Um teste verde ainda não é prova
A intuição sugere algo simples: se toda a suíte de testes passou, o trabalho está feito. Um preprint recente quebra essa intuição com um exemplo pequeno, quase de brinquedo. Dois agentes receberam a mesma tarefa de reconstruir um aplicativo. O primeiro seguiu disciplinadamente as regras do processo — e falhou no teste que estava guardado e não foi mostrado durante o trabalho. O segundo ignorou as regras, mas fechou todo o conjunto visível de verificações sem um único erro.
A conclusão é desagradável, mas útil: a suíte de testes descreve não a correção do aplicativo, mas a fronteira que se conseguiu contornar. Quando a verificação e a implementação crescem a partir da mesma descrição, nada impede o agente de ajustar o código às expectativas da verificação em vez da própria tarefa. Um painel verde, nessa situação, é o autorrelato do sistema sobre si mesmo, e não uma medição independente.
Por isso o autor do trabalho desloca o foco: a questão não é escrever instruções mais inteligentes para o modelo, mas fazer com que parte das afirmações se torne verificável por máquina, ou seja, algo que não se possa contornar com conversa.
A interface é fixada antes de a primeira linha de código ser escrita
O ponto de partida é uma observação de pesquisas anteriores: assim que o modelo se torna suficientemente forte, um pipeline complexo de reconstrução com múltiplos agentes começa a perder para o cenário mais primitivo. Basta entregar ao modelo o código-fonte mais uma instrução — é mais ou menos assim que funciona a abordagem AgentModernize — e o resultado acaba não sendo pior, e às vezes até melhor, do que o de um esquema com papéis, revisores e etapas intermediárias.
A resposta do autor é a ferramenta rebuild-dossier. Sua lógica é esta: primeiro fixar a interface real do aplicativo, isto é, suas entradas e saídas exatas, e só então permitir que se escreva código. A montagem avança um teste por vez, e cada etapa passa por verificações automatizadas, e não por acordos escritos no espírito de "não esqueça de garantir que…".
A diferença é fundamental. Uma instrução no prompt é um pedido. Um script que confere assinaturas e resultados é uma restrição. Um pedido pode ser violado sem que se perceba; uma restrição ou passa, ou não passa, e isso é visível de fora.
Cabe aqui uma ressalva fácil de passar despercebida: os autores não mediram um efeito separado da própria fixação da interface — esse elemento foi verificado à parte e não participou da comparação. Portanto, a conclusão "basta fixar o contrato e tudo funcionará" não decorre do trabalho.
Três níveis de verificação em vez de um único relatório do agente
A parte mais prática do trabalho não é sobre a arquitetura dos agentes, mas sobre como atestar fatos. Cada afirmação sobre o andamento da reconstrução é conferida em três lugares ao mesmo tempo: o que o agente escreveu sobre seu próprio trabalho, o que o log automático registrou e o que de fato apareceu no sistema de arquivos após a execução.
Cada nível tem seu ponto cego. O agente pode errar no relatório, ou pode embelezá-lo. O log registra eventos, mas depende do que se decidiu registrar. A lista de arquivos não mente, mas silencia sobre o significado das mudanças. A divergência entre as três imagens é justamente o sinal pelo qual tudo isso foi concebido.
Não é uma precaução teórica: a conferência revelou defeitos reais, incluindo um bug no código de logging escrito pelos próprios autores. Um único nível — por exemplo, a confiança incondicional no log — simplesmente não teria notado esse erro. A lição se aplica a qualquer pipeline agêntico: se você tem um único canal de observabilidade, você mede, antes de tudo, o seu próprio erro.
Modelo fraco e aplicativo grande: onde a construção tropeça
A segunda questão era esta: todo esse mecanismo se paga em comparação com a linha de base — dar a um modelo mais fraco o código-fonte e uma instrução? Em um aplicativo pequeno, registrou-se um empate. Em um maior, uma derrota evidente, e a verificação automatizada nem sequer foi executada ali. Ou seja, foi justamente o circuito de controle que deveria trazer a vantagem que falhou.
A leitura é esta: o que faz a diferença não é a fixação da interface, mas o mecanismo de verificação, que nessa execução não funcionou. Quanto maior o projeto e quanto menos se confia que a automação funcionará como planejado, mais cautela se deve ter com promessas de que "o processo colocará tudo nos eixos".
Um enredo à parte é a portabilidade. Os riscos se reproduzem em outro modelo e outra cadeia de ferramentas: o modelo mais forte passou pelo processo três vezes seguidas, o mais fraco, nenhuma. Para a ideia de "pegar um modelo acessível e o mesmo pipeline", isso é uma má notícia: a disciplina do processo acaba sendo uma função das capacidades do modelo, e não uma propriedade da instrução.
O que se conclui disso na prática
- Não considere testes verdes como prova. Pergunte primeiro quem escreveu esses testes e se é possível contorná-los sem violar nada em essência.
- Mantenha um conjunto de verificações reservado. Parte dos testes deve ficar inacessível ao agente durante o trabalho — caso contrário, ele otimizará exatamente para eles.
- Extraia o contrato para um artefato separado. Entradas e saídas antes do código, e não em comentários ao longo do caminho. Mas lembre-se de que só esse passo pode não bastar para obter ganho.
- Um teste por etapa. A granularidade fina torna a falha local e compreensível.
- Confira no mínimo três fontes: o relatório do agente, o log de máquina, o estado real dos arquivos. A divergência importa mais que a coincidência.
- Teste em outro modelo e outro ferramental. Se o processo se sustenta apenas no modelo mais forte, você não tem um processo, mas uma propriedade dele.
- Distinga o peso das evidências. No trabalho, três resultados têm sustentação desigual: em um ponto, uma comparação pequena; em outro, uma observação. Não transforme uma única demonstração bem-sucedida em padrão do setor.
Que trabalho é este e quanto confiar nele
Trata-se do preprint «Rebuild Dossier: Mechanically-Enforced Specs for Agentic App Rebuilds, and What Model-Tier Failures Reveal» (arXiv:2608.23616, seção cs.SE): versão v1 de 22 de agosto de 2026, v2 de 26 de agosto. Autor: Parker Fawcett. Extensão: 48 páginas, uma ilustração. A ferramenta é aberta sob licença MIT e se reproduz de ponta a ponta nos aplicativos dos próprios autores; o código e os artefatos de avaliação estão publicados à parte, com DOI próprio.
O principal valor aqui não está em uma receita pronta, mas na demonstração honesta de como exatamente um resultado "verde" engana e quantas camadas de verificação são necessárias para captar a divergência. As limitações também são nomeadas com franqueza: comparações compactas, peso desigual entre os três resultados, dependência da disciplina do processo em relação à força do modelo. Vale ler isso como um conjunto de hipóteses verificáveis e uma ferramenta útil, e não como uma metodologia definitiva de reconstrução de aplicativos por agentes.
