Los evals de PR para agentes de código son verificaciones diseñadas para juzgar un cambio generado por IA antes de que el reviewer humano gaste atención en él. Combinan pruebas, rúbricas, análisis del diff, evidencia de ejecución y reglas de bloqueo. El objetivo no es probar que el agente es inteligente. Es probar que ese PR concreto merece revisión humana.

En 2026, GitHub dijo que Copilot code review ya había procesado más de 60 millones de reviews y que más de una de cada cinco revisiones de código en GitHub involucraba a un agente (GitHub, "Agent pull requests are everywhere. Here's how to review them", 2026). Ese volumen cambia la disciplina: la revisión manual sin eval se vuelve cola.

Resumen práctico

  • Un PR de agente debe llegar con prueba, no solo con texto convincente.
  • Los buenos evals combinan pruebas determinísticas, rúbricas y evidencia de ejecución.
  • Los subagentes ayudan cuando revisan señales separadas y devuelven síntesis cortas.
  • CI debe bloquear riesgos repetibles antes de llamar al reviewer.

¿Por qué los evals de PR se volvieron urgentes?

En 2026, GitLab informó que el 85% está de acuerdo en que la IA desplazó el cuello de botella de escribir código a revisarlo y validarlo (GitLab, "AI Accountability Report", 2026). Los evals de PR se volvieron urgentes porque los agentes aceleran diffs, mientras el costo de confianza sigue cayendo en personas.

El error es tratar todo PR de agente como un PR humano cuyo autor puede defender cada decisión. Un agente puede escribir una explicación convincente y aun así tocar el archivo equivocado, ignorar una regresión o eliminar una prueba sin motivo. El relato no alcanza.

El eval hace otra pregunta: ¿qué señales mínimas vuelven revisable este PR? Para backend, puede ser prueba de contrato, tipos, lint, migración reversible y análisis de permisos. Para DevOps, puede ser plan de rollback, alcance de infraestructura y verificación de secretos. Para frontend, puede ser prueba visual, accesibilidad y estados vacíos.

Este enfoque extiende mi artículo sobre harness de agentes de código para pull requests confiables. El harness define el flujo. El eval define la medición. Sin ambos, el equipo solo mueve el cuello de botella a una cola de revisión mayor.

Un eval de PR para agentes de código convierte la revisión en triage basado en evidencia. Si el PR no muestra prueba, alcance y riesgo, no está listo. Si los muestra, el reviewer gasta atención en lo que importa: arquitectura, intención de producto, seguridad y trade-offs que la automatización no debe decidir.

¿Qué debe medir un eval antes del merge?

En 2026, GitLab también afirmó que el 82% ve el código generado por IA como riesgo de una nueva forma de deuda técnica (GitLab, "AI Accountability Report", 2026). Por eso, un eval de PR debe medir reproducción, alcance, regresión y trazabilidad, no solo si la suite quedó verde.

Loop verificable muestra hipótesis, patch, evals y PR con retorno cuando la prueba falla.

La primera señal es reproducción. Si el PR corrige un bug, el eval debe exigir una prueba que fallaba antes o un artefacto que muestre la falla original. Sin eso, el agente tal vez solo cambió un síntoma. Para una feature, el equivalente es un contrato de comportamiento con caso feliz y caso negativo.

La segunda señal es alcance. Los evals necesitan comparar el diff con la tarea. Un agente que cambia autenticación para corregir layout debe quedar bloqueado. Un agente que modifica un lockfile sin dependencia relacionada merece explicación. Un agente que elimina una prueba para pasar CI merece falla automática.

La tercera señal es riesgo. Cambios en autenticación, pagos, datos personales, colas, jobs, migraciones e infraestructura deben elevar el nivel del gate. No hace falta tratar todo PR como incidente. Hace falta reconocer que algunos directorios cargan más daño potencial.

Señal del PR Cómo medirla Bloquea cuando
Reproducción Prueba nueva, fixture o log mínimo. El bug no aparece antes de la corrección.
Alcance Archivos alterados contra la tarea. El diff toca una frontera no explicada.
Regresión Pruebas, typecheck, lint y contrato. Un comando falla o fue omitido.
Riesgo Directorios sensibles y tipo de cambio. Seguridad, datos o infra cambian sin revisión.
Rastro Cuerpo del PR con comandos y evidencia. El reviewer recibe solo un resumen genérico.

Experiencia práctica: cuando reviso PRs generados por agentes, la mejor señal no es la longitud del texto. Es la relación entre hipótesis y prueba. Si la hipótesis dice "corregir expiración de sesión", quiero ver la prueba de sesión, el archivo tocado y la salida del comando. Lo demás es secundario.

¿Cómo convertir esto en un gate de CI?

En 2026, GitLab dijo que solo el 28% afirma tener herramientas del ciclo de desarrollo totalmente integradas con datos y flujos compartidos (GitLab, "AI Accountability Report", 2026). Un gate de CI para agentes debe ser lo bastante simple para entrar en el flujo existente.

Checklist visual muestra un gate de CI que exige lint, pruebas, revisión humana y evidencia en el PR.

Empieza con un archivo de política. Puede vivir en AGENTS.md, CLAUDE.md o .github/agent-evals.yml. El nombre importa menos que su función: registrar comandos obligatorios, áreas sensibles, formato de evidencia y condición de bloqueo. En junio de 2026, GitHub hizo que AGENTS.md pueda orientar el feedback de Copilot code review (GitHub Changelog, "Copilot code review: AGENTS.md support and UI improvements", 2026).

Después, crea un verificador pequeño. No necesita usar IA el primer día. Un script en Node, Python o Bash puede validar que el cuerpo del PR tenga comandos, que archivos sensibles disparen label, que la prueba obligatoria haya corrido y que ningún archivo prohibido cambie. El gate empieza determinístico.

Luego, añade una rúbrica para lo que las pruebas no cubren. La rúbrica puede puntuar claridad del PR, relación con el requisito, riesgo residual y ajuste arquitectural. Usa IA como juez solo cuando el criterio sea semántico. Aun así, trata el resultado como señal, no como verdad final.

eval_de_pr:
  comandos_obligatorios:
    - "npm run lint"
    - "npm run test -- --runInBand"
    - "npm run typecheck"
  areas_sensibles:
    - "src/auth/**"
    - "infra/**"
    - "migrations/**"
  exige_reviewer_humano:
    - "auth"
    - "datos personales"
    - "rollback"
  bloquea_si:
    - "sin prueba nueva para bug"
    - "diff fuera de alcance"
    - "comando obligatorio ausente"

Para loops largos con Claude Code y Codex, el costo de contexto también se vuelve parte del gate. Uso RemoteCode para llevar Claude Code y Codex más lejos en flujos agentic como herramienta propia cuando el trabajo necesita atravesar sesiones, subagentes y evidencias sin cargar todo el historial en el prompt principal.

¿Dónde ayudan los subagentes sin agregar ruido?

En 2026, la documentación de Codex afirma que los subagentes ayudan en tareas muy paralelas, como exploración de codebase o implementación de un plan de varias etapas (OpenAI Developers, "Subagents", 2026). En evals de PR, los subagentes funcionan mejor como reviewers especializados, no como varios autores editando el mismo diff.

Un subagente puede leer seguridad. Otro puede revisar pruebas. Otro puede mirar impacto en tipos TypeScript. Otro puede comparar la especificación con el diff. El agente principal no necesita cada log. Necesita una síntesis con hallazgo, archivo, severidad, confianza y próxima acción.

La documentación de Claude Code describe subagentes como asistentes especializados que trabajan en su propio contexto y devuelven solo un resumen, preservando la conversación principal (Claude Code Docs, "Create custom subagents", 2026). Esa es la regla central para PRs: fan-out de lectura, merge de decisión.

Matriz muestra señales de reproducción, alcance, riesgo y origen para bloquear pull requests de agentes.

Evita subagentes escribiendo en el mismo módulo al mismo tiempo. Eso mezcla autoría, aumenta conflictos y dificulta explicar por qué ganó una decisión. Si el trabajo exige varios cambios, divide por frontera real: servicio, paquete, ruta, schema o job. El eval final debe consolidar.

Una buena salida de subagente cabe en pocas líneas:

area: seguridad
status: bloquear
archivo: src/auth/session.service.ts
motivo: renovacion acepta token expirado sin revisar revoked_at
prueba: test auth/session-renewal.spec.ts falla en el caso negativo
accion: exigir prueba de revocacion antes del merge

Esta forma evita lo peor de ambos mundos: muchos agentes hablando y nadie decidiendo. Un buen subagente reduce contexto. Un mal subagente se vuelve una reunión asíncrona entre modelos.

¿Cómo diseñar un loop que mejora solo?

En 2026, OpenAI recomienda dar a Codex un sistema de evaluación con scripts y artefactos revisables para que mejore una tarea hasta que la puntuación sea suficiente (OpenAI Developers, "Iterate on difficult problems", 2026). El loop mejora solo cuando la falla se vuelve dato estructurado, no cuando el agente vuelve a intentar a ciegas.

El ciclo empieza con una hipótesis. El agente declara qué comportamiento cambiará, qué archivo espera tocar y cómo probará el éxito. Luego aplica el patch. CI corre los evals. Si falla, el siguiente intento recibe un diagnóstico compacto: comando, falla, archivo probable y restricción preservada.

OpenAI describió, en su caso de agentes tributarios, un ciclo donde problemas de producción se vuelven hallazgos, evals a medida y tareas de ingeniería validadas contra evals dirigidos y de regresión (OpenAI, "Building self-improving tax agents with Codex", 2026). Para software, el mismo patrón convierte incidentes, bugs y reviews en casos de prueba reutilizables.

No aceptes un loop infinito como autonomía. Define límite de intentos y regla de parada. Si dos intentos fallan por el mismo motivo, el agente debe abrir bloqueo. Si la falla cambia, puede iterar. Si el eval está mal, el agente puede proponer un ajuste, pero no debe editar el gate sin revisión.

El punto más importante: el eval también necesita mantenimiento. Cuando un reviewer humano encuentra una falla que el gate dejó pasar, registra el patrón. Si se puede repetir, conviértelo en prueba, rúbrica, regla de alcance o checklist humano. El sistema mejora cuando cada error caro se vuelve una verificación barata.

¿Cuál es el mínimo viable para empezar esta semana?

En 2026, GitLab señaló que el 91% de las organizaciones probablemente invertirá en herramientas de gobernanza de código con IA en los próximos 12 meses (GitLab, "AI Accountability Report", 2026). El mínimo viable no necesita esperar una plataforma nueva: empieza con una política pequeña, un checker y un template de PR.

Primero, escribe una sección en AGENTS.md con comandos obligatorios y formato de entrega. Incluye "qué cambió", "por qué cambió", "cómo se verificó" y "riesgo residual". Eso ya mejora Claude Code, Codex, Copilot y cualquier agente que lea instrucciones del repositorio.

Segundo, crea un job de CI llamado agent-pr-eval. Corre comandos existentes y valida el cuerpo del PR. Si la base ya tiene pruebas end-to-end con Playwright, añade solo el subset relevante. Si tiene tipos de pruebas en desarrollo de software, elige la menor combinación que pruebe el cambio.

Tercero, marca áreas sensibles. Autenticación, autorización, cobros, datos personales, migraciones e infraestructura no deberían pasar con autoaprobación. Este gate encaja con arquitectura de servicios en TypeScript, porque los límites de módulo vuelven los evals más objetivos.

Cuarto, registra falsos negativos. Cada vez que un reviewer detecte un error que CI no detectó, haz una pregunta: ¿esto debe volverse prueba, rúbrica, regla de alcance o checklist humano? Si no se vuelve nada, la organización seguirá pagando el mismo costo de revisión.

Preguntas frecuentes sobre evals de PR

En 2026, GitLab afirmó que el 80% está de acuerdo en que sus organizaciones adoptaron herramientas de IA más rápido de lo que desarrollaron políticas para gobernarlas (GitLab, "AI Accountability Report", 2026). Estas dudas ayudan a convertir política en rutina.

¿Un eval de PR reemplaza el code review humano?

No. En 2026, GitLab informó que el 85% ve el cuello de botella en revisión y validación, no solo en escritura de código (GitLab, "AI Accountability Report", 2026). El eval elimina ruido repetible; el humano decide arquitectura, intención de producto y riesgo que exige juicio.

¿Todo PR de agente necesita IA juzgando la rúbrica?

No. En 2026, OpenAI recomienda scripts y artefactos revisables como base del loop de evaluación (OpenAI Developers, "Iterate on difficult problems", 2026). Empieza con verificaciones determinísticas. Usa juez de IA solo para criterios semánticos, como coherencia entre requisito y diff.

¿AGENTS.md es obligatorio para evals?

No, pero se volvió más útil. En 2026, GitHub anunció que Copilot code review usa instrucciones relevantes de AGENTS.md en el repositorio (GitHub Changelog, "Copilot code review: AGENTS.md support and UI improvements", 2026). El archivo se vuelve contrato compartido entre agentes y reviewers.

¿Qué métrica muestra que el eval mejoró?

Usa retrabajo de review. En 2026, GitHub reportó más de 60 millones de reviews procesados por Copilot code review (GitHub, "Agent pull requests are everywhere. Here's how to review them", 2026). Localmente, mide menos comentarios repetidos, PRs fuera de alcance y fallas post-merge.

Cierre

En 2026, OpenAI escribió que, con más throughput de código, el cuello de botella pasó a ser la capacidad humana de QA (OpenAI, "Harness engineering: leveraging Codex in an agent-first world", 2026). Los evals de PR son la respuesta práctica: no dejan que la IA decida sola, pero obligan a cada cambio a llegar con prueba.

Empieza pequeño. Un template de PR, tres comandos obligatorios, una lista de áreas sensibles y una regla de bloqueo ya cambian la calidad de la revisión. Después añade subagentes, rúbricas semánticas y loops de mejora. Un buen agente no es el que escribe más código. Es el que entrega un PR que el equipo puede verificar.

Fuentes consultadas

  • GitHub, "Agent pull requests are everywhere. Here's how to review them", recuperado en 2026-07-01, https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
  • GitLab, "AI Accountability Report", recuperado en 2026-07-01, https://ir.gitlab.com/news/news-details/2026/GitLab-Research-Reveals-Organizations-Are-Generating-AI-Code-Faster-Than-They-Can-Control-It/default.aspx
  • GitHub Changelog, "Copilot code review: AGENTS.md support and UI improvements", recuperado en 2026-07-01, https://github.blog/changelog/2026-06-18-copilot-code-review-agents-md-support-and-ui-improvements/
  • OpenAI Developers, "Subagents", recuperado en 2026-07-01, https://developers.openai.com/codex/subagents
  • Claude Code Docs, "Create custom subagents", recuperado en 2026-07-01, https://code.claude.com/docs/en/sub-agents
  • OpenAI Developers, "Iterate on difficult problems", recuperado en 2026-07-01, https://developers.openai.com/codex/use-cases/iterate-on-difficult-problems
  • OpenAI, "Building self-improving tax agents with Codex", recuperado en 2026-07-01, https://openai.com/index/building-self-improving-tax-agents-with-codex/
  • OpenAI, "Harness engineering: leveraging Codex in an agent-first world", recuperado en 2026-07-01, https://openai.com/index/harness-engineering/