En vez de promptear a un agente tarea por tarea, diseñé el sistema que lo promptea: un pipeline que encuentra su propio trabajo, lo reparte y se detiene solo cuando un chequeo real lo aprueba.
Cómo funciona
-
Auditor — recorre un repositorio buscando bugs de correctness reales (no nitpicks de estilo): fallos en boundaries de I/O/red/DB, race conditions, problemas de seguridad, validaciones ausentes. Cada hallazgo necesita un escenario de falla concreto con
archivo:línea. Crea un ticket en Jira por hallazgo, clasificado por gravedad y prioridad, con un tope duro por corrida y de-duplicación por JQL contra tickets ya abiertos. -
Resolutores en paralelo — hasta cuatro corridas simultáneas, cada una con un ticket ya asignado. Cada resolutor trabaja en su propio
git worktreeaislado — nunca en el checkout principal — así dos corridas concurrentes no se pisan. Implementa el fix mínimo, sin refactors. -
Guardrail de base de datos — regla mecánica, no discrecional: si el diff toca migraciones, modelos ORM o contiene DDL/DML fuera de tests, el resolutor se detiene, escribe el
.sqlpara revisión humana y marca el ticket como bloqueado. Nunca aplica cambios de esquema. -
Verificación — corre los tests / el analizador del repo y pega el output real. Si falla, itera un par de veces; si sigue rojo, revierte y marca el ticket como bloqueado con el log.
-
PR + cierre del ciclo — abre el PR, pide review a un bot, registra el PR en un archivo de estado y transiciona el ticket a “en revisión”. Un job aparte cierra el ticket cuando el PR se mergea — y solo procesa PRs que pasaron por el pipeline, nunca todos los del repo.
La idea de fondo
El agente que escribe el código no puede ser el que lo aprueba. El contexto donde el código nació ya está lleno de la cadena de auto-persuasión que lo produjo. La separación generator / evaluator es estructural: otro agente, con instrucciones que asumen que el código está roto hasta probar lo contrario, corre los tests y decide.
Guardias contra los costos silenciosos
- PRs nunca se auto-mergean — siempre hay una puerta humana.
- Ítems inciertos van a un inbox, no a un PR.
- Topes de tokens por corrida y diarios, con máximo de reintentos antes de mandar el hallazgo a revisión.
- El estado vive en disco, no en la ventana de contexto: cada hallazgo, su estado y la acción tomada se commitean para que la corrida de mañana los lea.
La lógica de discovery vive en archivos de skill versionados, no incrustada en un cron que nadie va a actualizar.