El autor de un CRM en Django montó con cinco roles de IA un pipeline que lleva la tarea solo hasta la captura de pantalla

Una escena conocida: lanzas Claude o Codex, le pasas un prompt y recibes un «listo». Abres el código y ves los mismos formularios, solo que con las variables renombradas. El autor de un análisis publicado en Habr venía del desarrollo de bases de datos y en otoño de 2025 se puso con un CRM para alquiler de coches y aeroclubes. Pasó por esto cuatro veces seguidas y acabó construyendo un pipeline que lleva la tarea por sí mismo y trae pruebas.

Por qué un solo prompt no basta

Estaba construyendo recursos compartidos para coches, instructores y espacios en Django. Los formularios eran parecidos y quería reutilizar el código. Codex informó de que la refactorización estaba hecha, pero la revisión mostró que casi nada había cambiado. Otras tres rondas en chats distintos dieron el mismo resultado. La queja principal del autor: solo al final entendía qué había hecho realmente el modelo. El conocimiento había que trasladarlo entre chats a mano, y la compresión del contexto perdía detalles.

Necesitaba un sistema en el que se viera de antemano cómo el modelo había entendido la tarea, el trabajo estuviera dividido en pasos y cada paso lo comprobara otro. Comprobarlo todo él mismo era imposible.

Cinco roles y un archivo

Los roles surgieron de un conjunto de wrappers de consola para Codex CLI, Claude Code y GLM. Al principio eran cuatro:

• el arquitecto construye la solución de alto nivel (modelos GPT en Codex);
• el planificador define el conjunto de archivos y esboza un borrador del código;
• el programador escribe los cambios;
• el revisor comprueba el resultado. Este rol se asignó a GLM, entre otras cosas para ajustarse a los límites de las suscripciones.

Cuando el trabajo en paralelo en cinco git worktrees se comió la atención del autor, apareció el gestor. Es un rol casi mecánico que pasa el turno. El autor lo hizo un agente y no un script porque quería poder preguntar «¿en qué estado estamos?». Ahora hay dos revisores, por áreas de responsabilidad.

A todos los une un artefacto de coordinación: el archivo de plan. Lo mantiene el arquitecto, los demás añaden sus secciones, y el gestor solo lo lee y pasa el turno. En la cabecera se anota el estado y quién tiene derecho a fijarlo: Ready for Planner, Ready for Coder, Ready for Review, Done. Es la misma idea que en los frameworks SDD como Spec Kit, OpenSpec, BMAD y Kiro. La tarea vive en un archivo y sobrevive a la compresión del contexto.

Hay también un detalle curioso: a los roles no les gustaba releer el plan y se fiaban de la «memoria». El arquitecto declaró una vez que le tocaba el turno al planificador, aunque este ya había terminado. El remedio es sencillo. El estado lo da un helper, el rol se lo pregunta y no se inventa nada.

Cómo se ve en una tarea real

La tarea venía del CRM para aeroclubes: reservar por horas un avión, un instructor y un alumno. El planificador notó que en el modelo de datos no había sitio para el campo «Lección de la sección del centro de formación (AUTs)» y planteó al arquitecto una pregunta marcada como «bloqueante». El arquitecto indicó dónde mapear los campos y el programador empezó a trabajar sin preguntas.

El revisor devolvió el formulario al programador dos veces. La segunda vez, un test incluso había fijado el error y pasaba, por lo que los tests en verde por sí solos no bastan. La tercera vez, el revisor ejecutó las comprobaciones (119 y 67 tests, verificación de migraciones, doc-lint), hizo capturas según el escenario del plan y contrastó cada una con el plan. El arquitecto abrió seis capturas y no aceptó la tarea a la primera: tres archivos del commit no estaban en el conjunto declarado. Tras la corrección, la aceptó. La persona entrega la tarea a la entrada y mira si el plan, la revisión, los tests y las capturas coinciden.

El pipeline además se mejora a sí mismo. Después de cada plan, los roles hacen un docs closeout: proponen qué rematar y cómo mejorar el proceso. Las propuestas se acumulan en registros y el triaje decide cuáles implantar. El autor también toma ideas de fuera. Los golden paths, recetas breves del tipo «para un formulario típico abre estos 3–5 documentos», y el doc gardening vienen del artículo de OpenAI sobre harness engineering. La búsqueda QMD sobre markdown se probó y se descartó: bastó la búsqueda de texto completo en SQLite. Contra los bucles hay un límite: tras 12 iteraciones sobre un mismo plan, el gestor detiene el trabajo.

Limitaciones y qué llevarse

Es la experiencia de una persona en un proyecto, sin mediciones del tipo «ahorré tantas horas». El autor no llegó a unificar los formularios en un único código y se quedó en un «nivel comprensible de uniformidad». Por el pipeline no pasan todos los cambios, solo aquellos tras los cuales hace falta dejar rastro en el repositorio. La comprobación por otro modelo ahora ocurre sobre todo fuera del pipeline. Los modelos concretos que menciona no son lo principal: cambian más rápido que el proceso.

Qué conviene llevarse a tu propio proyecto:

• Exige pruebas, no informes: tests, capturas, contraste con el plan.
• Crea un archivo de tarea único con estados y una regla de quién fija cada estado.
• No encargues al modelo calcular el estado; sácalo a un helper.
• Permite a los roles hacer preguntas bloqueantes antes de escribir código.
• Pon un límite de iteraciones para que los agentes no se atasquen sin fin.

La lección principal: un prompt sirve para una solución puntual. En cuanto el proyecto hay que desarrollarlo y mantenerlo, hace falta un proceso cuyo resultado se pueda verificar a simple vista.