Durante anos, o gargalo de desenvolvimento de software foi escrever código. Hoje, em empresa que adotou IA a sério, deixou de ser. Google reporta que 75% do código novo em produção é gerado por IA. Microsoft fica na faixa de 20% a 30%. Meta mira 50% até o fim de 2026. GitHub Copilot registra média de 46% entre seus usuários.
O gargalo não sumiu — só trocou de lugar. Foi da escrita para a revisão.
O tamanho real do risco
Vale começar pelo dado que assusta, porque ele é concreto e recente. Um levantamento da Veracode, testando mais de 100 modelos de linguagem em mais de 80 tarefas de programação, encontrou que 45% do código gerado por IA introduziu pelo menos uma vulnerabilidade do OWASP Top 10 — a lista das falhas de segurança mais críticas e mais exploradas do mundo. Java foi a linguagem mais arriscada, com falha em 72% dos casos testados; Python, C# e JavaScript ficaram numa faixa de 38% a 45%.
Isso não significa que IA escreve código pior que humano em todos os aspectos — significa que o código gerado passa nos testes funcionais e ainda assim carrega falha de segurança que só aparece sob revisão específica, não sob teste comum.
Tem outro ângulo, menos falado: volume. Um estudo da Apiiro, analisando ambiente real de empresa Fortune 500, encontrou que desenvolvedores usando IA produzem de 3 a 4 vezes mais commits, com pull requests maiores e mais dependência externa acumulada. Mais código, mais rápido, com mais peça nova entrando no sistema — cada uma dessas peças é superfície de ataque em potencial que alguém precisa revisar.
A conta simples: se a geração de código acelerou várias vezes e a capacidade humana de revisar não acelerou na mesma proporção, o gap entre os dois só cresce. Analistas do setor já nomeiam isso como "gap de geração de IA" — a distância entre volume produzido e volume que dá para revisar com atenção real.
O que não funciona: tentar revisar tudo manualmente, do jeito antigo
A resposta ingênua é "revisar com mais cuidado". Não escala. Revisor humano cansa, revisor humano não lê PR de 800 linhas com o mesmo rigor que lê um de 40, e volume 3 a 4 vezes maior não encontra 3 a 4 vezes mais revisor disponível — as empresas não estão contratando revisor nessa proporção.
O padrão que emergiu: redistribuir a revisão, não eliminar
O que empresas maduras nessa transição estão fazendo não é substituir revisão humana por revisão de IA. É redividir o trabalho entre as duas camadas, cada uma no que faz melhor.
IA assume o mecânico: erro de sintaxe, code smell, tratamento de erro incompleto, padrão repetido que já se sabe que é problema. Humano fica com a parte que exige contexto de negócio e julgamento — se o código está tecnicamente correto mas resolve o problema errado, e decisão de arquitetura que impacta o sistema como um todo. Isso não é redução do papel do revisor humano; é concentração dele no que só humano faz bem.
A Cloudflare tornou isso público em detalhe. Em vez de um revisor de IA genérico com um prompt gigante tentando cobrir tudo, eles rodam até sete agentes especializados em paralelo — cada um focado numa dimensão específica: segurança, performance, qualidade de código, documentação, gestão de release, conformidade com padrão de engenharia interno. Em um mês de operação, o sistema completou 131 mil execuções de revisão, cobrindo 48 mil pull requests em mais de 5 mil repositórios.
Note o paralelo com o conceito de sensor que já discutimos [no post sobre agent harness](/lab/o-que-e-agent-harness): um revisor especializado em segurança fazendo checagem de padrão conhecido é sensor computacional — determinístico, rápido, confiável para o que foi desenhado a checar. Um revisor avaliando se a documentação está clara ou se a solução atende à intenção do pedido original é sensor inferencial — mais flexível, mais sujeito a erro, e é aí que a revisão humana continua indispensável.
Adoção enterprise não é só sobre qualidade do modelo
Vale um ponto que passa despercebido em quem só olha benchmark técnico: quando empresa grande — banco, hospital, empreiteira de defesa — adota revisão de código por IA em escala, o critério de decisão não é só "o modelo encontra bug". É conformidade SOC 2, controle de residência de dado, integração com login corporativo, log de auditoria completo, controle de acesso por papel, e possibilidade de rodar dentro do próprio ambiente da empresa em vez de depender de nuvem externa. Ferramenta que resolve bem o problema técnico e ignora essa camada não entra em empresa grande, mesmo sendo tecnicamente superior.
O que isso muda depois que o código já está em produção
Um deslocamento que conecta direto com esse tema: parte da confiança que antes vinha só de "passou na revisão antes do merge" está migrando para observabilidade contínua depois do deploy. A maioria esmagadora dos líderes técnicos do setor já trata isso como recurso crítico — porque revisão de código, humana ou por IA, nunca vai pegar tudo antes de ir para produção. O que acontece de fato em produção — rastro de execução, sequência de chamada, padrão de erro real — virou sinal que complementa, não substitui, a revisão que acontece antes do merge.
Isso é coerente com algo que qualquer time definindo "pronto" para uma tarefa já devia estar considerando: código revisado e testado não é mais garantia suficiente sozinha. "Pronto" inclui, cada vez mais, ter como saber se algo deu errado depois de já estar no ar.
O que fazer com essa informação
Três decisões práticas, na ordem que fazem mais sentido para time pequeno ou médio decidindo como adotar isso:
* Não trate ferramenta de revisão por IA como substituto de revisor humano. Trate como camada que absorve o mecânico, para que a atenção humana, que é finita, se concentre no que exige julgamento.
* Separe segurança do resto. Considerando que quase metade do código gerado por IA carrega alguma vulnerabilidade conhecida, checagem de segurança automatizada não é opcional nem depois — é parte obrigatória de qualquer pipeline que aceita código gerado por IA.
* Não meça sucesso só por "quantos PRs revisamos". Volume de revisão subiu porque volume de código subiu; a métrica que importa é se o que passou pela revisão continua estável depois de estar em produção, não quantos itens foram marcados como aprovados.
O gargalo não desapareceu quando IA passou a escrever código. Só trocou de nome, e quem não perceber a troca continua otimizando a parte errada do processo.