O patch do agente passou; o produto ainda quebrou

Evals de regressão para agentes de código respondem a uma pergunta que o teste da tarefa não cobre: o patch preservou o que já funcionava? Codex, Claude Code e outros agentes podem acertar o bug visível e ainda quebrar contrato, integração, permissão, migração ou comportamento distante.

Em 2026, o artigo "TDAD: Test-Driven Agentic Development" avaliou agentes em SWE-bench Verified e relatou redução de 70% em regressões no nível de teste com análise de impacto baseada em grafo (arXiv, "TDAD: Test-Driven Agentic Development", 2026). A lição prática é simples: regressão precisa ser métrica do agente, não acidente descoberto pelo revisor.

Resumo prático

• Evals de regressão medem preservação, não só resolução.
• O CI deve escolher testes por impacto, risco e histórico.
• O agente recebe feedback curto, mas para quando repete a falha.
• O PR precisa carregar evidência de teste antes da revisão humana.

Por que regressão precisa virar métrica do agente?

Em 2026, o TDAD relatou 562 falhas de testes que antes passavam em 100 instâncias de baseline, com média de 6,5 testes quebrados por patch gerado (arXiv, "TDAD: Test-Driven Agentic Development", 2026). Isso muda a conversa: passar no teste da issue não prova que o produto continuou inteiro.

O erro comum é tratar agente como autor rápido e CI como carimbo final. Para código humano, isso já é frágil. Para código gerado por IA, fica pior porque o agente pode otimizar a evidência que você mostrou e ignorar dependências que não viu.

O eval de regressão deve ficar ao lado do eval de resolução. Um mede se a tarefa foi resolvida. O outro mede se comportamento previamente aceito continuou aceito. Quando os dois entram no mesmo gate, o revisor recebe um PR menor e com risco mais explícito.

Cápsula citável: Evals de regressão para agentes de código tornam preservação uma métrica de CI. O TDAD relatou 562 falhas de testes previamente aprovados em 100 instâncias de baseline; portanto, o patch agentic deve provar que corrigiu a tarefa sem quebrar contratos existentes.

Esse texto complementa evals de PR para agentes no CI. A diferença é o alvo. Ali, o foco é o pacote mínimo de revisão. Aqui, o foco é o conjunto de provas que impede o agente de vencer o teste estreito e perder o sistema.

O que entra numa suite de regressão para agentes?

Em 2026, a Anthropic separou evals de capacidade de evals de regressão: os primeiros devem começar com baixa taxa de aprovação, enquanto regressões devem ficar perto de 100% para detectar retrocesso (Anthropic, "Demystifying evals for AI agents", 2026). Para agentes de código, essa distinção vira contrato operacional.

Uma suite mínima tem quatro camadas. A primeira é determinística: testes que precisam passar. A segunda é estrutural: quais arquivos, símbolos e contratos o patch tocou. A terceira é comportamental: que fluxo de produto pode ter mudado. A quarta é processual: o agente seguiu limites de ferramenta, contexto e tentativa?

Use uma ficha curta por tarefa. Ela deve declarar o teste obrigatório, os testes de regressão esperados, o comando de verificação, o risco aceito e o critério de parada. Se a ficha não cabe no PR, ela provavelmente não cabe no loop agentic.

agent_regression_eval:
  required_task_tests:
    - tests/auth/password_reset.test.ts
  impacted_regression_tests:
    - tests/auth/session_contract.test.ts
    - tests/billing/webhook_idempotency.test.ts
  stop_rule: "parar quando a mesma regressao falhar duas vezes"
  evidence:
    - diff_summary
    - commands_run
    - failing_then_passing_output

Cápsula citável: A Anthropic recomenda tratar evals de regressão como proteção contra retrocesso, com taxa esperada próxima de 100%. Em agentes de código, isso se traduz em testes determinísticos, rubrica de qualidade, análise de tool use e evidência curta no PR.

Quando o loop fica longo e atravessa logs, subagentes e histórico de tentativas, eu uso o RemoteCode para manter continuidade em fluxos agentic de Codex e Claude Code com menos repetição de contexto. É uma ferramenta minha, então a menção aqui é editorial e ligada ao custo real de carregar evidência sem inflar o prompt.

Como escolher testes sem rodar a suite inteira?

Em 2026, o TDAD combinou grafo código-teste e análise de impacto para reduzir regressões no nível de teste em 70% (arXiv, "TDAD: Test-Driven Agentic Development", 2026). O ponto não é copiar a ferramenta. É adotar a ideia: o agente precisa saber quais testes distantes representam o risco do diff.

Rodar tudo sempre parece seguro, mas escala mal em monorepos, suites lentas e pipelines pagos. Rodar só o teste perto do arquivo também falha. A saída pragmática é montar uma seleção por impacto que combine dependência estática, histórico de falhas, cobertura, ownership e contratos compartilhados.

Comece com regras simples. Se o agente tocou autenticação, rode testes de sessão e permissão. Se tocou serialização, rode consumidores. Se mudou schema, rode migração, rollback e contrato de API. Depois amadureça para grafo, cobertura e sinais de produção.

Cápsula citável: Seleção de testes para agentes não deve depender só de proximidade de arquivo. O TDAD mostrou que dependências indiretas explicam regressões perdidas; por isso, CI agentic precisa combinar grafo, histórico e risco do domínio antes de devolver feedback ao agente.

Esse padrão conversa com RAG sobre codebase para agentes. RAG ajuda o agente a editar. Evals de regressão ajudam o pipeline a decidir se a edição preservou comportamento.

Onde o agente recebe feedback e onde deve parar?

Em 2026, a Anthropic usou exemplos de evals de coding agents com testes determinísticos, rubricas, análise estática, estado esperado e métricas de transcript (Anthropic, "Demystifying evals for AI agents", 2026). Esse modelo separa feedback útil de permissão infinita.

O agente deve receber o menor log que explica a regressão. Inclua comando, teste, trecho de erro, arquivo provável e regra de escopo. Não entregue a saída inteira da suite se só uma falha importa. O objetivo é reparar, não reabrir a investigação do zero.

Pare o loop quando a mesma regressão falhar duas vezes pelo mesmo motivo, quando o agente ampliar o escopo sem justificativa ou quando a correção exigir decisão de produto. Autonomia sem critério de parada vira uma sequência de patches plausíveis.

Cápsula citável: Feedback de regressão deve ser curto e executável: comando, teste, erro, arquivo provável e limite de escopo. Se a mesma falha reaparece, o agente deve parar, porque a próxima tentativa tende a aumentar diffs sem aumentar confiança.

Para a parte de reparo depois da falha, use o fluxo descrito em loop self-correcting de agente no CI. O eval decide se houve regressão. O loop decide se existe uma tentativa segura de correção.

Como registrar evidência de regressão no PR?

Em 2026, a OpenAI mostrou um fluxo de code review com Codex em CI usando saída JSON estruturada, arquivo de resultado e comentários no sistema de controle de código (OpenAI Developers, "Build Code Review with the Codex SDK", 2026). A mesma disciplina serve para regressão.

O PR deve mostrar três coisas. Primeiro, qual risco foi avaliado. Segundo, quais testes cobriram esse risco. Terceiro, qual evidência mudou depois do patch. Se o agente só escreve "testes passaram", o revisor ainda precisa reconstruir o raciocínio.

Prefira um artefato pequeno no CI. Ele pode ser comentário, resumo de job ou arquivo anexado. O formato deve sobreviver à troca de ferramenta: Codex hoje, Claude Code amanhã, outro agente depois. O contrato é mais importante que o fornecedor.

{
  "regression_eval": {
    "risk": "contrato de sessao alterado",
    "commands": ["npm test -- session_contract"],
    "result": "passed",
    "retry_count": 1,
    "human_review_needed": false
  }
}

Cápsula citável: Evidência de regressão em PR agentic deve ser estruturada. A OpenAI demonstra revisão com Codex em CI por meio de saída JSON; para regressão, o mesmo padrão registra risco, comando, resultado, tentativas e necessidade de revisão humana.

Isso reduz o trabalho descrito em PRs de agentes que falham antes do merge. O revisor ainda julga arquitetura e produto, mas não precisa descobrir se a regressão óbvia foi sequer testada.

Qual implementação mínima cabe nesta semana?

Em 2026, o GitLab relatou que 85% dos respondentes concordam que a IA deslocou o gargalo de escrever código para revisar e validar código (GitLab, "AI Accountability Report", 2026). A implementação mínima deve atacar esse gargalo, não criar um laboratório perfeito.

Comece com um arquivo versionado de regras por área crítica. Mapeie domínio para testes de regressão. Depois adicione um job de CI que lê o diff, escolhe a regra, roda os comandos e publica evidência. Só então permita que o agente tente corrigir uma falha.

Para equipes pequenas, três categorias bastam na primeira semana: autenticação, persistência e integração externa. Elas concentram contratos difíceis de revisar no olho. Se o agente toca uma dessas áreas, o CI exige regressão específica antes de liberar revisão.

Cápsula citável: A primeira versão de evals de regressão não precisa de grafo perfeito. Com regras versionadas por domínio, comandos determinísticos e evidência no PR, o time já reduz o gargalo que o GitLab identificou: validação de código gerado por IA.

Depois refine com context engineering para agentes de código. O melhor eval não despeja tudo no agente. Ele entrega apenas a falha, o contrato e a evidência necessária para uma correção pequena.

FAQ sobre evals de regressão para agentes

Evals de regressão substituem code review?

Não. Em 2026, o GitLab mediu 85% dos respondentes vendo revisão e validação como novo gargalo do código com IA (GitLab, "AI Accountability Report", 2026). Evals reduzem incerteza mecânica, mas arquitetura, produto e risco residual continuam humanos.

Preciso de grafo código-teste desde o primeiro dia?

Não. Em 2026, o TDAD mostrou 70% menos regressões de teste com grafo e impacto (arXiv, "TDAD: Test-Driven Agentic Development", 2026). Esse é o alvo maduro. A primeira versão pode ser uma tabela por área crítica, desde que rode comandos reais e publique evidência.

O agente deve corrigir regressão automaticamente?

Só com limite. Em 2026, a Anthropic recomenda evals com testes, rubricas e métricas de transcript para agentes de código (Anthropic, "Demystifying evals for AI agents", 2026). Permita uma tentativa pequena. Se a falha repetir, pare e peça revisão humana.

Como isso se encaixa com Claude Code e Codex?

Em 2026, Claude Code GitHub Actions permite criar PRs e implementar mudanças em workflows, enquanto Codex pode rodar revisão estruturada em CI (Claude Code Docs, "GitHub Actions", 2026; OpenAI Developers, "Build Code Review with the Codex SDK", 2026). Use o agente como executor; use o CI como juiz de regressão.

Fontes consultadas

• arXiv, "TDAD: Test-Driven Agentic Development - Reducing Code Regressions in AI Coding Agents via Graph-Based Impact Analysis", consultado em 2026-07-18, https://arxiv.org/html/2603.17973v1
• Anthropic, "Demystifying evals for AI agents", consultado em 2026-07-18, https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
• GitLab, "GitLab Research Reveals Organizations Are Generating AI Code Faster Than They Can Control It", consultado em 2026-07-18, https://ir.gitlab.com/news/news-details/2026/GitLab-Research-Reveals-Organizations-Are-Generating-AI-Code-Faster-Than-They-Can-Control-It/default.aspx
• OpenAI Developers, "Build Code Review with the Codex SDK", consultado em 2026-07-18, https://developers.openai.com/cookbook/examples/codex/build_code_review_with_codex_sdk
• Claude Code Docs, "GitHub Actions", consultado em 2026-07-18, https://code.claude.com/docs/en/github-actions
• AgriciDaniel, "claude-blog", consultado em 2026-07-18, https://github.com/AgriciDaniel/claude-blog