Eduardo Blog
Portugues English

Publicado em

Quem revisa o código que ninguém leu

A revisão linha a linha não escala no volume atual, mas ninguém sabe medir se a camada de verificação que a substitui é suficiente.

17 min de leitura

Em

Tags

O review linha a linha está quebrando. O problema é que ninguém sabe medir o que vai substituí-lo.

Nicholas Carlini trabalhou com penetration testing antes de ir para a Anthropic. Isso importa para entender o que ele fez e, principalmente, para entender como ele terminou.

Ele colocou dezesseis agentes de IA rodando em paralelo sobre um mesmo repositório, sem intervenção humana ativa, com a tarefa de escrever um compilador C em Rust do zero. Duas semanas, cerca de duas mil sessões, vinte mil dólares em API, cem mil linhas de código. O resultado compila um kernel Linux 6.9 que dá boot em x86, ARM e RISC-V. Passa 99% da GCC torture test suite. Compila QEMU, SQLite, Postgres, Redis. Roda Doom.

Nenhum ser humano revisou aquele código.

Não por descuido. Por design: a verificação era feita pela suíte de testes e por um oráculo externo, o próprio GCC, usado como compilador comprovadamente correto para isolar onde o compilador do Claude errava. É, na prática, o modelo que boa parte da indústria está propondo como substituto do code review. E funcionou.

O texto em que Carlini descreve tudo isso termina assim:

“For autonomous systems, it is easy to see tests pass and assume the job is done, when this is rarely the case. I used to work in penetration testing (…) and the thought of programmers deploying software they’ve never personally verified is a real concern. (…) while this experiment excites me, it also leaves me feeling uneasy.”

Alguém construiu uma das melhores camadas de verificação automatizada de que se tem notícia, viu ela funcionar, e ainda assim não considera o resultado verificado. Esse desconforto é o assunto deste artigo.

O que quebrou

O code review linha a linha assume uma coisa banal: que o revisor consegue ler a mudança.

Essa premissa está cedendo, e há números. Um levantamento da Faros.ai sobre mais de dez mil desenvolvedores em 1.255 times mostra que equipes com alta adoção de IA completam 21% mais tarefas, fazem merge de 98% mais pull requests e veem o tempo de review subir 91%.

Repare que são duas curvas subindo ao mesmo tempo: o número de mudanças e o tamanho delas. E há um terceiro fator que piora a conta, este vindo de relato de desenvolvedores: revisar código gerado por IA custa mais esforço do que revisar código de um colega. Falta a âncora de intenção. Você não pode perguntar ao autor por que ele fez daquele jeito, porque não houve um “por quê”: houve uma amostragem.

O time produz mais código e então gasta mais tempo revisando. É a definição de um gargalo que se desloca.

Do lado da qualidade, o quadro é pior documentado, mas aponta na mesma direção. A GitClear analisou 153 milhões de linhas alteradas entre 2020 e 2023 e mediu não velocidade, mas composição: a proporção de código “adicionado” e “copiado/colado” subiu em relação a código “atualizado”, “deletado” e “movido”. Menos código movido significa menos refatoração e menos reuso. E o churn, linhas revertidas ou reescritas em até duas semanas, foi projetado para dobrar em relação ao baseline pré-IA de 2021. A formulação da GitClear é boa: o código gerado por IA se comporta como “um colaborador itinerante, propenso a violar o princípio DRY dos repositórios que visita”.

Um terceiro dado, de origem completamente diferente, fecha o triângulo. O DORA Report de 2023, com cerca de três mil respondentes, encontrou que ferramentas de IA melhoravam levemente o bem-estar individual (menos burnout, mais satisfação), com efeito neutro a negativo na performance do time. Ganho individual, perda coletiva. É exatamente o formato de um problema de integração, não de geração.

Um parêntese histórico que desarma o pânico

Vale registrar algo que o próprio debate tende a esquecer: o code review linha a linha só se tornou prática ubíqua por volta de 2012 a 2014.

Times entregaram software por décadas sem ele. E mesmo depois de adotá-lo, as coisas continuaram quebrando. Foi precisamente por isso que a indústria construiu feature flags, rollout gradual, canary deploys e rollback instantâneo. Ou seja: nós já tínhamos concluído, muito antes da IA, que o review sozinho não bastava. Ele nunca foi o único portão; era um filtro entre outros.

Isso não torna o review dispensável. Torna a discussão menos teológica. A pergunta não é “vamos abrir mão de um pilar sagrado?”, e sim “esse filtro específico ainda está pegando o que se propunha a pegar, no volume atual?”.

A dificuldade de fundo: o agente não julga o próprio trabalho

Antes das soluções, o obstáculo: quase toda proposta ruim nasce de subestimá-lo.

O time de Labs da Anthropic publicou um estudo de arquitetura de harness para desenvolvimento de longa duração. O ponto de partida foi uma falha recorrente e chata: quando você pede a um agente que avalie o que acabou de produzir, ele responde com elogio confiante. Mesmo quando a qualidade é obviamente medíocre para qualquer observador humano. O problema é agudo em tarefas subjetivas, mas aparece também nas verificáveis.

A resposta deles foi separar quem faz de quem julga: um gerador e um avaliador independentes. Mas a lição não é a arquitetura, e sim a razão dela:

Calibrar um avaliador externo para ser cético é muito mais tratável do que fazer um gerador ser crítico de si mesmo.

Note o que essa frase admite. A separação não elimina a leniência: o avaliador continua sendo um LLM inclinado a ser generoso com output de LLM. O relatório é honesto ao ponto de dizer que Claude é “a poor QA agent” fora da caixa: identificava problemas legítimos e então se convencia de que não eram grandes coisas, aprovando o trabalho assim mesmo. Foram várias rodadas de leitura de logs e ajuste de prompt até o julgamento ficar razoável. E mesmo depois sobrou headroom: bugs em features aninhadas que o avaliador não exercitou a fundo.

Ankit Jain, fundador da Aviator, chegou ao mesmo diagnóstico e propôs uma saída diferente e complementar:

“The fix isn’t to ask the LLM to verify. It’s to ask it to write a script that verifies. Shift from judgment to artifact.”

Duas soluções, uma falha só. E a falha tem nome antigo. É a Lei de Goodhart: quando uma medida vira objetivo, deixa de ser boa medida. O incentivo de um sistema agêntico é trivial: consigo completar a tarefa? Consigo agradar quem me pediu? O sucesso do agente nunca é intrinsecamente guiado por acurácia de longo prazo ou requisito de negócio. Um agente otimizando “os testes passam” é uma fábrica soviética otimizando “número de pregos produzidos”: a meta é batida, o indicador melhora nos relatórios, e a correlação entre indicador e realidade se rompe em silêncio.

É também por isso que “usar IA para revisar o código da IA” não resolve sozinho. Se um agente escreve e outro agente revisa, fresh eyes is just another agent with the same blind spots: olhos frescos são só mais um modelo com os mesmos pontos cegos. O review pós-PR fazia sentido quando humanos escreviam e precisavam de um segundo par de olhos com um viés diferente.

As abordagens: cinco filtros imperfeitos

A proposta mais articulada hoje é a de Jain, e vale apresentá-la pelo que ela é: um modelo de queijo suíço. Nenhum portão pega tudo; empilham-se filtros furados até os furos não se alinharem.

1. Comparar múltiplas opções. Em vez de pedir a um agente que acerte, peça a três que tentem de formas diferentes e escolha. A seleção nem precisa ser manual: dá para ranquear por quantas etapas de verificação passaram, pelo menor diff, por não introduzir dependências novas. O argumento econômico: o custo da opcionalidade é o mais baixo da história da engenharia de software.

2. Guardrails determinísticos. Testes, type checks, verificação de contrato. Coisas que não têm opinião, só fatos. A frase que sintetiza a camada: o agente não consegue negociar com um teste que falha. Em subcamadas: linters custom, invariantes da organização (nenhuma credencial hardcoded), contratos de domínio (em pagamentos, todo valor monetário usa o tipo Money).

3. Humanos definem critérios de aceitação. Aqui o BDD volta a fazer sentido depois de vinte anos de adoção morna. Ele nunca pegou porque escrever a spec parecia trabalho extra quando você ia escrever o código de qualquer jeito. Com agentes, a equação inverte: a spec deixa de ser trabalho extra e vira o artefato primário; o código vira artefato dela. A pergunta do humano muda de “você escreveu isso corretamente?” para “estamos resolvendo o problema certo com as restrições certas?”.

4. Permissões como arquitetura. A maioria dos frameworks trata permissão como tudo-ou-nada, mas granularidade importa. Se a tarefa é “corrigir o parsing de data em utils/dates.py”, o acesso deveria ser àquele arquivo e ao seu teste, não ao codebase inteiro. E gatilhos de escalação (mexer em autenticação, em schema de banco, adicionar dependência) marcam revisão humana independentemente da confiança do agente.

5. Verificação adversarial. Um agente faz, outro verifica, e eles não confiam um no outro: esse é o ponto. É um padrão organizacional antigo, a mesma razão pela qual QA não deveria se reportar ao gerente de engenharia. Com agentes dá para impor arquiteturalmente: o verificador não tem como modificar o código para facilitar o próprio trabalho.

Duas armadilhas que o próprio Jain sinaliza, e que valem mais que várias das camadas:

Se o agente escreve o código e os testes, você só moveu o problema. Agora você confia que ele testou as coisas certas. Os critérios de verificação precisam vir da spec e ser definidos antes do código, não inventados depois para confirmar o que já está lá.

E o rubber-stamp é mensurável. A Anthropic publicou o número ao explicar por que construiu um modo automático de permissões no Claude Code: na prática, usuários aceitam 93% dos prompts de permissão. Um portão que quase sempre diz sim não é um portão, é um ritual. Pior: aprovar cada ação treina você a não ler o que aprova, anulando o propósito da aprovação. Qualquer um que já tenha dado “LGTM” num PR de oitocentas linhas sabe que o problema não nasceu com a IA, ela só o tornou estatisticamente visível.

Uma tática barata que não aparece nas cinco camadas e merece estar em qualquer pipeline: peça o review a um modelo de outra família. Modelos treinados em dados diferentes têm pontos cegos diferentes. Não resolve o problema estrutural, mas é a única forma barata de recuperar algo parecido com “olhos frescos”.

O argumento que dispensa convicção

A parte mais subutilizada dessa discussão é econômica, e vem dos números que a Anthropic publicou do próprio harness. No build de uma DAW no navegador, com Opus 4.6:

Fase Custo
Build (3 rounds) US$ 113,85
QA (3 rounds) US$ 10,39
Total US$ 124,70

O QA custou cerca de 8% do total. E, por esses 8%, pegou features stubadas, uma gravação de áudio que só alternava o estado do botão sem gravar nada, e clipes que não arrastavam.

Verificação é barata em relação a geração. Esse é o argumento a favor de separar quem faz de quem julga que não depende de concordar com ninguém sobre o futuro do code review. Ele vale mesmo para quem acha o resto deste artigo exagerado.

A prova por contraste

Dois casos, mesmo autor, mesmo veículo, mesmo período. Gergely Orosz cobriu os dois no The Pragmatic Engineer.

O primeiro: a Bun migrou de Zig para Rust em onze dias, com 64 agentes de IA e cerca de US$ 165 mil. Funcionou.

O segundo: o Spotify. Um podcast da própria empresa com a Anthropic reporta 4.500 deploys de produção por dia, 73% dos PRs assistidos por IA, engenheiros mantendo de cinco a dez sessões de Claude simultâneas em tmux sobre um monorepo de vinte milhões de linhas. No mesmo período, o pipeline de publicação do Spotify Podcasts falhou três vezes em cinco semanas, sem status page, com um incident review prometido que saiu três semanas depois, e com o timeline errado. A causa-raiz da primeira falha: um campo novo entrou no critério de elegibilidade de publicação sem disparar a atualização downstream correspondente. Episódios ficavam elegíveis e simplesmente não publicavam. Em silêncio.

Escala industrial de IA nos dois casos. A diferença não é quantidade de IA.

  Bun Spotify Podcasts
Verificador Compilador + suíte de testes madura + usuários em produção Pipeline que perdia episódios silenciosamente
Resultado Migração em 11 dias 3 falhas em 5 semanas, sem status page

A IA amplifica o que o seu ciclo de verificação já é.

E há uma ironia que fecha o caso: o próprio podcast do Spotify com a Anthropic afirma que verificação é a coisa mais importante ao trabalhar com agentes, e o lugar onde a maioria das empresas subinveste: eles adicionaram um judge e a taxa de sucesso de PR saltou de ~25% para 80%. A organização conhecia a regra, sabia enunciá-la em público, e mesmo assim entregou um pipeline que falhava em silêncio.

Saber o princípio não é o mesmo que ter a infraestrutura.

O que continua em aberto

Aqui é onde eu preciso ser honesto sobre as fontes, porque a procedência muda a leitura.

Ankit Jain é fundador e CEO da Aviator, empresa que vende exatamente infraestrutura de verificação para times “AI-native”: os links de verification rules e acceptance criteria no texto dele apontam para a documentação do próprio produto. O Latent Space publicou o artigo com o editor declarando explicitamente que discordava. A GitClear, do outro lado da mesa, vende ferramenta de code review e tem interesse direto na narrativa “código de IA precisa de mais revisão”. E o estudo que ela contrasta, o dos 55% de ganho de velocidade com Copilot, é patrocinado pelo GitHub. Faros.ai e DORA são os dados mais limpos de conflito, e são os que eu citaria primeiro em qualquer discussão.

Nada disso invalida os argumentos. Mas explica por que a conclusão de cada lado coincide tão bem com o que cada lado vende.

O contraponto que não tem conflito de interesse é o de Carlini, e é por isso que ele abre e fecha este texto. Jain assume que a camada de verificação pode ser boa o bastante para substituir a leitura humana. Carlini construiu uma das melhores possíveis (compilador com oráculo externo, 99% de aprovação em torture tests) e disse que não está confortável.

O ponto de convergência honesto entre os dois é este:

A revisão linha a linha de fato não escala no volume atual. Mas a pergunta em aberto não é se o checkpoint deve subir: é como medir se a camada de verificação que o substitui é suficiente.

Ninguém tem essa métrica. Não existe, hoje, um número que responda “o quão verificado está este código?” da forma como cobertura de teste finge responder e não responde. Enquanto não existir, cada time que move o checkpoint para cima está fazendo uma aposta calibrada por intuição.

E o que sobra para você

Duas coisas, e nenhuma delas é ler diffs de quinhentas linhas.

A primeira é escrever a spec e os critérios de aceitação, antes, não depois. É o único ponto do processo em que o julgamento humano entra sem competir com a máquina em velocidade.

A segunda, Burke Holland formulou melhor do que eu formularia:

“A coisa mais importante é não aceitar output de IA que seja ‘bom o suficiente’. Insista em qualidade. Seja implacável. Essa parte ainda é sua responsabilidade, e saber distinguir um resultado de qualidade de um que não é é o valor que você traz.”

E, como régua do que a camada automatizada precisa cobrir para substituir a leitura, o velho checklist do Google continua servindo: design, funcionalidade, complexidade, testes, nomenclatura, comentários, estilo, documentação. Olhe a lista e pergunte, item por item, qual deles seu pipeline hoje realmente verifica. Testes e estilo, provavelmente. Complexidade e design, quase certamente não.

Fecho com a dose de humildade que o Holland oferece e que se aplica a tudo que está escrito aqui, inclusive à minha própria confiança nisso:

“Ninguém realmente sabe o que está fazendo agora. Estamos todos descobrindo à medida que andamos. Muito do que hoje é encantamento mágico da IA vai ser o anti-pattern de amanhã.”

O desconforto do Carlini não é um problema a ser resolvido antes de publicar. É a postura epistêmica correta para o momento.

Referências