Agentes de IA estão matando a revisão de código — O problema do principal-agente explicado

O processo de revisão de código padrão da indústria — revisar-depois-commitar, popularizado pelos PRs do GitHub — foi projetado para colaboração de baixa confiança. Um humano faz uma alteração, outro humano a revisa, iterações ocorrem e a alteração é incorporada. Isso funcionava porque os revisores podiam inferir facilmente esforço e compreensão a partir da leitura do código. Agentes de IA quebram isso completamente.

O desastre do agente no meio

O melhor cenário com agentes de IA: um humano instrui uma máquina a escrever código, o humano revisa o código e depois o envia a um segundo humano para revisão tradicional. Isso dobra a carga de revisão. Pior, os agentes aumentam o volume total de alterações. O resultado: a largura de banda de revisão se esgota antes mesmo que uma fração dos ganhos de produtividade dos agentes se materialize.

Mas a realidade é pior. O padrão real é: o humano digita um prompt curto, verifica superficialmente a saída, empacota como um PR e depois direciona os comentários do revisor de volta ao agente para correções. Isso é um caso clássico de problema principal-agente: o revisor (principal) não consegue mais inferir esforço ou compreensão a partir do código, porque o código foi gerado por uma máquina. O humano que comanda o agente não tem incentivo para realmente ler o código ou pensar criticamente sobre o feedback do revisor. Eles gastam 5 minutos e geram uma carga de revisão séria para outro engenheiro.

Isso é o que está matando o código aberto — "PRs lixo" de pessoas que não têm compreensão do projeto, de suas restrições ou de suas ferramentas.

Um caminho para equipes pequenas

Para equipes pequenas de alta confiança, há um processo mais simples: humano instrui o agente → humano revisa o código → humano faz o deploy diretamente (sem um segundo revisor). O humano que comanda a máquina assume total responsabilidade ao possuir o deploy. O problema principal-agente desaparece porque o humano é tanto o condutor quanto o implantador.

Na exe.dev, uma equipe de nove pessoas usa essa abordagem com sucesso. Práticas-chave: escrever muito mais testes de integração e ponta a ponta, construir fluxos de trabalho baseados em agentes para analisar commits em busca de bugs de segurança/desempenho/usabilidade e garantir que um humano seja sempre responsável pelo deploy final.

O modelo tradicional de revisão de código não é recuperável com agentes. Equipes pequenas podem se adaptar; grandes organizações e projetos de código aberto enfrentam um problema estrutural mais difícil.