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

Este es el tema más candente del momento. Los agentes están generando cientos de commits al día, y nadie puede revisarlos todos.

Peter, un desarrollador de OpenClaw, a veces hace 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 manejar solos.

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

Definir las reglas de merge en un único archivo JSON

Escribí qué rutas son de alto riesgo y qué checks deben pasar, todo en un solo archivo. La idea clave es 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 después de pasar un policy gate y CI

Ejecutar checks de calificación antes del CI

Correr builds en PRs que ni siquiera pasaron revisión es quemar dinero. Poné un risk-policy-gate antes del CI fanout. Solo esto reduce significativamente los costos innecesarios de CI.

• Orden fijo: policy gate → confirmación del Review Agent → CI fanout
• Los PRs no calificados nunca llegan a la etapa de prueba/build

Nunca confiar en un “pass” de un commit desactualizado

Esto es lo que Carson enfatizó más. Si un “pass” de un commit viejo queda pendiente, el código más reciente hace merge sin verificación. Volvé a ejecutar las revisiones en cada push y bloqueá el gate si no coinciden.

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

Emitir solicitudes de re-ejecución desde exactamente una fuente

Cuando múltiples workflows solicitan re-ejecuciones, se generan comentarios duplicados y condiciones de carrera. Parece trivial, pero si no lo solucionás, todo el pipeline se desestabiliza.

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

Dejar que los agentes también manejen las correcciones

Cuando el Review Agent encuentra un problema, el Coding Agent lo parchea y hace push a la misma rama. El insight más agudo del post de Carson: fijá la versión del modelo. De lo contrario, obtenés resultados distintos cada vez y la reproducibilidad desaparece.

• Codex Action corrige → push → disparo del rerun
• Las versiones de modelo fijadas garantizan reproducibilidad

Solo cerrar automáticamente conversaciones bot a bot

Nunca toques los hilos donde participó un humano. Sin esta distinción, los comentarios de los revisores quedan enterrados.

• Auto-resolver solo después de una re-ejecución limpia en el head actual
• Los hilos con comentarios humanos siempre quedan abiertos

Dejar evidencia visible y verificable

Si la UI cambió, no basta con tomar una captura de pantalla. Se requiere evidencia verificable por CI. Convertí los incidentes de producción en casos de prueba para que el mismo fallo no se repita.

• Regresión → issue de gap en harness → agregar caso de prueba → seguimiento de SLA

Las herramientas que eligió Carson

Para referencia, esto es lo que Carson seleccionó: Greptile como agente de revisión de código, Codex Action para la remediación, y tres archivos de workflow que se encargan del trabajo pesado greptile-rerun.yml para los reruns canónicos, greptile-auto-resolve-threads.yml para limpiar hilos desactualizados, 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 está bien o mal. Pero en la práctica, también hay que verificar cómo se ve el resultado.

Dos enfoques se destacan.

El visual-explainer de Nico Bailon renderiza diffs de terminal como páginas HTML en lugar de ASCII, haciendo que los changesets sean 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 errores de CSS y layout. Combinado con bisect, puede identificar exactamente qué commit causó la regresión.

Estuve pensando en esto mientras construía codexBridge. Rastrear qué agente escribió qué código no es suficiente solo con logs de sesión. Necesitás 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 produjeron las máquinas. Esa es la respuesta.