Agentes de IA para programar não são assistentes. Veja o que muda de verdade quando você faz a troca

Você pediu algo pequeno ao seu agente de IA: “Adicione soft delete às faturas.” Dez minutos depois, você tem um pull request. Catorze arquivos alterados, uma migration, queries atualizadas, testes novos, tudo verde.

Você lê o diff do jeito que vem lendo código gerado por IA nos últimos dois anos: linha por linha, procurando algo estranho. Não tem nada estranho. Você aprova.

Duas semanas depois, o financeiro pergunta por que estão faltando faturas no relatório de conciliação do mês passado. Nenhuma linha daquele pull request estava errada. O problema estava numa decisão que o agente tomou sozinho, e nada na sua revisão foi pensado para pegar decisões.

O que um agente de IA para programar faz de diferente

Por muito tempo, a conversa sobre ferramentas de IA para programar girou em torno da qualidade das sugestões. Com que frequência o autocomplete acerta? Ele entende a função ao redor? Vale mais aceitar e corrigir, ou digitar você mesmo?

Essa conversa fazia sentido quando a ferramenta sugeria algumas linhas por vez. Você continuava sendo o autor. A intenção estava na sua cabeça, você via cada sugestão no contexto e aceitava ou descartava em um segundo.

Um agente de IA para programar trabalha em outro nível. Você dá um objetivo. Ele lê o codebase, escolhe os arquivos que vai mexer, decide como implementar a mudança, escreve os testes e te entrega um resultado pronto. No caminho, ele toma dezenas de pequenas decisões de design, e você não viu nenhuma delas acontecer.

Essa é a mudança de verdade. A pergunta deixa de ser “essa sugestão é boa?” e passa a ser “o que ele decidiu enquanto eu não estava olhando?”.

Por que os reflexos do autocomplete não dão conta

Revisar autocomplete treinou um conjunto específico de reflexos. Compila? O nome está claro? Tem um off-by-one? Tratou o null? Essas checagens funcionam no nível da linha ou da função, porque era ali que o autocomplete errava.

Raramente é ali que o trabalho de um agente parece errado. O código costuma estar limpo, segue o estilo dos arquivos ao redor e vem com testes passando. Revise com reflexos de linha e ele passa, porque esse é o nível em que ele parece mais sólido.

Os agentes erram um nível acima: na forma como interpretaram o pedido. O que conta como “pronto”. Quais chamadas existentes devem ver o novo comportamento. Qual padrão existente copiar.

Seu pedido não respondia nada disso, então o agente preencheu as lacunas por conta própria. Ele se apoiou no treinamento, como um desenvolvedor se apoia na experiência, ou no que apareceu nas suas conversas anteriores com ele. Essas escolhas não parecem erros num diff. Parecem código perfeitamente razoável.

Isso não acontece só com você. Um estudo de 2026 sobre pull requests gerados por IA (More Code, Less Reuse, MSR 2026) descobriu que os revisores reagiam a eles de forma mais neutra ou positiva do que aos de pessoas, mesmo com esse código trazendo mais redundância. Código com cara de limpo ganha muita confiança.

Também tem um problema de volume. Ler linha por linha uma mudança de catorze arquivos exige muita atenção, e lá pelo nono arquivo a maioria já está lendo por cima. Um reflexo feito para três linhas sugeridas não escala para uma mudança que você não escreveu e não viu sendo escrita.

O que o agente assumiu no exemplo das faturas

Volte ao soft delete. Para construí-lo, o agente teve que responder perguntas que você nunca fez em voz alta:

• Faturas excluídas devem sumir de todo lugar? Ele decidiu que sim e adicionou um filtro deleted_at IS NULL ao query scope compartilhado. O job noturno de conciliação usa esse mesmo scope.
• O que acontece com a unicidade do número da fatura? Ele mudou o índice único para ignorar as linhas excluídas, então outra fatura pode reaproveitar um número excluído. Seu contador provavelmente vai ter opiniões sobre isso.
• Faturas excluídas podem voltar? Ele adicionou um endpoint de restauração, porque o exemplo mais próximo no codebase, uma tabela customers com soft delete, tinha um.
• O que os testes provam? Provam que a interpretação do agente funciona. Não verificam a sua, porque o agente os escreveu a partir da própria leitura da tarefa.

Cada uma dessas é uma escolha defensável, e algumas provavelmente estão certas. Mesmo assim, são decisões de design, e nesse pull request ninguém as tomou de propósito. Um diff mostra o que mudou. Ele não consegue dizer quais dessas mudanças foram escolhas.

Quem revisa código de agentes descreve a mesma coisa. Num estudo de julho de 2026 baseado em threads do Reddit e blogs de engenharia sobre code review, um deles explica que código gerado por IA é mais difícil de revisar porque “você está reconstruindo a intenção”.

Revise primeiro as suposições, depois as linhas

Você continua lendo o diff. Só para de começar por ele. Estes hábitos levam a revisão para o nível em que os agentes erram:

1. Peça as suposições antes do código. Faça o agente escrever primeiro um plano curto: o que vai mudar, o que está assumindo e o que está deixando de fora. Revisar cinco frases de intenção é mais rápido do que revisar catorze arquivos, e é o momento mais barato para corrigir o rumo.
2. Pergunte de novo depois do código. Quando a mudança estiver pronta, peça ao agente para listar cada decisão que tomou e que o seu pedido não especificava. Ele não vai pegar todas. Vai mostrar as que conhece, e isso te dá uma lista para checar em vez de um diff para varrer.
3. Comece pelos arquivos que você não esperava. Antes de ler linha por linha, veja quais arquivos mudaram. Um query scope compartilhado, uma classe base, um arquivo de configuração, uma migration numa tabela que você nunca mencionou: é ali que moram as decisões de maior alcance. Helpers novos também contam. Os agentes costumam escrever um utilitário novo em vez de reaproveitar o que você já tem, o que significa que assumiram que não existia nada que servisse.
4. Leia os testes como uma spec. Pergunte “esses são os comportamentos que eu queria?” antes de perguntar “eles passam?”. Uma suíte de testes que o agente escreveu descreve o que o agente achou que era a tarefa. Confira também se o agente não apagou, pulou ou afrouxou nenhum teste existente para chegar ao verde. O METR documentou casos de modelos de fronteira que modificavam testes para tirar notas mais altas em tarefas de programação.
5. Anote as restrições que ele continua deixando passar. A maioria dos agentes lê um arquivo de regras do projeto (CLAUDE.md, AGENTS.md ou uma pasta de regras, dependendo da ferramenta). Quando uma revisão revelar uma suposição que vai voltar, como “relatórios sempre incluem faturas excluídas”, registre ali para que a próxima mudança já comece com ela.

Onde a seniority aparece na revisão de agentes

Nada disso é uma habilidade nova. É o que um bom revisor já faz com o pull request de um engenheiro rápido e confiante que entrou no mês passado: primeiro confere o que ele entendeu da tarefa, depois confere o código. A diferença é que agora você faz isso várias vezes por dia.

Isso também explica por que os agentes deixam a revisão mais exigente. O agente escreve o código. O contexto que falta para ele (por que a conciliação depende daquele scope, por que números de fatura nunca podem se repetir) é exatamente o que um engenheiro sênior carrega consigo. Já escrevemos sobre como o pull request é onde a seniority aparece (em inglês). É o mesmo critério que analisamos em o que realmente mede um engenheiro sênior quando todos usam agentes de IA, aplicado a um novo tipo de autor.

Então, na próxima vez que um agente te entregar um pull request limpo e verde, faça uma pergunta a si mesmo antes de abrir o diff: o que ele teve que assumir para construir isso? Se você não souber responder, é ali que sua revisão começa.