Revin

Revin Squads de engenheiros sêniores embarcados no seu time. Entramos no seu Slack, entregamos no seu repositório e tocamos seu roadmap. Full-stack em 2 semanas.

O Jev, da TypeSafe, virou o assunto da semana prometendo uma IA que não alucina porque não escreve texto.A promessa ajud...
18/09/2026

O Jev, da TypeSafe, virou o assunto da semana prometendo uma IA que não alucina porque não escreve texto.

A promessa ajuda pouco na hora de decidir: escolher a opção errada continua sendo erro. O que muda é o formato dele. Classif**ar ticket, rotear pedido e validar CNPJ são escolha, e o erro vira número que se testa no CI. Resposta ao cliente é escrita, e o erro vira revisão humana enquanto o fluxo existir.

No artigo, o teste de acerto por fila em Python:
https://revin.com.br/pt/blog/ia-que-escolhe-ou-ia-que-escreve-jev

82% das empresas brasileiras admitem que o time usa IA de terceiros sem aprovação. O número é do estudo da Oxford Econom...
18/09/2026

82% das empresas brasileiras admitem que o time usa IA de terceiros sem aprovação. O número é do estudo da Oxford Economics para a SAP, publicado hoje pelo TI Inside, e 43% delas já apontam vazamento de dados.

A reação comum é soltar um comunicado proibindo. Não funciona, porque ninguém avisa antes de colar um trecho de código no chat. O dev cola quando o prazo aperta e o caminho aprovado é pior que o proibido.

Nos slides, os três passos que fazem o caminho aprovado ganhar, começando por pagar a ferramenta que o time já usa.

Na sua empresa, o time usa IA paga pela empresa ou a conta pessoal?

Um post no dev.to disse em voz alta o que quase ninguém quer ouvir: os te**es que a IA gera testam os pontos cegos dela,...
09/09/2026

Um post no dev.to disse em voz alta o que quase ninguém quer ouvir: os te**es que a IA gera testam os pontos cegos dela, não o seu sistema. Juntou 36 reações e 33 comentários, e a discussão inteira gira em volta de um mecanismo bem simples.

A IA lê o seu código para escrever o teste. Se ela entendeu a regra errado, ela escreve a implementação errada e escreve também o teste que valida aquele erro. Os dois saem coerentes entre si, o relatório f**a verde e o erro passou duas vezes no mesmo lugar.

Isso não aparece na revisão porque não existe contradição para aparecer. O teste concorda com o código. Os dois discordam do contrato, e o contrato ninguém abriu.

Em montagem industrial tem uma regra chata que resolve essa história há décadas: quem soldou não assina o laudo do ensaio. Fui responsável técnico de estrutura metálica e nunca vi inspeção aceitar o mesmo sujeito aprovando a própria junta. Em software virou rotina.

Três checagens que cabem numa tarde: quebre uma regra de propósito e veja se algum teste f**a vermelho, procure teste sem expect, rode mutation testing num módulo que mexe em dinheiro.

Comenta 1 se o seu time roda mutation testing, 2 se ninguém nunca quebrou um teste de propósito só para ver o que acontece.

**esautomatizados

Martin Fowler publicou hoje uma frase de Christian Catalini que vale mais que a maioria dos relatórios de IA deste ano: ...
08/09/2026

Martin Fowler publicou hoje uma frase de Christian Catalini que vale mais que a maioria dos relatórios de IA deste ano: o custo de gerar coisas caiu muito, o custo de verif**ar essas coisas não caiu quase nada.

Repare onde a IA chegou primeiro. Chat, imagem, código. Todos com saída fácil de inspecionar: você lê o texto, olha a imagem, roda o teste. A fronteira antiga era trabalho rotineiro contra não rotineiro. A nova é mensurável contra não mensurável.

O problema aparece quando a verif**ação também vira coisa gerada. Semana passada eu parei o Postgres num ambiente de teste para ver quem reclamava. Quatro dos seis serviços continuaram respondendo 200 no /health, com painel verde e tudo. A checagem existia. A garantia não existia em nenhum momento.

Aqui a gente marcou 96 PRs e voltou uns três meses depois: 33,9% dos arquivos escritos com IA tinham voltado para conserto, contra 20,8% dos escritos à mão. Gerar acelerou. Conferir continuou custando hora de gente sênior.

Antes de aumentar o volume que o seu time gera, responda a pergunta chata para cada tarefa: quanto custa saber que isso está certo? Se a resposta for descobrir quando o cliente reclamar, o gargalo mudou de lugar e ninguém avisou o orçamento.

Gerar ou conferir: qual dói mais na sua empresa hoje? Comenta 1 ou 2 aqui embaixo.

Está construindo com IA e não sabe avaliar arquitetura? Comece pela checagem mais barata que existe: pegue uma máquina l...
04/09/2026

Está construindo com IA e não sabe avaliar arquitetura? Comece pela checagem mais barata que existe: pegue uma máquina limpa e tente subir o sistema seguindo só o que está escrito no repositório. Se passar de umas duas horas, ou se só uma pessoa no mundo consegue, você não tem um sistema de pé.

Antes da Revin eu tive uma startup e a minha pergunta para o dev era sempre "quanto tempo leva". Levei quase um ano pra ver que o erro estava na pergunta.

As outras quatro checagens, nenhuma exigindo ler código:
https://revin.com.br/pt/blog/construir-com-ia-sem-saber-arquitetura

Perto de dois terços das empresas já derrubaram um aplicativo crítico de negócio por política de segurança mal configura...
02/09/2026

Perto de dois terços das empresas já derrubaram um aplicativo crítico de negócio por política de segurança mal configurada. O relatório é da Cloud Security Alliance e saiu hoje no CIO Dive. Ninguém invadiu nada: a configuração era da própria casa.

Separei quatro coisas que aparecem em quase toda auditoria de sistema herdado que chega aqui, da regra de rede duplicada em ambiente híbrido ao health check que responde 200 com o checkout parado. No fim, cinco te**es que cabem numa tarde antes do próximo deploy.

Qual deles você não consegue rodar hoje?

O LeadDev publicou um perfil da cultura de engenharia de alta intensidade da Shopify. A frase que ficou: alta intensidad...
31/08/2026

O LeadDev publicou um perfil da cultura de engenharia de alta intensidade da Shopify. A frase que ficou: alta intensidade não é a mesma coisa que alto estresse.

O que chega aqui em call comercial é a versão encurtada dessa história. O prazo apertou, alguém decide que o time precisa render mais, e a conversa vira ritmo. Quase nunca é ritmo.

Velocidade é multiplicador. Se o caminho do commit até o cliente é curto e dá para voltar atrás, mais ritmo vira mais entrega. Se cada deploy depende de uma reunião e ninguém sabe o que quebra quando o serviço cai, mais ritmo vira fila maior de coisa pela metade. Nos projetos que chegam aqui depois que o fornecedor sumiu, uns 40% do sprint já vão para consertar o que foi entregue antes. Pedir intensidade em cima disso acelera essa fatia junto.

Cultura se copia numa reunião de segunda. Fundação leva meses.

Antes de pedir mais ritmo, olhe quatro coisas: o sistema sobe hoje numa máquina limpa, o deploy volta atrás sem reunião, o alerta acende antes do cliente ligar, e existe teste que falha quando você quebra o código de propósito.

O deploy de ontem dava para voltar atrás sem reunião? 1 para sim, 2 para não.

"Vocês só colocam 3 pessoas no meu projeto." Essa frase aparece em quase toda call comercial que eu faço, e a resposta a...
28/08/2026

"Vocês só colocam 3 pessoas no meu projeto." Essa frase aparece em quase toda call comercial que eu faço, e a resposta aqui é sempre a mesma: essa é a ideia.

Com ela vêm outras três. Não aceitamos escopo fechado. Pedimos leitura do repositório antes de dar prazo. Não descemos para o preço do concorrente. As quatro são limitações verdadeiras do que a gente vende, e nenhuma é acidente.

O fio que liga todas é o contrato. Preço fechado paga quem termina, não quem entrega algo que aguenta o ano seguinte. Aí a versão barata da solução vira o padrão, e o que sai primeiro é justamente o que você não tem como avaliar na hora de assinar: teste que verif**a de verdade, revisão de pull request, instrumentação de monitoramento. O painel f**a verde e ninguém está medindo nada atrás dele.

Eu já estive do outro lado da mesa. Na minha primeira empresa eu contratava dev sem saber julgar prazo, e a sprint terminava sem a entrega. Toda vez. Levei um tempo para entender que o problema morava no modelo de contratação, não na equipe.

Qual dessas quatro objeções você já disse numa call? Escreve o número aqui embaixo, quero saber qual dói mais.

Todo mês tem gente pegando o salário mensal do dev, dividindo por 160 e achando que descobriu o custo da hora. Falta met...
26/08/2026

Todo mês tem gente pegando o salário mensal do dev, dividindo por 160 e achando que descobriu o custo da hora. Falta metade da conta.

Quem já orçou obra sabe o erro. Você lista o tijolo, o cimento e o ferro, fecha um número, e aí chega a mão de obra, o andaime, o transporte e o mestre que vai olhar o serviço. O número da lista de material nunca foi o preço da casa.

Com dev é igual. O salário é a linha mais visível e a menos completa.

Fora dele vem FGTS, INSS, férias com o terço, décimo terceiro, provisão de rescisão. Só isso já joga o custo uns 70% a 80% acima do bruto. Depois entra o que sustenta o trabalho: notebook, IDE, repositório, monitoramento, ambiente de homologação, o plano de IA que o time usa todo dia.

E tem a parte que ninguém coloca na planilha porque não vira boleto: as horas que não chegam no produto. Alguém revisa o pull request. Alguém cobre as férias. O incidente come uma tarde. O onboarding do próximo come uma semana. Das 160 horas que você contratou, umas 110 viram entrega.

Quando eu fecho essa conta, o multiplicador cai entre 2,2 e 2,8 vezes o salário. É faixa, não fórmula: depende do seu regime, da sua stack e de quanto o time gasta em reunião.

Refaça a sua com esses números antes de olhar qualquer proposta de fora. Comparar R$ 87 com o valor da hora de um fornecedor é comparar lista de material com obra entregue.

Faz a conta aí e me conta: qual multiplicador deu no seu time?

Uma pergunta simples juntou 35 respostas no TabNews: dá para subir um sistema PHP 5.6 para o PHP 8 e ainda colocar Larav...
25/08/2026

Uma pergunta simples juntou 35 respostas no TabNews: dá para subir um sistema PHP 5.6 para o PHP 8 e ainda colocar Laravel em cima, ou é melhor desenvolver do zero?

São duas obras de tamanho diferente, e a segunda é bem mais cara do que parece na reunião.

Subir a versão costuma sair barato. O que ninguém coloca na planilha é o comportamento que muda em silêncio. No 5.6, comparar 0 com um texto devolvia verdadeiro. No 8, devolve falso. Nada explode, nenhum log acende. O if que decide desconto só escolhe o outro caminho, e você descobre no fechamento do mês, pelo financeiro.

Num sistema de umas 90 mil linhas, a ferramenta de compatibilidade marcou 217 apontamentos. O que custou dinheiro não estava naquela lista, porque relatório de compatibilidade lê sintaxe e essa mudança é de comportamento.

Antes de aprovar reescrita, meça três coisas: quantas regras de negócio só existem dentro do código, quanto do faturamento passa por elas e quanto tempo o time leva para subir o sistema numa máquina limpa. Reescrever congela o roadmap por uns dois trimestres. O sistema antigo, feio do jeito que está, é a única documentação viva das suas regras.

E no seu caso: qual versão roda hoje no sistema que sustenta o faturamento? Comenta 5.6, 7 ou 8 que eu digo por onde eu começaria.

Address


Website

Alerts

Be the first to know and let us send you an email when Revin posts news and promotions. Your email address will not be used for any other purpose, and you can unsubscribe at any time.

Shortcuts

Share