20260911 #4 — El día uno: un molde

Hoy cada proyecto que arranco nace igual. Tiene un molde: doce agentes (cada uno es un archivo que define un rol, con lo que puede y no puede hacer), un loop en el que un agente escribe código y otro lo revisa, un conjunto de reglas comunes, un registro de tickets, un sistema de sesiones que documenta cada jornada y un ledger de costos. Todo eso lo instala un comando de scaffolding: un script que copia la estructura base en un directorio vacío y la deja lista para el proyecto nuevo. Ya corre en ocho proyectos.

Quise saber de dónde salió, y la respuesta está en un solo archivo: 20260815-V01_creacion_backlog_y_primeros_pasos.md, la primera sesión de la que tengo registro. Sábado 15 de agosto, de 16:46 a 00:02. Siete horas.

Lo primero que noté al releerlo es que el día uno no fue el día uno. La base de datos tiene cambios fechados el 9 de agosto y el ledger registra USD 40 de ese mismo día. Una semana de trabajo sin registro. Lo que el archivo del 15 documenta como "hecho" es, en parte, el inventario de esa semana —porque ese fue el día en que apareció el sistema de sesiones. La primera sesión registrada es la sesión en la que empecé a registrar.

Lo que se armó en un día

El archivo agrupa el trabajo en cinco bloques, todos marcados como terminados. Primero, el producto: la base de datos con sus diez tablas y permisos, la aplicación web, y tres historias de usuario funcionando —registrarse, iniciar sesión, editar el perfil.

Y después, lo que hoy me importa más: la fábrica. Seis agentes con roles distintos —el que escribe código (coder), el que lo revisa (code-reviewer), el que coordina a los dos (coordinator), el que planifica (planner), el que captura trabajo pendiente (backlog-manager) y el que lleva los costos (cost-monitor). Una regla de backlog: el trabajo que se descubre a mitad de camino se anota como ticket en vez de perderse. Un comando para ejecutar un ticket de punta a punta desde la terminal. Y un hook —un script que corre solo cada vez que el modelo termina un turno— que extraía el consumo de tokens y lo graficaba. Once tickets, veinte historias, y una sección del archivo de instrucciones que decía cómo se enrutaban los pedidos a los agentes.

Primero el producto, después la fábrica. Pero la fábrica es lo que sobrevivió.

Las decisiones que siguen vivas

La sección "Decisiones principales" tiene nueve líneas. Tres de ellas son hoy la columna vertebral del molde.

El routing de agentes es una instrucción, no un mecanismo. La línea original: "subagentes nunca se invocan automáticamente". No hay código que lo imponga; es una tabla en el archivo de instrucciones que dice qué frase activa qué agente —"planificá" va al planner, "ejecutá el ticket" al coordinator, y cualquier pregunta normal se responde sin delegar a nadie. Esa frase sigue textual en el proyecto original y, palabra por palabra, en el proyecto desde el que escribo esta nota.

El aislamiento es por permisos. Cada agente declara qué herramientas puede usar, y la única que permite lanzar otros agentes la tiene solo el coordinator. El que escribe código no puede delegar; el que revisa tampoco. Hoy hay doce agentes en vez de seis y la regla se mantiene con una sola excepción deliberada: el agente que hace el chequeo de salud del proyecto también orquesta.

El loop tiene tope. Si el revisor y el que escribe no se ponen de acuerdo en tres vueltas, el ticket queda bloqueado y se informa. Sigue en el mismo archivo, con el mismo número.

Las tres son decisiones de límite —qué no se hace solo, quién no puede hacer qué, cuándo parar—, no de capacidad. Lo que se decidió sobre qué podían hacer los agentes cambió mucho; lo que se decidió sobre qué no podían hacer, nada.

Lo que no aguantó

El mismo archivo tiene la otra mitad. "Sin git por ahora (directorio local)": git es el control de versiones, y el proyecto original lo incorporó dos semanas después; este proyecto también lo tiene. "Costo por llamada no disponible — solo total manual vía ledger": sigue sin estar disponible, pero el ledger pasó de uno por proyecto a uno solo compartido; el gráfico de consumo quedó huérfano. El envío de correos que limitaba los registros a dos por hora era el primer pendiente; se resolvió al día siguiente.

Y el dato más incómodo: el proyecto que parió el molde tiene 109 tickets (99 hechos), 34 sesiones y su última sesión es del 22 de agosto. Una semana de vida intensa y después silencio. El molde, en cambio, se extrajo el 20 de agosto y desde entonces no paró.

No sé si es un fracaso del producto o el resultado esperable de construir primero la fábrica. Lo que sí sé es que la sesión del 15 de agosto vale como registro no por el código que lista, sino por las nueve líneas de decisiones que dejó escritas. El código se reescribió; las decisiones se copiaron.

Tags: sesión fundacional · molde · scaffolding · agentes · decisiones que sobreviven