Pipeline de 7 Pasos para Verificar el Código Escrito por Agentes de IA

Este es el tema más candente ahora mismo. Los agentes generan cientos de commits al día, y nadie puede revisarlos todos.

Peter, un desarrollador en OpenClaw, a veces envía más de 3.000 commits en un solo día. Eso está muy por encima de lo que cualquier persona puede procesar. Se ha convertido en una tarea que los humanos simplemente no pueden gestionar solos.

Al principio pensé que no había solución. Entonces leí el “Code Factory” de Ryan Carson y todo encajó. En lugar de intentar leerlo todo, construyes una estructura donde las máquinas verifican el código.

Define las reglas de merge en un único archivo JSON

Escribe qué rutas son de alto riesgo y qué comprobaciones deben superarse, todo en un solo archivo. La clave está en que esto evita que la documentación y los scripts se desincronicen.

• Las rutas de alto riesgo requieren un Review Agent más evidencia basada en el navegador
• Las rutas de bajo riesgo pueden hacer merge tras pasar un policy gate y CI por sí solos

Ejecuta las comprobaciones de cualificación antes del CI

Lanzar builds sobre PRs que ni siquiera han pasado revisión es tirar el dinero. Coloca un risk-policy-gate delante del fan-out de CI. Solo esto reduce significativamente los costes innecesarios de CI.

• Orden fijo: policy gate → confirmación del Review Agent → fan-out de CI
• Los PRs que no superan la cualificación nunca llegan siquiera a la fase de test/build

Nunca confíes en un “pass” de un commit obsoleto

Esto es lo que Carson subrayó con más énfasis. Si persiste un “pass” de un commit antiguo, el código más reciente hace merge sin verificación. Vuelve a ejecutar las revisiones en cada push y bloquea el gate si no coinciden.

• Un Review Check Run solo es válido cuando coincide con el headSha
• Fuerza una nueva ejecución en cada evento synchronize

Emite las solicitudes de reejecutar desde exactamente una fuente

Cuando varios workflows solicitan reejecutar, obtienes comentarios duplicados y condiciones de carrera. Parece una minucia, pero si no lo corriges, todo el pipeline se tambalea.

• Evita duplicados con un patrón Marker + sha:headSha
• Omite la solicitud si el SHA ya fue enviado

Deja que los agentes gestionen también las correcciones

Cuando el Review Agent detecta un problema, el Coding Agent lo parchea y hace push a la misma rama. La observación más aguda del post de Carson: fija la versión del modelo. De lo contrario, obtienes resultados diferentes cada vez y la reproducibilidad desaparece.

• Codex Action corrige → push → disparo de reejecutar
• Las versiones de modelo fijadas garantizan la reproducibilidad

Cierra automáticamente solo las conversaciones de bot a bot

Nunca toques los hilos en los que haya participado un humano. Sin esta distinción, los comentarios de los revisores quedan enterrados.

• Auto-resolve solo tras una reejecutación limpia en el head actual
• Los hilos con comentarios de humanos permanecen abiertos, siempre

Deja evidencia visible y verificable

Si la interfaz ha cambiado, no te limites a hacer una captura de pantalla. Exige evidencia verificable por CI. Convierte los incidentes en producción en casos de prueba para que el mismo fallo no se repita.

• Regresión → issue de gap en el harness → añadir caso de prueba → seguimiento por SLA

Las herramientas elegidas por Carson

Como referencia, esto es lo que seleccionó Carson: Greptile como agente de revisión de código, Codex Action para la remediación, y tres archivos de workflow que hacen el trabajo pesado greptile-rerun.yml para las reejecutaciones canónicas, greptile-auto-resolve-threads.yml para limpiar hilos obsoletos, y risk-policy-gate.yml para la política preflight.

Más allá de la corrección: verificación visual

Todo lo anterior detecta si el código es correcto o incorrecto. Pero en la práctica, también necesitas verificar cómo se ve el resultado.

Destacan dos enfoques.

El visual-explainer de Nico Bailon renderiza los diffs de terminal como páginas HTML en lugar de ASCII, haciendo que los conjuntos de cambios sean inmediatamente legibles de un vistazo.

El agent-browser de Chris Tate toma una dirección diferente. Compara pantallas reales del navegador píxel a píxel para detectar roturas de CSS y maquetación. Combinado con bisect, puede identificar exactamente qué commit causó la regresión.

He estado pensando en esto mientras construyo codexBridge. Rastrear qué agente escribió qué código no es suficiente con simples registros de sesión. Necesitas una estructura de búsqueda que facilite la recuperación.

La conclusión

La respuesta a “¿quién verifica el código escrito por agentes?” no son los humanos. Es una estructura donde las máquinas juzgan la evidencia que las máquinas produjeron. Esa es la respuesta.