Código escrito por agentes apaga o rastro das tentativas que o geraram

O problema: o rastro que desaparece

Paul Stack, em artigo da série sobre agentes e CI, argumenta que quando um agente de código assume o ciclo de verificação e correção antes do merge, o histórico de iteração se perde. O agente produz uma implementação, os testes falham, ele interpreta os erros, modifica o código, repete o processo até que tudo passe. A atestação final registra apenas o estado terminal: os controles que rodaram, seus resultados, a configuração vigente e o commit final. O caminho até lá - falhas encontradas, interpretações, mudanças intermediárias descartadas - desaparece quando a verificação tem sucesso.

Para fins de entrega, o resultado terminal é o que importa. Para fins de governança, não: quando um incidente de produção remete a uma mudança feita por agente, as perguntas são sobre o caminho. O agente encontrou uma falha relacionada e a contornou em vez de corrigir a causa raiz? A revisão sinalizou o problema e ele o tratou incorretamente? A configuração de verificação não cobria a categoria de teste relevante? Em código humano, esses rastros existem: histórico de commits, conversas de PR, threads de Slack, memória do revisor. Em loops de verificação por agente, resta um commit final e uma atestação.

Responsabilidade não é a parte difícil

Stack rejeita a tese de que há um vácuo de responsabilidade no nível do praticante. Stanford Law's CodeX publicou em fevereiro uma análise enquadrando o tema como um vazio de responsabilidade difuso entre engenheiros, provedores de modelo e fornecedores - e ele concede que, na fronteira fornecedor-cliente, os marcos legais são de fato subdesenvolvidos. Mas no nível do praticante a resposta é clara: quem instruiu o agente, definiu os critérios de verificação e decidiu entregar responde pelo resultado, como responderia por qualquer ferramenta.

O problema real é outro: se essa pessoa precisa investigar o que deu errado, ela precisa responder perguntas específicas sobre o que o agente tentou, o que falhou e por que concluiu que a mudança era segura. Para times que usam agentes de código hoje, essa evidência em grande parte não existe. O autor cita o modelo de "Software Factory" da StrongDM, em que agentes escrevem e testam código contra um ambiente gêmeo digital sem revisão humana, e cuja descrição publicada não aborda trilhas de auditoria das decisões dos agentes nem como erros de especificação se propagam. A economia empurra os times para menos envolvimento humano, não mais, tornando o registro ausente mais importante, não menos.

O que é proveniência de iteração

O autor distingue a proposta de duas propriedades já estabelecidas nos posts anteriores. Integridade de configuração pergunta se as regras e prompts esperados governaram a execução; integridade de resultado pergunta se os controles realmente executaram e produziram o resultado alegado - o que, segundo ele, não é totalmente provável apenas pela atestação, e para maior garantia exige execução em infraestrutura independente. A proveniência de iteração responde uma pergunta diferente: o que aconteceu no caminho.

Ela não prova que a execução foi honesta nem que a interpretação do agente estava correta; torna o processo auditável depois. Um levantamento recente sobre proveniência de execução em agentes de LLM distingue proveniência de execução (o registro completo da execução) de rastreamento de evidência (a projeção sobre quais evidências sustentaram quais decisões) - e a camada de governança precisa da segunda, não da primeira.

O que o registro deve conter

Stack propõe quatro elementos: identidade e conteúdo da configuração (qual sistema agente, versão do modelo e conjuntos de instruções governaram a execução, com o conteúdo dos prompts duravelmente recuperável, não apenas checksums que confirmem a correspondência); histórico de iteração estruturado, vinculando falhas observadas a mudanças e repetições, sem tratar o raciocínio diagnóstico do agente como conclusão confiável; metadados de cobertura de verificação, que indiquem o que os controles podiam e não podiam capturar, para distinguir "verificado e seguro" de "verificado contra um conjunto incompleto de checagens"; e proveniência da revisão, registrando qual prompt governou a revisão, o que foi examinado e como os apontamentos foram resolvidos.

A infraestrutura existente aponta para o lado errado

A comunidade de segurança da cadeia de suprimentos construiu em mais de uma década uma base madura - in-toto, SLSA, Binary Authorization for Borg do Google, Sigstore - que assume código escrito por humanos e trata a etapa de autoria como uma asserção única: um humano submeteu via code review. Quando a autoria tem estrutura interna que vale registrar, a cadeia precisa se estender para trás. Os conceitos arquiteturais já existem; aplicá-los ao loop de verificação por agente é uma extensão, não uma invenção.

O menor registro útil: tornar cada execução de agente reconstrutível, retendo para cada tentativa o diff de entrada e saída, os checks executados e suas falhas, o modelo e a configuração, e o elo para a tentativa seguinte, amarrando a sequência à atestação final. Assinar o registro torna adulterações detectáveis; controles em ambiente endurecido dão garantia maior - mas nada disso ajuda se o histórico foi descartado. A conclusão: se um agente pode corrigir o próprio trabalho até obter resultado verde, o histórico dessas correções precisa ser artefato de primeira classe da mudança de software, retido ao lado do código, dos testes e da atestação.