O novo gargalo não é escrever código: é revisar código gerado por IA

A cena se repete em quase todo time que adotou assistentes de código: a fila de pull requests cresce mais rápido do que a agenda de quem revisa. O desenvolvedor que antes levava dois dias para escrever uma feature agora abre o PR na manhã seguinte — e abre outro à tarde. A revisão, que sempre foi o gargalo silencioso, virou o gargalo visível.

O problema não é a IA escrever código. É que a capacidade de revisão não escala junto com a geração, e o material que chega para revisão mudou de natureza: diffs maiores, menos refatoração, mais superfície de erro.

O gargalo mudou de lugar

O relatório DORA de 2024 já apontava o paradoxo: com 75,9% dos times usando IA, a taxa de entrega caiu 1,5% e a estabilidade da entrega recuou 7,2%. Ganho individual de produtividade não se traduziu em melhora organizacional (byteiota).

A qualidade do material revisado também mudou. Uma análise da CodeRabbit sobre 470 pull requests de projetos open source, de dezembro de 2025, encontrou 1,7x mais problemas em código gerado por IA — 10,83 issues por PR contra 6,45 (roamingpigs). O mesmo levantamento cita o relatório State of AI Code Quality de 2025: 76% dos desenvolvedores não confiam plenamente em código escrito por IA, mas usam assim mesmo. Erros de lógica e correção sobem 75%; vulnerabilidades de segurança chegam a 2,74x.

Há um efeito estrutural por baixo disso. A GitClear, analisando 211 milhões de linhas de código entre 2020 e 2024, viu o código refatorado cair de 24,1% para 9,5% — e o copiar-e-colar superou a refatoração pela primeira vez (the-ai-corner). Ou seja: chega mais volume, com menos consolidação interna, para uma equipe de revisão do mesmo tamanho.

O caso CamoLeak (CVE-2025-59145, CVSS 9.6) é o retrato do padrão: código plausível que ninguém leu com profundidade suficiente (the-ai-corner).

Quatro sinais de risco que aparecem no diff

Antes de discutir processo, vale nomear o que se vê. Estes sinais não provam problema, mas pedem revisão mais lenta:

• Diff grande demais para caber na cabeça. Quando um PR mistura feature, refatoração e ajuste de configuração, o revisor perde a capacidade de reconstruir a intenção. Diff grande costuma esconder decisão não tomada.
• Testes que só confirmam a implementação. O teste foi escrito depois, espelha a estrutura do código e passa sempre. Não descreve comportamento esperado nem falha quando a regra de negócio muda. É o sintoma que o laudo de Cobertura de Testes & Test Theater chama de test theater.
• Abstrações que ninguém entende. Camadas novas, interfaces de uma implementação só, indireção sem consumidor. Se o revisor não consegue explicar por que a abstração existe, ela provavelmente não deveria existir ainda.
• Ausência de vínculo com requisito. O PR resolve algo, mas não há linha que ligue o código à decisão que o justifica. Sem esse elo, a revisão vira opinião contra opinião.

Três camadas de revisão, não uma

Boa parte da fricção vem de tratar revisão como um bloco único. São três perguntas diferentes, com ferramentas e tempos diferentes:

Revisão sintática — o código compila, segue o padrão, não introduz segredo hardcoded, não traz dependência suspeita. É a camada mais automatizável: lint, análise estática, verificação de dependências. Aqui a IA revisora ajuda de verdade, porque o critério é objetivo.

Revisão arquitetural — a mudança respeita as fronteiras existentes? Introduz ciclo entre módulos? Coloca regra de negócio na camada de persistência? Aumenta acoplamento em um ponto já quente? Essa camada exige contexto que o diff não carrega: ela só faz sentido contra um retrato da arquitetura atual.

Validação da intenção — é isso que deveria ser construído? O comportamento entregue corresponde ao requisito, à decisão registrada e ao risco aceito? É a camada que nenhuma ferramenta fecha sozinha, porque depende de alguém que detém a intenção original.

O erro comum é empurrar tudo para a terceira camada e chamar de "revisão de código". O revisor humano gasta energia em formatação e estilo enquanto a pergunta de arquitetura passa batida — e a de intenção, também.

Critérios verificáveis para aceitar uma mudança

Critério verificável é aquele que outra pessoa consegue checar sem perguntar ao autor. Alguns que funcionam na prática:

1. O PR declara qual requisito ou decisão ele atende, com link para a spec, issue ou decisão registrada. Sem isso, o PR não entra na fila de revisão profunda.
2. O diff tem um limite acordado. Acima dele, o PR é dividido — não por burocracia, mas porque revisão acima de certo tamanho degrada para leitura superficial.
3. Todo comportamento novo tem um teste que falha quando a regra muda. Não cobertura percentual: um teste que quebra se a intenção for violada.
4. A mudança não cria ciclo novo nem cruza fronteira de domínio sem justificativa escrita. Isso é checável por análise estrutural, não por opinião.
5. Nenhum segredo, credencial ou dependência de nome suspeito entra sem verificação explícita. Slopsquatting é um vetor real de supply chain.
6. O autor consegue explicar a abstração que introduziu. Se não consegue, ela sai do PR.

Note o que esses critérios têm em comum: todos ancoram a mudança em algo externo ao diff — um requisito, uma fronteira, um teste que falha, uma dependência verificada. É o oposto de "parece bom".

O que fazer quando o volume não volta atrás

Não adianta prometer revisão mais rápida. O caminho é reduzir o que precisa de olho humano profundo, empurrando o resto para verificação automática — e reservando a atenção humana para arquitetura e intenção.

Isso exige três coisas que a maioria dos times não tem hoje: um retrato do estado atual (para revisar arquitetura contra algo, não no vácuo), uma especificação que ligue requisito a decisão, e sensores que verifiquem o que foi acordado sem depender de leitura manual.

É exatamente aí que o ArchGenerator entra. Um laudo de diagnóstico estabelece o estado medido — com evidência ancorada, interpretação presumida e limitação em aberto separadas — e serve de linha de base para a revisão arquitetural. A partir de um laudo elegível, um Kit SDD organiza prioridades, especificações, contratos, regras de governança e sensores de verificação, entregues para uso no ambiente da equipe. O elo que interessa aqui é a rastreabilidade: o achado aponta o problema, a spec registra a decisão, a story delimita o trabalho e o sensor verifica o resultado. O ArchGenerator não aplica a correção nem faz merge — quem decide e executa continua sendo o time.

O ganho não é revisar mais rápido. É revisar menos coisa que não precisava de humano, e revisar com critério o que realmente importa.

O gargalo é uma escolha de processo

A geração de código ficou barata; a confiança, não. Enquanto o volume de PRs crescer sem que os critérios de aceite fiquem explícitos, a fila de revisão vai continuar sendo o ponto onde o ganho de velocidade se perde — e onde o risco entra em produção sem ser visto. O trabalho não é frear a IA. É decidir, antes do próximo PR, o que precisa estar verdadeiro para que uma mudança seja aceita: qual requisito ela atende, qual fronteira ela respeita, qual teste falha se ela estiver errada. Times que escrevem esses critérios revisam menos e confiam mais. Times que não escrevem vão revisar tudo — e enxergar cada vez menos.