Resumo
- Nubank, Bradesco, Amazon e Microsoft publicaram números grandes de geração de código com IA. A METR mediu dev experiente 19% mais lento. Nenhum dos dois lados está mentindo.
- Os números medem coisas diferentes: os cases medem o sistema inteiro; os estudos medem o dev com a ferramenta e o resto do fluxo intacto.
- O que mudou de verdade: gerar código ficou barato, e a conta foi parar na revisão. O gargalo mudou de lugar.
- Os três cases têm a mesma coisa em comum, e não é o modelo: é o que fizeram com a verificação. A régua para o seu time está na seção 4.
1. Os números que não cabem na mesma frase
De um lado, os cases publicados. De outro, os estudos medidos. Vale colocar os dois na mesa antes de escolher um lado.
1.1 O lado que acelera
Nubank. A migração do core de ETL — um monólito de 8 anos, com milhões de linhas — estava estimada em um ano e meio. Com o agente Devin, saiu em dois meses, com 12x de eficiência no tempo de engenharia, segundo a Cognition. O próprio Nubank descreveu a experiência no blog de engenharia.
Bradesco. Copilot interno com 40% de melhoria de eficiência reportada e times gerando até 10 mil linhas de código por dia.
iFood. Mais de 60% do código produzido na empresa já tem apoio de IA, segundo o relato técnico da GenPlat — o caso que abriu o post sobre gateway de IA.
Amazon. O caso mais concreto de todos: 30 mil aplicações migradas de Java 8/11 para 17 com o Q Developer, 4.500 anos-dev economizados e US$ 260 milhões por ano. Upgrade que levava 50 dias-dev caiu para horas.
Microsoft e NVIDIA. Nadella disse que até 30% do código da Microsoft já é escrito por IA; a NVIDIA adotou o Cursor como padrão e reporta 3x de volume por dev.
1.2 O lado que freia
O estudo da METR é o mais citado do ano, e com razão: experimento randomizado, 16 desenvolvedores experientes, 246 tarefas reais. Resultado: 19% mais lentos com IA — achando que estavam 20% mais rápidos.
E aqui a parte que quase ninguém cita: a própria METR atualizou o estudo em fevereiro de 2026. Com os agentes de fim de 2025, o efeito ficou perto de zero, com intervalo de confiança largo — e eles admitem um viés de seleção no desenho original: 30 a 50% dos convidados recusaram participar se tivessem que trabalhar sem IA. A leitura honesta não é "IA atrasa": é "o ganho individual medido é muito menor que o percebido, e muito menor que o dos cases".
A pesquisa da Stack Overflow com 49 mil devs fecha o quadro: adoção subiu de 76% para 84% enquanto a confiança caía de 40% para 29%. Mais devs desconfiam da precisão (46%) do que confiam (33%), e a frustração número um, citada por 64%, é a resposta "quase certa" — a que custa mais caro revisar.
E o código que fica: um estudo de abril de 2026 com 302,6 mil commits de IA em 6.299 repositórios achou mais de 15% dos commits introduzindo pelo menos um problema — em todos os assistentes analisados — e 22,7% dos problemas ainda vivos na versão mais recente dos repositórios.
2. O gargalo mudou de lugar
Os dois lados medem verdades diferentes porque o fluxo de software tem duas metades: produzir código e confiar nele. A IA industrializou a primeira e não tocou na segunda.
Antes, escrever era o caro. A revisão acompanhava porque a produção era o limite: o time inteiro não conseguia gerar PRs mais rápido do que conseguia lê-los.
Agora a geração é quase gratuita, e o que chega na fila de revisão é mais volume, em PRs maiores, escritos por uma ferramenta que erra de um jeito específico: plausível. O erro grosseiro a revisão pega; o "quase certo" da Stack Overflow exige ler com atenção de quem escreveu — sem ter escrito.
É aqui que entra o conceito que Addy Osmani, engenheiro do Google, nomeou em março: comprehension debt — a dívida de entendimento. Código mergeado que ninguém no time consegue explicar. Os 22,7% de problemas nunca corrigidos do estudo do arXiv são essa dívida aparecendo na medição: ninguém corrige o que ninguém entende.
O dev do experimento da METR estava exatamente nessa posição: a ferramenta gera rápido, e ele paga sozinho o custo de verificar. O saldo dá perto de zero. Não é a ferramenta que falha. É o fluxo que não mudou junto.
3. O que os cases fizeram de diferente
Olhe os três cases de novo, agora prestando atenção no que não é geração de código.
No Nubank, o Devin foi treinado com exemplos de migrações que os engenheiros já tinham feito à mão, e cada mudança passou por revisão e aprovação de um engenheiro. A tarefa era estreita e verificável: migração com formato conhecido, não feature aberta.
No Bradesco, a adoção do Copilot veio com camadas extras de revisão, compliance e segurança — o que torna o "10 mil linhas por dia" um número operável em banco, e não uma manchete de risco.
Na Amazon, a transformação de Java rodou num pipeline com testes: o critério de aceitação estava embutido no processo. 30 mil aplicações não passam por review manual de boa vontade.
O padrão é um só: os três aceleraram a geração e industrializaram a verificação. Tarefa estreita com critério claro, revisão com dono e regra, teste automatizado onde dava. O ganho não veio de gerar mais código; veio de conseguir confiar no código gerado mais rápido.
A diferença entre o case e o estudo não é o modelo, nem o talento do time. É que no case a verificação é um processo com dono — e no experimento, é um dev sozinho pagando esse custo por conta.
4. A régua: três perguntas para saber de que lado você está
Como no post sobre gateway, são perguntas que você responde numa reunião. Se precisar consultar alguém, esse já é um dado.
4.1 O tamanho médio do PR subiu desde que a IA entrou?
PR maior é o primeiro sintoma do gargalo mudando de lugar: gerar ficou fácil, e o custo foi empurrado para quem revisa. Se o seu tempo de aprovação também subiu, o time está mergeando mais e entendendo menos — exatamente a combinação do estudo dos 302 mil commits.
4.2 A verificação tem dono, ou é esperança?
Nos três cases, alguém é responsável por dizer "isso pode entrar": revisão com regra, teste no pipeline, critério de aceitação explícito. Se na sua empresa a resposta é "cada dev revisa o que a IA gera", você não tem processo — tem uma política implícita de confiança numa ferramenta em que 46% dos devs dizem não confiar. A configuração das ferramentas versionada no repositório e verificada em CI é o primeiro passo, e está descrita em Sua política de uso de IA não impede o vazamento.
4.3 O time consegue explicar o código que mergeou semana passada?
É o teste da dívida de entendimento, e dá para fazer literalmente: escolha um PR assistido por IA de semana passada e peça para o autor explicar uma decisão do código. Se a resposta for "foi o que a ferramenta gerou", você está acumulando os 22,7% — o problema que ninguém corrige porque ninguém entende.
O contrário também vale
Se o seu time é pequeno, os PRs continuam do mesmo tamanho e a revisão está em dia, não crie processo novo por causa deste post. Verificação industrializada resolve um problema de volume; sem volume, ela é burocracia procurando um problema.
5. O passo antes de qualquer ferramenta
Repare que as três perguntas são sobre o fluxo, não sobre o modelo. É por isso que trocar de assistente não muda o resultado de quem respondeu mal as três — e é por isso que os cases funcionam com ferramentas diferentes.
A estratégia de IA que funciona anda junto com a cultura de desenvolvimento que o time já tem: o rito de revisão, o pipeline, o critério do que pode entrar. A ferramenta certa escolhida antes disso vira prateleira. O fluxo certo acha a ferramenta sozinho.
Como ajudamos times a adotar IA
Trabalhamos com times de engenharia que buscam incorporar IA ao dia a dia de desenvolvimento — não como experimento, mas como parte real do fluxo de trabalho.
Isso passa por escolher as ferramentas certas para o contexto do time, configurá-las de forma que façam sentido para a política de dados da empresa e garantir que os desenvolvedores saibam usá-las de um jeito que realmente aumente a produtividade, em vez de gerar mais fricção.
Se você tem um time de desenvolvimento e está tentando colocar IA para trabalhar de forma séria, fale com a gente.