Pipeline de 7 Etapas para Verificar Código Escrito por Agentes de IA

Esse é o tema mais quente do momento. Agentes estão gerando centenas de commits por dia, e ninguém consegue revisar todos eles.

Peter, um desenvolvedor da OpenClaw, às vezes faz mais de 3.000 commits em um único dia. Isso está muito além do que qualquer humano consegue processar. Tornou-se uma tarefa que os humanos simplesmente não conseguem mais lidar sozinhos.

A princípio, achei que não havia solução. Então li o “Code Factory” de Ryan Carson e o quadro se encaixou. Em vez de tentar ler tudo, você constrói uma estrutura onde máquinas verificam o código.

Defina as regras de merge em um único arquivo JSON

Escreva quais caminhos são de alto risco e quais verificações precisam passar, tudo em um só arquivo. O insight principal é que isso evita que a documentação e os scripts fiquem fora de sincronia.

• Caminhos de alto risco exigem um Review Agent mais evidências via navegador
• Caminhos de baixo risco podem ser mergeados após passar pelo policy gate e o CI

Execute verificações de qualificação antes do CI

Rodar builds em PRs que nem passaram pela revisão é jogar dinheiro fora. Coloque um risk-policy-gate na frente do CI fanout. Isso sozinho reduz significativamente os custos desnecessários de CI.

• Ordem fixa: policy gate → confirmação do Review Agent → CI fanout
• PRs não qualificados nunca chegam à etapa de testes/build

Nunca confie em um “passou” de um commit desatualizado

Esse foi o ponto que Carson mais enfatizou. Se um “passou” de um commit antigo fica parado, o código mais recente é mergeado sem verificação. Execute as revisões novamente a cada push e bloqueie o gate se elas não coincidirem.

• Um Review Check Run só é válido quando corresponde ao headSha
• Force uma reexecução a cada evento synchronize

Emita pedidos de reexecução de exatamente uma fonte

Quando vários workflows solicitam reexecuções, surgem comentários duplicados e race conditions. Parece trivial, mas se você não resolver isso, o pipeline inteiro fica instável.

• Evite duplicatas com o padrão Marker + sha:headSha
• Ignore a solicitação se o SHA já foi enviado

Deixe os agentes cuidarem das correções também

Quando o Review Agent encontra um problema, o Coding Agent aplica o patch e faz push para o mesmo branch. O insight mais aguçado do post do Carson: fixe a versão do modelo. Caso contrário, você obtém resultados diferentes a cada vez e a reprodutibilidade vai por água abaixo.

• Codex Action corrige → push → aciona reexecução
• Versões de modelo fixadas garantem reprodutibilidade

Feche automaticamente apenas conversas entre bots

Nunca mexa em threads onde um humano participou. Sem essa distinção, comentários de revisores acabam sendo soterrados.

• Auto-resolva apenas após uma reexecução limpa no head atual
• Threads com comentários humanos ficam abertas, sempre

Deixe evidências visíveis e verificáveis

Se a UI mudou, não basta tirar um screenshot. Exija evidências verificáveis pelo CI. Transforme incidentes de produção em casos de teste para que a mesma falha nunca se repita.

• Regressão → issue de gap no harness → adicionar caso de teste → rastreamento de SLA

As escolhas de ferramentas do Carson

Para referência, veja o que Carson selecionou: Greptile como agente de revisão de código, Codex Action para remediação, e três arquivos de workflow que fazem o trabalho pesado greptile-rerun.yml para reexecuções canônicas, greptile-auto-resolve-threads.yml para limpeza de threads desatualizadas, e risk-policy-gate.yml para a política de preflight.

Além da correção: verificação visual

Tudo acima verifica se o código está certo ou errado. Mas na prática, você também precisa verificar como a saída está visualmente.

Duas abordagens se destacam.

O visual-explainer de Nico Bailon renderiza diffs do terminal como páginas HTML em vez de ASCII, tornando os conjuntos de mudanças imediatamente legíveis de relance.

O agent-browser de Chris Tate segue uma direção diferente. Ele compara telas reais do navegador pixel a pixel para detectar quebras de CSS e layout. Combinado com bisect, consegue identificar exatamente qual commit causou a regressão.

Tenho pensado nisso enquanto construo o codexBridge. Rastrear qual agente escreveu qual código não é suficiente apenas com logs de sessão. Você precisa de uma estrutura de busca que facilite a recuperação das informações.

Conclusão

A resposta para “quem verifica o código escrito por agentes” não são os humanos. É uma estrutura onde máquinas julgam as evidências que máquinas produziram. Essa é a resposta.