Revisor de IA precisa saber parar, não apenas encontrar mais problemas

A InfoQ relata que uma mudança na equipe do Claude Code passou por mais de 50 rodadas noturnas de revisão e correção antes de o autor interromper o processo.[5] Ao investigar os apontamentos, o time encontrou cerca de 59% deles em código que já existia desde a primeira passagem do revisor, e não em novos problemas introduzidos a cada rodada.[5]

O problema de engenharia não é apenas a qualidade de uma sugestão. É o comportamento do circuito inteiro: revisar, corrigir, criar outro commit e revisar novamente. Um sistema que não sabe encerrar uma discussão pode produzir muita atividade sem convergir.

O que muda para quem desenvolve

A equipe afirma ter aproximadamente 90% do código do Claude Code escrito pelo próprio Claude e busca integrar a maioria das mudanças com no máximo um humano no circuito, que pode ser o autor.[5] Esse é o processo relatado, não uma demonstração de que retirar revisores humanos serve para qualquer projeto.

A reportagem também descreve uma explicação gerada sobre encerramento automático de issues que não correspondia ao comportamento implementado.[5] Minha conclusão prática é separar três coisas: explicação do código, evidência de comportamento e autorização para aceitar a mudança. Uma resposta convincente não deve ocupar os três papéis.

Como aplicar

Desenhe o bot de revisão como um processo com orçamento e condição de parada. Comece com um limite pequeno de rodadas automáticas; ao atingir o limite, peça uma decisão humana em vez de gerar outro commit.

Para cada apontamento, exija localização, comportamento observado, impacto e uma forma de reprodução ou verificação. Classifique se o problema foi introduzido pela mudança ou se já fazia parte da base. Dívida anterior pode merecer correção, mas não precisa transformar toda revisão em uma refatoração sem fim.

Um experimento útil é selecionar mudanças já encerradas e pedir revisão sem permissão de escrita. Compare os apontamentos com os defeitos conhecidos, registre falsos positivos e avalie quantos exigem trabalho para serem descartados. Só depois considere autorizar correções.

Trate alterações em instruções de agentes como mudanças de comportamento. Não as aprove automaticamente só porque o arquivo parece documentação.

Cuidados e limites

No processo descrito, aprovação de agente não conta como aprovação humana, e áreas como cache, atualizador e prompts de sistema exigem uma pessoa.[5] A equipe também reconhece ainda não possuir mecanismos automáticos para endurecer aprovações quando métricas pioram.[5]

A ação aberta de revisão de segurança traz uma ressalva explícita: não foi endurecida contra injeção de prompt e deve revisar apenas solicitações confiáveis.[5] Portanto, não a trate como uma autorização genérica para processar contribuições externas com acesso a segredos.

Minha recomendação é manter isolamento e revisão humana nas fronteiras de confiança. Um revisor automatizado precisa justificar um apontamento e aceitar uma decisão de encerramento. Insistência não é evidência de qualidade.

Fonte

[5] Fonte: InfoQ