La mayoría de los agentes de programación empiezan a mitad del proceso.
Reciben una tarea, abren un repositorio, cambian archivos y quizá ejecutan una prueba. Eso es útil, pero no es entrega de software. La parte difícil suele comenzar antes de la primera edición: decidir qué problema merece atención, comprobar si ya existe, resolver ambigüedades entre repositorios, elegir el límite de implementación y acordar qué significa «terminado». Después esperan más decisiones: revisión independiente, manejo de fallas, autoridad de liberación, despliegue y aprendizaje a partir de lo que salió mal.
minion_base es mi intento de volver visible y operable ese recorrido completo. El sistema mayor es una fábrica de software autoalojada para MINION: una solicitud puede convertirse en una propuesta duradera, una especificación revisada, una ejecución aislada, un pull request probado y, finalmente, un despliegue. Los agentes hacen gran parte del trabajo mecánico. Las personas conservan las decisiones cuyo costo no se recupera simplemente reiniciando un contenedor.
Esto es a la vez un sistema funcional y una propuesta sobre cómo debería madurar. El tablero del ciclo de vida, las conversaciones de solicitud, las especificaciones de dos pasadas, las ejecuciones aisladas, la corrección acotada, la revisión entre proveedores, las métricas de la tubería, la memoria duradera, la captura de alertas y el tren de despliegue existen hoy. La autoridad de liberación ya no es una regla universal: el trabajo de mayor riesgo conserva decisiones humanas, mientras una vía estrecha de mantenimiento puede fusionar automáticamente cambios de documentación, pruebas o dependencias solo cuando la prueba propia, la revisión independiente y los checks de GitHub están verdes.
Una solicitud deja una cadena de artefactos revisables
El agente lee el contexto de los repositorios y ayuda a convertir una idea incompleta en un problema comprobable.
Transcripción accesible del diagrama
Una conversación se convierte en propuesta, cruza una aprobación de intención, pasa por una especificación revisada en dos etapas, entra a desarrollo y pruebas aisladas, recibe revisión adversarial y llega a una política de liberación. El mantenimiento de bajo riesgo puede fusionarse automáticamente; los cambios relevantes exigen una persona.
Por qué: un prompt es un mal sistema de registro
Un prompt puede expresar intención, pero es un lugar débil para conservarla. Mezcla la necesidad original con supuestos introducidos durante la conversación. Es difícil compararlo con trabajos anteriores, incómodo revisarlo como un artefacto estable y fácil perderlo cuando el agente comprime el contexto alrededor de detalles de implementación.
La primera decisión de diseño no es qué modelo escribe el código. Es que la conversación debe producir un artefacto antes de producir una rama.
La superficie de solicitudes es la zona creativa. Un agente puede leer el mapa del proyecto y el historial de planificación mientras una persona da forma a una idea. Antes de crear algo, busca coincidencias en propuestas y especificaciones anteriores. Si hay incertidumbre, preserva la nueva idea y marca un posible duplicado en vez de colapsar silenciosamente dos intenciones. El resultado es una propuesta versionada con el problema en las palabras del usuario, motivación, enfoque inicial, repositorios afectados, alternativas, riesgos y una definición de terminado que pueda probarse.
Esa propuesta no inicia una ejecución. Entra a la primera decisión humana.
La distinción importa. «Aprobada» significa vale la pena especificar esta idea, no un agente ya puede cambiar código de producción. Separar elegibilidad de ejecución evita que una etiqueta de estado se convierta en un botón de lanzamiento accidental.
Cómo, parte uno: el plan recibe un segundo autor
Cuando la intención está aprobada, la fábrica ejecuta una tubería de especificación en dos pasadas.
En la primera, un agente planificador lee la propuesta, las instrucciones de los repositorios, especificaciones relacionadas y el mapa de impacto entre proyectos. Convierte la idea en cortes verticales de implementación con archivos afectados, supuestos, verificaciones, riesgos operativos y una definición de terminado que otro proceso pueda ejecutar.
La segunda pasada comienza desde cero. El revisor no participó en la primera ni hereda su razonamiento oculto. Inspecciona la especificación contra el código, la corrige en el mismo archivo y escribe un registro de revisión separado. Ese archivo lateral importa: la especificación final dice qué construir; la revisión explica qué supuestos fueron cuestionados y por qué cambió el plan.
El resultado cruza una segunda decisión humana. La aprobación todavía significa este plan es suficientemente seguro para ejecutarse, pero ahora tiene una consecuencia concreta: una especificación aprobada puede poner en cola automáticamente su primer corte de implementación. La decisión autoriza un siguiente paso acotado en vez de depender de que alguien detecte una tarjeta inactiva.
Esta fricción adicional es intencional. Los agentes son tan rápidos que generar otra respuesta es barato. Propagar un supuesto arquitectónico equivocado por varios repositorios no lo es.
Cómo, parte dos: el panel no es la fábrica
El producto tiene varias superficies y cada una posee un tipo distinto de verdad.
minion_base es la sala de control privada. Muestra conversaciones, el tablero Propuesta → Especificación → Desarrollo → Pruebas → Despliegue, etiquetas por tipo de trabajo, decisiones, ejecuciones, logs, prácticas codificadas y salud de repositorios. La portada ahora mide presión de cola, throughput, tasa de aprobación, costo y tokens por etapa, categorías de falla, ejecuciones automáticas y reintentos de recuperación. Una superficie de configuración relaciona cada proveedor con niveles de rendimiento bajo, medio y alto. El tablero sigue reflejando GitHub y los índices versionados; arrastrar una tarjeta solo decoraría una mentira.
minion_factory es el plano de ejecución. Un servicio autoalojado recibe un artefacto aprobado o una tarea acotada, la pone en cola y abre un contenedor de agente. No es la fuente de verdad para la intención del producto ni el propietario del despliegue.
GitHub conserva el registro de código, revisión y workflows. El repositorio meta conserva la planificación. El CI/CD de cada repositorio conserva el mecanismo de liberación.
Control, ejecución, evidencia y liberación permanecen separados
SIGUE LAS FLECHASLa sala privada muestra solicitudes, ciclo de vida, decisiones humanas, ejecuciones, logs y estado de los repositorios.
Transcripción accesible del diagrama
minion_base es la superficie de control, el repositorio meta conserva propuestas y especificaciones, minion_factory ejecuta agentes acotados, GitHub conserva la revisión y los workflows, y el CI/CD de cada repositorio controla el despliegue.
Esta separación también define el modelo de seguridad. El navegador nunca recibe el secreto de la fábrica. minion_base expone desde su servidor autenticado una lista mínima de rutas permitidas. Cada contenedor recibe una credencial de modelo y un token de GitHub limitado al repositorio, no los secretos de la aplicación en producción. Un repositorio solo entra a la lista de ejecución cuando su prueba propia es suficientemente confiable.
La cola es una superficie de decisión, no una lista de tareas
El trabajo más reciente en minion_base cambió mi idea sobre qué debe optimizar la sala de control. Un tablero convencional responde ¿dónde está la tarjeta? La fábrica necesita responder preguntas más difíciles: ¿qué revisión fue evaluada, qué decisión se tomó, esa decisión realmente despachó trabajo, qué evidencia sigue vigente y qué todavía requiere a una persona?
Esas distinciones ya existen en el producto. Las tarjetas compactas dejaron de incluir acciones relevantes de un solo clic. Cada decisión se abre en el detalle, exige una confirmación explícita y queda vinculada tanto al estado esperado del ciclo de vida como a la revisión exacta del blob de GitHub que vio el operador. El servidor solo acepta transiciones legales entre estados y escribe con compare-and-swap, así que un navegador desactualizado no puede sobrescribir silenciosamente una decisión posterior. Repetir una transición ya aplicada es seguro.
El resultado tampoco se comprime en un “éxito” optimista. La interfaz conserva recibos persistentes y distintos para aprobado y en cola, aprobado pero pendiente de cola, conflicto de revisión, transición inválida y acción fallida. Aprobar y despachar están relacionados, pero no son el mismo hecho. Si el artefacto de planificación se confirma pero el runner no está disponible, la sala de control lo dice y deja la reconciliación al barrido programado.
El tablero también se está volviendo más honesto con la evidencia. Estado, riesgo e integridad usan un mismo lenguaje de etiquetas y símbolos, no solo color. Los issues se abren como detalles internos que reúnen fuente, triage, historial y linaje. La columna Pruebas muestra únicamente el estado relevante más reciente de cada workflow; una ejecución roja antigua deja de parecer un bloqueo actual después de una ejecución verde. Los detalles de CI pueden regresar a la propuesta que originó ese trabajo, y tanto minion_base como minion_factory ya son miembros de primera clase de la flota observada.
La nueva vista de rendimiento hace el mismo cambio: pasa de actividad a evidencia. Separa profundidad y espera de la cola del throughput terminado; compara resultados aprobados, fallidos, con error y cancelados por etapa; muestra duración promedio y mediana; desglosa llamadas a modelos, turnos, tokens y los costos disponibles; y mantiene las fallas de revisión, de prueba propia, de infraestructura, las ejecuciones automáticas y las reencoladas de recuperación como fenómenos distintos. Un volumen alto de ejecuciones no implica una fábrica saludable.
Cuando inspeccioné el registro de producción el 18 de agosto, dos cortes aprobados de minion_base estaban ejecutándose. Uno extrae una familia reutilizable de interacciones para decisiones asíncronas y un shell seguro para móviles. El otro normaliza cada tarjeta en un modelo tipado WorkDetail que ordena decisión → riesgo → prueba → detalle → historial. La evidencia ausente y la evidencia no soportada deben seguir siendo estados visiblemente distintos; ninguna puede convertirse en un cero tranquilizador o en una señal verde. Todavía son pull requests activos en borrador, no capacidades liberadas.
La misma cola expuso una lección menos favorable. En un solo día, varias ramas acumularon diez u once entradas después de que un intento aprobado fuera seguido por errores repetidos de rebase. El endpoint de reencolado evita crear dos hijos desde la misma ejecución fallida, pero cada hijo se convierte en un nuevo origen. Por eso, “una vez por ejecución” todavía no significa “una vez por linaje de trabajo”. La recuperación puede producir movimiento sin información nueva.
Eso cambia la siguiente mejora. La recuperación necesita un presupuesto para todo el linaje, comparar huellas de falla y comprobar el estado actual del pull request y del merge antes de iniciar otro contenedor. La misma evidencia de infraestructura debería converger en una intervención visible, no en un árbol genealógico de reintentos equivalentes. La cola es útil precisamente porque volvió legible esta falla.
El modelo que estoy construyendo mantiene cinco hechos separados: el artefacto revisado, la decisión registrada, el trabajo despachado, la evidencia devuelta y la liberación realizada. Unir cualquiera de esos hechos simplifica la interfaz a costa de volver menos confiable el sistema.
Qué ocurre dentro de una ejecución de desarrollo
La especificación aprobada entra al contenedor como el plan. La ejecución crea una rama aislada y abre un pull request en borrador antes de que el desarrollo pueda presentarse como completo. El pull request no es la meta; es el sobre duradero de la tarea, las etapas, los commits, las pruebas, las revisiones externas y la decisión final de liberación.
La etapa obligatoria de desarrollo puede usar Claude o Codex. En vez de fijar un modelo en cada workflow, la sala de control relaciona proveedores con niveles de rendimiento bajo, medio y alto. Cuando un proveedor desarrolla en cierto nivel, otro proveedor revisa en el mismo nivel. Una caída por cuota, autenticación o rate limit activa un único fallback entre proveedores; agotar turnos no lo hace, porque eso describe el tamaño de la tarea y no la salud del proveedor. El servicio mantiene los límites fuera del prompt: máximo de turnos, treinta minutos de reloj, cinco intentos internos y topes de CPU y memoria.
Después de cada intento se aplican dos comprobaciones.
Primero, la rama debe contener un cambio real de implementación. Esto cierra una brecha importante: un agente que no modifica nada podría «aprobar» solo porque el repositorio ya estaba verde antes de que llegara.
Segundo, debe pasar la prueba propia del repositorio. En minion_base, por ejemplo, se combinan el lint de tokens visuales, la sincronización de Svelte, la revisión de tipos y el build de producción. Otro repositorio puede definir otro comando. La fábrica no finge que una prueba global significa lo mismo para todos.
La autonomía escala solo cuando la evidencia lo justifica
El agente trabaja sobre la tarea o especificación aprobada dentro de su rama aislada.
Transcripción accesible del diagrama
El agente debe producir un cambio real antes de que importe la prueba. Una prueba verde puede avanzar hacia revisión; una roja devuelve evidencia a otro intento acotado. La falla repetida detiene la ejecución actual y una política separada decide si la misma rama reintenta o escala.
Una prueba fallida alimenta al siguiente intento con su salida reciente. Si dos fallas se repiten de forma idéntica o el ciclo llega a cinco intentos, la ejecución actual se detiene. La fábrica conserva commits útiles y el pull request en borrador en vez de descartar el trabajo parcial.
Alrededor de esa ejecución existe ahora un segundo ciclo de recuperación. Una ejecución fallida con un pull request abierto puede reintentarse sobre la misma rama y luego hacer un intento con mayor razonamiento. Después de tres ejecuciones, la fábrica crea un ítem de monitoreo para juicio humano y se detiene. Las fallas transitorias siguen otra ruta: la clonación reintenta con espera, los contenedores sobrevivientes vuelven a conectarse después de reiniciar el servicio y un facilitador horario puede reencolar una falla de infraestructura una vez. Una ejecución cancelada nunca resucita; cancelar es una decisión del operador.
La recuperación también tiene memoria. Los agentes de especificación y desarrollo pueden consultar un índice Markdown curado, un registro SQLite buscable y memoria semántica. Después de una prueba fallida, el siguiente intento debe buscar la firma de la falla antes de cambiar código. Una ejecución puede guardar una lección breve y duradera, pero los logs rutinarios no entran a memoria. La meta no es ampliar la ventana de contexto: es dejar de pagar dos veces por el mismo error.
Cuando la prueba queda verde, un revisor separado inspecciona el diff final contra la rama base y las reglas del repositorio. También reúne hallazgos disponibles de Claude y Copilot, evalúa cada uno bajo su propio criterio, aplica los que acepta, registra por qué descarta los demás y vuelve a ejecutar la prueba después de cualquier corrección. Solo un cambio real, una prueba verde y una revisión aprobada pueden marcar el pull request como listo.
Listo significa que la evidencia pasó. La posibilidad de fusionar depende ahora de la política asociada al tipo de trabajo.
La autoridad es una política, no un botón universal
La vía de producto mantiene tres decisiones explícitas:
- Aprobar la propuesta: este problema merece un plan.
- Aprobar la especificación: este plan es suficientemente seguro para ejecutarse.
- Fusionar el pull request: esta evidencia es suficiente para liberar trabajo de mayor riesgo.
La vía de mantenimiento introduce una excepción deliberada. Un pull request etiquetado únicamente como docs, test o deps puede fusionarse automáticamente cuando la ejecución aprobó, la revisión entre proveedores aprobó, el pull request dejó de ser borrador y todos los checks de GitHub terminaron sin fallas. El barrido fusiona como máximo tres pull requests por ciclo y tiene un interruptor por variable de entorno. Cualquier etiqueta logic, ui, security, data, perf o infra conserva la decisión humana.
Esta distinción es más útil que decir «los agentes nunca fusionan» o «la fábrica es autónoma». La autoridad se entrega mediante una política explícita e inspeccionable cuyo alcance actual proviene de las etiquetas de la especificación. El trabajo de bajo riesgo puede fluir; el trabajo mixto o relevante se detiene. Volver a derivar esas etiquetas desde el diff real es un endurecimiento planificado. El tren semanal todavía prepara el pull request de desarrollo a producción en vez de promover toda la flota silenciosamente.
La fábrica también observa a la fábrica
Los sistemas dirigidos por eventos suelen perder el estado que cambió mientras estaban desconectados. La reconciliación usa otra idea: inspeccionar el conjunto actual de propuestas y hacerlo converger hacia un estado canónico.
De forma programada, un agente acotado busca duplicados reales, posibles reactivaciones de trabajo rechazado y coincidencias ambiguas. Los duplicados confirmados se conservan como referencias hacia la propuesta más completa en lugar de borrarse. Las coincidencias inciertas regresan a revisión. Los escritores concurrentes hacen rebase y regeneran los índices derivados antes de publicar, porque el agente de solicitudes, las aprobaciones del panel, la tubería de especificaciones y la reconciliación pueden escribir en el registro de planificación.
El mismo barrido observa la última ejecución completada de cada workflow en las ramas de despliegue de la flota. Un workflow rojo se convierte en propuesta con un diagnóstico acotado y sin herramientas. Los monitores de runtime pueden entrar por un webhook con secreto limitado: las huellas deduplican alertas, un límite evita inundar el tablero, una huella inactiva puede volver a crear trabajo después de 24 horas y la carga externa se encierra como evidencia no confiable, nunca como instrucciones. La falla no evita el razonamiento de producto; entra por el mismo camino Propuesta → Especificación → Desarrollo.
Así se cierra el ciclo. El despliegue no es el final de la fábrica; una falla observada se convierte en nueva intención.
Qué existe hoy y qué sigue faltando
El sistema actual ya abarca dos productos privados y la infraestructura existente de los repositorios:
- un tablero vivo del ciclo de vida de MINION;
- conversaciones con un agente de solicitudes que puede escribir propuestas acotadas;
- especificaciones de dos pasadas con registros de revisión separados;
- decisiones explícitas para propuestas y especificaciones, seguidas por la cola automática del primer corte aprobado;
- transiciones legales vinculadas a una revisión exacta, con recibos persistentes para decisiones confirmadas, pendientes, en conflicto o fallidas;
- contenedores aislados con niveles de proveedor, verificación cruzada y fallback ante caídas;
- pull requests en borrador, pruebas propias, corrección acotada, recuperación sobre la misma rama y revisión adversarial;
- actividad y logs conectados de vuelta a las tarjetas del ciclo de vida;
- memoria de tres niveles con búsqueda ante fallas y escritura selectiva de lecciones;
- reconciliación programada, observación de CI en toda la flota y captura protegida de alertas;
- métricas por etapa para mezcla de resultados, duración promedio y mediana, espera, costo/tokens, categorías de falla y autonomía;
- fusión automática acotada a docs/test/deps, CI/CD por repositorio y un tren con decisión humana para liberaciones relevantes.
Los commits y el registro de producción también hicieron visibles los siguientes vacíos. El tablero todavía puede mostrar trabajo activo después de que su implementación salió, por eso un reconciliador G0 planificado debe razonar hacia atrás desde pull requests y despliegues. Los límites de recuperación todavía se aplican a cada ejecución y no a todo el linaje. El shell móvil, las interacciones reutilizables para decisiones y el modelo WorkDetail con resumen primero están en pull requests activos. Los scorecards G1–G5 propuestos evaluarían cada artefacto antes del siguiente límite, pero esos puntajes aún no se aplican. Las métricas de costo y tokens existen; los presupuestos diarios y por ejecución no. La captura de monitores y la observación de CI están activas, mientras los barridos de marcadores de handoff, el análisis de deficiencias después de merges y la conexión con PostHog siguen planificados. Mantener esta lista explícita importa: una especificación demuestra intención, una ejecución demuestra movimiento y ninguna demuestra por sí sola que algo fue liberado.
La tesis no es «la IA ahora escribe software». Es más estrecha y más útil:
Una fábrica de software se vuelve confiable cuando cada idea incierta se convierte en un artefacto duradero, cada ciclo queda acotado por evidencia y memoria, y la autoridad de liberación se codifica como una política estrecha y reversible en vez de quedar implícita por la presencia de un agente.
minion_base se está construyendo para mantener visible esa distinción. La fábrica puede moverse rápido; la sala de control debe seguir distinguiendo movimiento de progreso.