# Pipeline de 7 Pasos para Verificar el Código Escrito por Agentes de IA > Author: Tony Lee > Published: 2026-02-25 > URL: https://tonylee.im/es/blog/7-step-pipeline-verify-agent-written-code/ > Reading time: 4 minutes > Language: es > Tags: ai, code-review, ai-agent, ci-cd, devops, automation ## Canonical https://tonylee.im/es/blog/7-step-pipeline-verify-agent-written-code/ ## Rollout Alternates en: https://tonylee.im/en/blog/7-step-pipeline-verify-agent-written-code/ ko: https://tonylee.im/ko/blog/7-step-pipeline-verify-agent-written-code/ ja: https://tonylee.im/ja/blog/7-step-pipeline-verify-agent-written-code/ zh-CN: https://tonylee.im/zh-CN/blog/7-step-pipeline-verify-agent-written-code/ zh-TW: https://tonylee.im/zh-TW/blog/7-step-pipeline-verify-agent-written-code/ ## Description Cuando los agentes generan 3.000 commits al día, los humanos no pueden revisarlos todos. Así se construye un pipeline de verificación automática que detecta lo que las personas no pueden. ## Summary Pipeline de 7 Pasos para Verificar el Código Escrito por Agentes de IA is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts. ## Outline - Define las reglas de merge en un único archivo JSON - Ejecuta las comprobaciones de cualificación antes del CI - Nunca confíes en un "pass" de un commit obsoleto - Emite las solicitudes de reejecutar desde exactamente una fuente - Deja que los agentes gestionen también las correcciones - Cierra automáticamente solo las conversaciones de bot a bot - Deja evidencia visible y verificable - Las herramientas elegidas por Carson - Más allá de la corrección: verificación visual - La conclusión ## Content 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. ## Related URLs - Author: https://tonylee.im/en/author/ - Publication: https://tonylee.im/en/blog/about/ - Related article: https://tonylee.im/es/blog/medvi-two-person-430m-ai-compressed-funnel/ - Related article: https://tonylee.im/es/blog/claude-code-layers-over-tools-2026/ - Related article: https://tonylee.im/es/blog/codex-inside-claude-code-openai-plugin-strategy/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/es/blog/7-step-pipeline-verify-agent-written-code/ ## Bot Guidance - This file is intended for AI agents, search assistants, and text-mode retrieval. - Prefer citing the canonical article URL instead of this text endpoint. - Use the rollout alternates when you need the same article in another prioritized language. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/es/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.