Evals de regresión para agentes de código responden la pregunta que la prueba de la tarea no cubre: ¿el patch preservó lo que ya funcionaba? Codex, Claude Code y agentes similares pueden corregir el bug visible y romper contrato, integración, permiso, migración o comportamiento distante.
En 2026, "TDAD: Test-Driven Agentic Development" evaluó agentes en SWE-bench Verified y reportó una reducción de 70% en regresiones a nivel de test con análisis de impacto basado en grafo (arXiv, "TDAD: Test-Driven Agentic Development", 2026). La lección operativa es directa: la regresión debe ser métrica del agente, no sorpresa del reviewer.
Resumen práctico
- Los evals de regresión miden preservación, no solo resolución.
- CI debe elegir tests por impacto, riesgo e historial.
- El agente recibe feedback corto, pero se detiene ante falla repetida.
- El PR necesita evidencia de test antes de revisión humana.
¿Por qué la regresión debe volverse métrica del agente?
En 2026, TDAD reportó 562 fallas en tests que antes pasaban en 100 instancias de baseline, con promedio de 6,5 tests rotos por patch generado (arXiv, "TDAD: Test-Driven Agentic Development", 2026). Pasar la prueba de la issue no prueba que el producto siguió intacto.
El error común es tratar al agente como autor rápido y al CI como sello final. Eso ya es frágil para código humano. Es peor para código generado por IA porque el agente puede optimizar la evidencia mostrada e ignorar dependencias que nunca vio.
Un eval de regresión debe vivir junto al eval de resolución. Uno mide si la tarea fue resuelta. El otro mide si el comportamiento previamente aceptado siguió aceptado. Cuando ambos entran en el mismo gate, el reviewer recibe un PR menor y con riesgo más claro.
Cápsula citable: Los evals de regresión para agentes de código convierten preservación en métrica de CI. TDAD reportó 562 fallas de tests previamente aprobados en 100 instancias de baseline; por eso, un patch agentic debe probar que corrigió la tarea sin romper contratos existentes.
Esto amplía evals de PR para agentes en CI. El objetivo es distinto. Allí el foco es el paquete de revisión. Aquí el foco es el conjunto de pruebas que impide que el agente gane la prueba estrecha y pierda el sistema.
¿Qué entra en una suite de regresión para agentes?
En 2026, Anthropic separó evals de capacidad de evals de regresión: los primeros deben comenzar con tasa baja de aprobación, mientras las regresiones deben mantenerse cerca de 100% para detectar retrocesos (Anthropic, "Demystifying evals for AI agents", 2026). Para agentes de código, esa diferencia se vuelve contrato operativo.
Una suite mínima tiene cuatro capas. La primera es determinística: tests que deben pasar. La segunda es estructural: archivos, símbolos y contratos tocados por el patch. La tercera es conductual: flujos de producto que podrían cambiar. La cuarta es procesal: ¿el agente respetó límites de herramienta, contexto e intentos?
Usa una ficha corta por tarea. Debe declarar tests obligatorios, tests de regresión esperados, comandos de verificación, riesgo aceptado y criterio de parada. Si la ficha no cabe en el PR, probablemente tampoco cabe en el 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: "detener cuando la misma regresion falle dos veces"
evidence:
- diff_summary
- commands_run
- failing_then_passing_outputCápsula citable: Anthropic recomienda tratar evals de regresión como protección contra retroceso, con tasa esperada cercana a 100%. En agentes de código, eso significa tests determinísticos, rúbricas de calidad, revisión de tool use y evidencia compacta en el PR.
Cuando el loop atraviesa logs, subagentes e historial de intentos, uso RemoteCode para preservar continuidad en flujos agentic de Codex y Claude Code con menos contexto repetido. Es una herramienta mía, así que esta mención es editorial y ligada al costo real de cargar evidencia sin inflar el prompt.
¿Cómo elegir tests sin ejecutar todo?
En 2026, TDAD combinó grafo código-test y análisis de impacto para reducir regresiones a nivel de test en 70% (arXiv, "TDAD: Test-Driven Agentic Development", 2026). El punto no es copiar la herramienta. Es adoptar la idea: el agente necesita saber qué tests distantes representan el riesgo del diff.
Ejecutar todo siempre parece seguro, pero escala mal en monorepos, suites lentas y pipelines pagos. Ejecutar solo tests cercanos al archivo también falla. La salida pragmática es selección por impacto con dependencia estática, historial de fallas, cobertura, ownership y contratos compartidos.
Empieza con reglas simples. Si el agente tocó autenticación, ejecuta tests de sesión y permisos. Si tocó serialización, ejecuta consumidores. Si cambió schema, ejecuta migración, rollback y contrato de API. Después madura hacia grafo, cobertura y señales de producción.
| Señal del diff | Test de regresión que debe entrar |
|---|---|
| Cambio en contrato público | Tests de consumidor y compatibilidad |
| Cambio en autorización | Tests de permiso, sesión y abuso |
| Cambio en fila o webhook | Idempotencia, retry y orden de entrega |
| Cambio en persistencia | Migración, rollback y consulta crítica |
Cápsula citable: La selección de tests para agentes no debe depender solo de proximidad de archivo. TDAD mostró que dependencias indirectas explican regresiones perdidas; por eso, CI agentic necesita grafo, historial y riesgo de dominio antes de devolver feedback al agente.
Este patrón combina con RAG de codebase para agentes. RAG ayuda al agente a editar. Evals de regresión ayudan al pipeline a decidir si la edición preservó comportamiento.
¿Dónde recibe feedback el agente y dónde debe parar?
En 2026, Anthropic usó ejemplos de evals de coding agents con tests determinísticos, rúbricas, análisis estático, estado esperado y métricas de transcript (Anthropic, "Demystifying evals for AI agents", 2026). Ese modelo separa feedback útil de permiso infinito.
El agente debe recibir el log más pequeño que explique la regresión. Incluye comando, test, fragmento de error, archivo probable y regla de alcance. No entregues toda la salida de la suite cuando solo importa una falla. El objetivo es reparar, no reiniciar la investigación.
Detén el loop cuando la misma regresión falle dos veces por el mismo motivo, cuando el agente amplíe alcance sin justificación o cuando la corrección exija decisión de producto. Autonomía sin criterio de parada se vuelve una cadena de patches plausibles.
Cápsula citable: El feedback de regresión debe ser corto y ejecutable: comando, test, error, archivo probable y límite de alcance. Si la misma falla reaparece, el agente debe parar porque el siguiente intento suele ampliar diffs sin aumentar confianza.
Para la reparación después de la falla, usa el flujo de loops autocorrectivos en CI. El eval decide si hubo regresión. El loop decide si existe un intento seguro de corrección.
¿Cómo registrar evidencia de regresión en el PR?
En 2026, OpenAI mostró un flujo de code review con Codex en CI usando salida JSON estructurada, archivo de resultado y comentarios en el sistema de control de código (OpenAI Developers, "Build Code Review with the Codex SDK", 2026). La misma disciplina sirve para regresión.
El PR debe mostrar tres cosas. Primero, qué riesgo fue evaluado. Segundo, qué tests cubrieron ese riesgo. Tercero, qué evidencia cambió después del patch. Si el agente solo escribe "tests pasaron", el reviewer aún debe reconstruir el razonamiento.
Prefiere un artefacto pequeño en CI. Puede ser comentario, resumen de job o archivo adjunto. El formato debe sobrevivir al cambio de herramienta: Codex hoy, Claude Code mañana, otro agente después. El contrato importa más que el proveedor.
{
"regression_eval": {
"risk": "contrato de sesion alterado",
"commands": ["npm test -- session_contract"],
"result": "passed",
"retry_count": 1,
"human_review_needed": false
}
}Cápsula citable: La evidencia de regresión en un PR agentic debe ser estructurada. OpenAI demuestra revisión con Codex en CI mediante salida JSON; para regresión, el mismo patrón registra riesgo, comando, resultado, intentos y necesidad de revisión humana.
Esto reduce el trabajo descrito en PRs de agentes que fallan antes del merge. El reviewer aún juzga arquitectura y producto, pero no necesita descubrir si la regresión obvia fue probada.
¿Qué implementación mínima cabe esta semana?
En 2026, GitLab reportó que 85% de los respondentes concuerdan en que la IA movió el cuello de botella de escribir código a revisarlo y validarlo (GitLab, "AI Accountability Report", 2026). La implementación mínima debe atacar ese cuello de botella, no crear un laboratorio perfecto.
Empieza con un archivo versionado de reglas por área crítica. Mapea dominio a tests de regresión. Luego agrega un job de CI que lee el diff, elige la regla, ejecuta comandos y publica evidencia. Solo entonces permite que el agente intente corregir una falla.
Para equipos pequeños, tres categorías bastan en la primera semana: autenticación, persistencia e integración externa. Concentran contratos difíciles de revisar a simple vista. Si el agente toca una de esas áreas, CI exige regresión específica antes de liberar revisión.
Cápsula citable: La primera versión de evals de regresión no necesita grafo perfecto. Con reglas versionadas por dominio, comandos determinísticos y evidencia en el PR, el equipo ya reduce el cuello de botella identificado por GitLab: validación de código generado por IA.
Después refina con context engineering para agentes de código. El mejor eval no vuelca todo en el agente. Entrega solo la falla, el contrato y la evidencia necesaria para una corrección pequeña.
FAQ sobre evals de regresión para agentes
¿Evals de regresión sustituyen code review?
No. En 2026, GitLab midió 85% de respondentes viendo revisión y validación como nuevo cuello de botella del código con IA (GitLab, "AI Accountability Report", 2026). Evals reducen incertidumbre mecánica, pero arquitectura, producto y riesgo residual siguen humanos.
¿Necesito un grafo código-test desde el primer día?
No. En 2026, TDAD mostró 70% menos regresiones de test con grafo e impacto (arXiv, "TDAD: Test-Driven Agentic Development", 2026). Ese es el objetivo maduro. La primera versión puede ser una tabla por área crítica si ejecuta comandos reales y publica evidencia.
¿El agente debe corregir regresiones automáticamente?
Solo con límite. En 2026, Anthropic recomienda evals con tests, rúbricas y métricas de transcript para agentes de código (Anthropic, "Demystifying evals for AI agents", 2026). Permite un intento pequeño. Si la falla se repite, detén y pide revisión humana.
¿Cómo encaja esto con Claude Code y Codex?
En 2026, Claude Code GitHub Actions permite crear PRs e implementar cambios en workflows, mientras Codex puede ejecutar revisión estructurada en CI (Claude Code Docs, "GitHub Actions", 2026; OpenAI Developers, "Build Code Review with the Codex SDK", 2026). Usa el agente como ejecutor; usa CI como juez de regresión.
Fuentes consultadas
- arXiv, "TDAD: Test-Driven Agentic Development - Reducing Code Regressions in AI Coding Agents via Graph-Based Impact Analysis", consultado en 2026-07-18, https://arxiv.org/html/2603.17973v1
- Anthropic, "Demystifying evals for AI agents", consultado en 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 en 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 en 2026-07-18, https://developers.openai.com/cookbook/examples/codex/build_code_review_with_codex_sdk
- Claude Code Docs, "GitHub Actions", consultado en 2026-07-18, https://code.claude.com/docs/en/github-actions
- AgriciDaniel, "claude-blog", consultado en 2026-07-18, https://github.com/AgriciDaniel/claude-blog
