El orquestador no programa: trece sesiones en un día, un navegador que verifica y saber cuándo parar

Por Thales (CEO, ZeroSuite) y Claude Opus 5.5 — instancia de Claude Code

Este artículo trata de una forma de trabajar, no de un producto. El producto es una plataforma privada de un cliente, y sigue siendo privada: no vamos a nombrarla, mostrarla ni describir qué vende. Lo que sí podemos describir es su forma, porque fue la forma lo que hizo interesante el día:

• Mueve dinero real. Cada saldo es un libro mayor de partida doble, y un error llega a un
• cliente.
• Sustituye un back office que lleva quince años en uso. El propietario se sabe de memoria
• cada etiqueta de menú y espera volver a encontrarlas.
• Cada push a main despliega en producción. No hay CI detrás, solo un script de gate local.
• El propietario revisa el trabajo en un navegador. No lee diffs.

Entre la tarde del 29 de septiembre y la tarde del 30 de septiembre de 2026, una sesión de Claude Code ejecutó otras trece sesiones de Claude Code, una tras otra, sobre esa plataforma. La sesión que las dirigía no escribió ni una línea de código de producto. Así es como funciona, lo que salió mal y las tres reglas que dejamos por escrito al final del día.

Parte 1 — Una fase, un proceso nuevo

La cola de trabajo vive en el repositorio, como prompts de CASP: un archivo Markdown por fase, con status: queued, un puntero next_after, una lista MUST y una lista DO NOT. casp/state.json indica qué prompt va a continuación.

La sesión con la que hablas es el orquestador. En cada fase hace cinco cosas:

1. Comprueba la cola: el siguiente prompt existe, está queued y su next_after apunta a algo
2. que ya se entregó.
3. Decide la forma, en solitario o en flota, y escribe la decisión en casp/state.json
4. antes de lanzar. Todas las fases del día salieron en solitario, por una razón que podíamos
5. medir: la gate usa puertos fijos, una base de datos de pruebas compartida y un único directorio
6. de build. Dos procesos escribiendo a la vez no producirían un conflicto de git. Producirían
7. tests en rojo que alguien achacaría al diff equivocado.
8. Lanza un hijo: claude -p "/next …" dentro de un script iniciado con nohup, con la salida
9. a un archivo de log.
10. Lo vigila: un monitor en segundo plano emite una línea por cada commit nuevo, una línea
11. cuando el hijo termina y una línea STALLED si ningún archivo del repositorio ha cambiado en
12. veinte minutos.
13. Verifica él mismo el cierre: nada sin pushear, un árbol limpio, casp check que sale con
14. 0, el id de sesión que avanzó, el log presente y un script que lee qué commit está sirviendo
15. realmente producción.

El hijo arranca sin nada más que el repositorio. Esa es la idea: el contexto nunca se acumula de una fase a otra, y cada hijo lee el CLAUDE.md del proyecto, el prompt y el log de la sesión anterior. Al cerrar, escribe el siguiente prompt y mueve los punteros, y el orquestador comprueba que lo hizo.

Tres detalles medidos importan más que el diseño:

• A un hijo headless no se le puede despertar. En modo -p, las tareas en segundo plano se
• matan a los 600 segundos salvo que se exporte CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0, y nadie
• reanuda a un hijo que «espera al monitor». Las gates largas corren en segundo plano con un bucle
• de sondeo acotado que fija un indicador explícito, nunca el $? de un bucle, que devuelve el
• código de salida del último sleep.
• El orquestador también puede engañarse a sí mismo. A última hora, pgrep -f chain-child.sh
• informó de un hijo todavía vivo cuando ya había terminado. El patrón coincidía con el propio
• comando de shell del orquestador, que contenía la misma cadena. Pasamos a buscar el proceso
• claude -p.
• Un despliegue que falta no es un despliegue fallido. Una tarde, producción sirvió durante
• cuarenta y cinco minutos un commit de hacía tres pushes. El orquestador lo informó y pidió al CEO
• que mirara el panel de despliegue. Diez minutos después la cola se había vaciado y todo estaba
• al día. La regla que nos quedamos: informar de lo que lees y no sacar conclusiones de una sola
• lectura.

Parte 2 — Una doctrina escrita en una línea, no repetida en cada prompt

La tarde del 29, la postura del propietario se endureció en una frase que el CEO transmitió literalmente:

« je ne veux plus prendre de décisions autres que ce qui est dans le legacy et que le proprio a l'habitude de voir » («No quiero tomar ninguna decisión que no sea lo que está en el sistema legacy y lo que el propietario está acostumbrado a ver.»)

A los clientes del propietario les gusta el copia y pega: si el menú antiguo muestra una entrada con un sufijo entre paréntesis, el nuevo muestra exactamente lo mismo, paréntesis incluidos.

Un hijo headless no puede preguntar. Así que la doctrina entró en el CLAUDE.md del proyecto, en la sección que los hijos leen para decidir solos, como regla de nivel 0 (aplicarla, citarla, no preguntar):

• los menús, las etiquetas y los nombres de página siguen el sistema legacy en producción;
• cuando dos sistemas legacy no coinciden, gana el código que realmente escribe en producción;
• **cuando el legacy tiene un defecto o le falta un límite, aplicar buenas prácticas y dejarlo
• registrado**;
• nunca copiar un defecto de dinero o de seguridad.

La tercera regla demostró su valor esa misma noche. El sistema legacy tenía un tope sobre el importe que una sola operación podía abonar, pero un indicador de configuración lo había desactivado. La reacción del CEO fue una línea: «hay que poner un límite, si no es peligroso». No elegimos una cifra por intuición. Dimensionamos el tope a partir del historial de producción, que el propio CEO consultó, en solo lectura, desde la consola de la base de datos: el mayor importe abonado nunca, la distribución por encima de él y el margen semanal del negocio. El valor por defecto del legacy habría cortado 1.498 abonos históricos reales: una buena razón para no copiar el valor, aun restaurando el límite.

Parte 3 — Un navegador en manos del CEO, y lo que no puede demostrar

Los hijos corren en headless. Ninguno ve una pantalla. Cada log de sesión del día termina con la misma línea honesta: no visto en un navegador por un humano.

Así que el orquestador delega una comprobación, después de las sesiones que importan, a un subagente que maneja el propio Chrome del CEO a través de Claude in Chrome. El CEO ya tiene la sesión iniciada como administrador. El brief es corto y estricto:

• Solo lectura. Ningún formulario enviado y ningún clic en Confirmar, Acreditar, Pagar,
• Rechazar o Eliminar. En las pantallas de dinero, el agente puede abrir un diálogo de confirmación
• para leer los importes que anuncia, y luego debe cancelarlo sin escribir nada.
• Medir, no capturar. document.title, h1, scrollWidth, el atributo de un botón, dos
• capturas de pantalla como máximo.
• Informar en treinta líneas: punto por punto, defectos ordenados por gravedad, sin
• correcciones de código.

Seis de esas pasadas se ejecutaron durante el día. Encontraron problemas reales que los tests no habían detectado:

• una tabla tres píxeles más ancha que su contenedor, lo que cortaba la última columna;
• un botón de eliminar que había quedado dentro de una fila de la tabla, en contra de la regla
• según la cual las escrituras viven en el pie del modal;
• un botón de confirmación que seguía activo con el campo del motivo vacío;
• el buscador del panel de administración, que ofrecía páginas del espacio de clientes;
• un bloque de resumen que mostraba cero cuando no había filtro de fecha, mientras la lista de
• debajo mostraba depósitos.

Una pasada también informó de un defecto que no existía.

El agente informó de que cerrar un modal de detalle dejaba su id en la URL, de modo que al recargar se volvía a abrir. Lo probó de tres maneras, y las tres fallaron. El hijo anterior había declarado la corrección «correcta por construcción» sin haber podido reproducir el bug. La combinación parecía demoledora: una corrección que nadie había reproducido y un verificador que reproducía el bug tres veces.

El orquestador redactó una sesión para corregirlo, con un test sobre el stack real que primero tenía que fallar. Luego pidió al CEO una comprobación manual de diez segundos: abrir una fila, pulsar Escape, recargar. El modal siguió cerrado.

La pestaña del agente había estado todo el tiempo en visibilityState: hidden. Las pulsaciones de teclado reales nunca llegaban a la página, así que cada gesto se había emulado en JavaScript. El agente lo había dicho en su informe, pero el orquestador no le dio peso hasta la prueba humana. La sesión de corrección se reescribió como una salvaguarda de regresión: añade el test sobre el stack real y solo cambia el código si el test falla. El test pasó.

La lección que nos quedamos tiene dos mitades:

• Quien implementa no debería ser quien verifica. Un hijo que «no consigue reproducir» no ha
• demostrado nada.
• **Una herramienta de verificación tiene sus propios límites, y a un verificador que los declara
• hay que creerle.** Desde ese día, cada brief dice: si la pestaña está oculta y el teclado no llega
• a la página, emula, dilo y no concluyas un defecto solo por eso. Cuando un solo gesto decide,
• diez segundos de una mano humana valen más que cualquier herramienta.

Parte 4 — Un design system en una mañana, pasando primero por una maqueta

El propietario envió una captura de pantalla del nuevo panel de administración, reconstruido el día anterior para reflejar la página legacy, y no tenía buen aspecto:

• tres títulos apilados uno encima de otro;
• un panel de detalle a la derecha que se comía la tabla, de modo que las últimas columnas se
• salían de la pantalla;
• ids mostrados solos, sin nombres;
• una barra lateral en la que cada entrada llevaba una descripción de tres líneas.

El CEO pidió rehacer el diseño «teniendo en cuenta todas las funciones del legacy».

El orquestador no envió a un hijo a rediseñar el panel. En ese momento había un hijo programando en las mismas carpetas, y un diseño es una decisión que el propietario tiene que ver antes de que nadie lo construya. Lo delegó en un subagente de diseño con dos entregables y sin acceso de escritura al repositorio:

• Una especificación: principios, tokens, componentes y una tabla que asocia cada defecto
• observado con la regla que lo corrige. Se basaba en las páginas legacy leídas con el mismo
• navegador y en el código fuente, en solo lectura.
• Una maqueta HTML estática de la peor página, rellenada con las filas exactas de la captura
• del propietario, en ancho de escritorio y a 375 px.

Mientras el agente trabajaba, el CEO añadió una frase:

« l'onglet blanc à droite doit être un joli modal qui s'ouvre pour afficher plus de détails sur chaque ligne » («El panel blanco de la derecha debería ser un modal bonito que se abra para mostrar más detalles de cada fila.»)

El orquestador se la reenvió al agente en marcha, que reorganizó la especificación en torno a ella: la tabla conserva todo el ancho y los detalles se abren en la única primitiva de diálogo que ya existía en el proyecto.

La maqueta se abrió en el navegador del CEO, y la aprobó. Después, el orquestador enmendó al agente de diseño en un punto, apoyándose en la doctrina. El agente recomendaba escribir la moneda en su forma local legible. Tanto el sistema legacy como el código existente escriben el código ISO, y «copiar lo que el propietario está acostumbrado a ver» es una regla de nivel 0. El orquestador no enmienda a un subagente por gusto, solo en virtud de una regla escrita.

La migración se hizo luego como una serie de sesiones encadenadas:

• S1, una página piloto: shell, barra lateral, tabla agrupada, modal de detalle y un test de
• Playwright añadido a la gate.
• S2: filtros y paginación numerada compartidos entre las páginas de listado.
• S3: colas de validación, donde cada botón de escritura pasó al pie del modal, detrás de una
• confirmación.
• S4a: las páginas de cuenta y de detalle.

Cada pasada de navegador volcó sus defectos en el prompt de la sesión siguiente. La última pasada del día solo encontró tres, menores.

Parte 5 — «Lo que lleva tiempo son los tests, no las correcciones»

A media tarde, el CEO propuso un atajo:

« ce sont les tests qui prennent bcp de temps et non les fixes, exemple un fix peut prendre 5 mins et un test 1h, donc on va être très smart, on fixe bcp de bugs en série sans test et après on fait test groupé » («Lo que lleva mucho tiempo son los tests, no las correcciones: una corrección puede llevar 5 minutos y un test una hora, así que seamos listos: corregimos muchos bugs seguidos sin tests y luego los probamos todos juntos.»)

La intuición merecía una medición, no un sí. El orquestador leyó las marcas de tiempo de los logs de cada paso de la gate. La gate completa tardaba cuatro minutos: format, vet, tests de Go, seis comprobaciones de front-end, build, tests de navegador y un smoke test de cada página de menú contra el stack real. Una sesión completa tardaba de treinta y cinco a cuarenta y dos minutos. La gate era más o menos una décima parte.

El coste real estaba en otro sitio, en la sobrecarga fija de cada sesión y de cada verificación:

• leer el contexto;
• el ritual de cierre;
• una pasada de navegador de diez minutos después de cada sesión.

Así que la respuesta fue mitad sí y mitad no:

• Sí a agrupar. De cinco a diez defectos por sesión, una sola gate al final, una pasada de
• navegador cada dos o tres sesiones, más una después de cualquier cosa que toque dinero.
• Sí a menos tests nuevos. Un test nuevo solo para dinero, seguridad o un defecto que ya ha
• vuelto una vez. Una etiqueta, un espaciado o un título se corrigen sin test dedicado.
• No a pushear sin la gate. Aquí un push es un despliegue de un sistema que mueve dinero.
• Cuatro minutos frente a una producción en rojo no es un intercambio.

El CEO estuvo de acuerdo, y la regla entró en el CLAUDE.md del proyecto como nivel 0, de modo que cada hijo posterior la aplicó sin que se lo dijeran. La sesión siguiente corrigió ocho defectos en una pasada con una sola gate. Su primera ejecución salió en rojo en una única aserción, que esperaba el formato de moneda antiguo: era una de las ocho correcciones funcionando como debía.

Del mismo día salió otra medición. Una sesión dedicada a saldar deuda de la gate sustituyó la preparación de la base de datos en cada test por una base de datos plantilla. El paquete de tests de Go pasó de 265 segundos a 59. La velocidad vino de arreglar la parte lenta, no de saltarse la comprobación.

Parte 6 — Una decisión de dinero que un hijo se negó a tomar

Una sesión en cola debía reproducir un interruptor del legacy: un depósito hecho por un agente a un cliente puede marcarse como «Available» o «Not Available». El prompt decía: construye el botón solo si la API ya admite esa escritura. No la admitía, y el hijo se detuvo en el sitio correcto. Registró una pregunta de nivel 1, que un hijo nunca debe responder por sí mismo, y explicó por qué un simple indicador no bastaba.

En el sistema nuevo, ese depósito es una transferencia en el libro mayor que ya ha ocurrido. Al agente se le cargó el importe, al cliente se le abonó con una bonificación, y puede que el cliente ya haya gastado el dinero. Un estado que no mueve dinero reproduciría exactamente el tipo de defecto que la doctrina prohíbe copiar. El hijo recomendó una reversión explícita: asientos inversos exactos, un motivo obligatorio y registrado, y un rechazo si el saldo del cliente ya no la cubre.

El CEO lo aprobó en una línea. La sesión siguiente lo construyó:

• Asientos inversos exactos, leídos del libro mayor en lugar de recalculados con las tarifas
• de hoy.
• Cada bolsillo restaurado exactamente, cuando el agente había pagado desde varios.
• Una sola transacción, con una reserva única para que dos administradores que hacen clic a la
• vez produzcan una sola reversión.
• Tests del camino del dinero para cada caso.

En el navegador, el diálogo de confirmación muestra los dos lados del movimiento antes de que nadie confirme.

La misma sesión anotó, en su lista de pendientes, que una transferencia de saldo entre clientes enviada al número de teléfono equivocado tampoco tenía vuelta atrás. El orquestador recomendó extender la reversión a ese caso, por una razón sencilla: un número equivocado va a ocurrir en producción. El CEO estuvo de acuerdo, y una sesión después salió como una función aparte. La primera no se refactorizó para la ocasión.

Parte 7 — «No sé cuándo cerrar una sesión»

Al final del día, el CEO pidió al orquestador que mostrara su uso de contexto y lo comentara. Las cifras no tenían nada de especial:

• 287k tokens usados de un millón, el 29 %, casi todo conversación;
• unos 30k añadidos en el último bloque de trabajo;
• 680k tokens todavía libres.

Lo que importaba era lo poco que era. Trece sesiones y seis pasadas de navegador se habían ejecutado cada una en su propio proceso o contexto de subagente, y solo habían devuelto sus conclusiones. Sin eso, el orquestador habría sido compactado varias veces.

Entonces el CEO admitió algo que cualquier usuario intensivo de estas herramientas reconocerá:

« pour te dire la vérité je ne sais pas quand fermer et quand ouvrir une nouvelle session, vu que j'ai des tâches presque illimitées » («Para serte sincero, no sé cuándo cerrar y cuándo abrir una sesión nueva, porque mis tareas son casi ilimitadas.»)

Con una cola infinita, la cola no puede ser la señal. La señal es el estado del contexto. Escribimos cuatro condiciones, y basta con una para cerrar:

1. Se ha terminado un bloque de trabajo coherente: pusheado, archivos de estado actualizados.
2. Es el momento más barato, porque la nota de traspaso se escribe sola.
3. Cambia el tema. El contexto del primer tema enturbia el segundo.
4. La sesión ya se compactó una vez. Un resumen basta para terminar el bloque en curso, no para
5. empezar uno nuevo.
6. Se pilla al agente con una creencia caducada: se apoya en un estado que leyó hace horas y
7. que ha cambiado desde entonces. Esta prevalece sobre cualquier cifra.

Las cifras van después: por encima de unos 300 a 400k tokens, o de seis a ocho horas de trabajo, cerrar en el siguiente límite de bloque aunque todo vaya bien. Y nunca cerrar en mitad de un bucle cerrado de «ver el defecto → corregir → volver a comprobar» con el humano.

Cerrar cuesta poco porque nada importante vive en la sesión. La cola, el siguiente prompt, los logs, la doctrina y la regla de agrupación están todos en disco. Una sesión nueva los lee en pocos minutos por unos 30k tokens. Pusimos la regla en el CLAUDE.md global y en la memoria persistente, con una instrucción que la hace útil: *recuérdaselo tú mismo al usuario, en una línea, cuando una condición se cumpla*. También invertimos una costumbre: una compactación automática inminente es ahora una señal para cerrar, no para compactar.

Cómo copiar esto

1. Separa el orquestador de los ejecutores. La sesión con la que hablas decide, lanza, vigila y
2. verifica. Cada fase corre en un proceso headless nuevo que solo conoce el repositorio.
3. Pon la cola y el estado en disco, con punteros que el orquestador pueda comprobar
4. mecánicamente después de cada fase: id de sesión avanzado, siguiente prompt en cola, árbol
5. limpio, pusheado, producción sirviendo lo que crees que sirve.
6. Escribe la doctrina del propietario como una sola línea a nivel de decisión en el archivo
7. que lee cada hijo. Incluye la vía de escape: «nunca copiar un defecto de dinero o de seguridad;
8. donde falte un límite, aplicar buenas prácticas y dejarlo registrado».
9. Dales a los hijos una escalera: aplicar lo que ya está decidido, decidir y registrar lo que
10. es reversible, detenerse ante el dinero, lo irreversible, el precio y el alcance.
11. Verifica en un navegador real con un agente separado y de solo lectura, que mida en lugar de
12. capturar. Pídele que declare los límites de su propia herramienta, y resuelve cualquier gesto
13. decisivo aislado con diez segundos de una mano humana.
14. Diseña a través de una maqueta que apruebe el propietario antes de que ninguna sesión la
15. construya, y enmienda a un subagente solo en virtud de una regla escrita, nunca por gusto.
16. Mide antes de cambiar tests por velocidad. Agrupa correcciones, ejecuta la gate una vez,
17. escribe tests nuevos solo donde el dinero, la seguridad o la reincidencia los justifiquen, y
18. nunca pushees código sin verificar que se despliega.
19. Deja por escrito cuándo cerrar, y haz que el agente sea el primero en decirlo.

CASP — el Coding-Agent State Protocol. Tu agente de IA recorre toda la hoja de ruta sin perder el hilo. Nativo de git, solo local, MIT, cero telemetría. Creado por Juste Thales Gnimavo, de ZeroSuite, un CEO en solitario cuyos productos funcionan en producción con Claude como único ingeniero. Instalación: npm i -g @justethales/casp · https://casp.sh · https://github.com/ThalesGnimavo/casp