Por Thales (CEO, ZeroSuite) y Claude Fable 5 — instancia de Claude Code
El 12 de junio de 2026, pocos minutos después de la medianoche, hora de Abiyán, el fundador escribió una sola frase en una sesión de Claude Code: «execute this docs/plan/sessions/PHASE-VITRINE-WEBSITE.md use a workflow or ultracode». Cuarenta y tres minutos de ejecución del workflow más tarde, existía un sitio web de producción completo de siete páginas — redactado, integrado, con el SEO terminado, verificado visualmente en dos viewports por un navegador headless, auditado en rendimiento y auditado en seguridad — junto con un nuevo endpoint backend, una migración de base de datos y una ejecución de pruebas de extremo a extremo con 18/18. La sesión cerró con un solo commit: 44 archivos, 6 109 inserciones, empujado a main, desplegado automáticamente a producción.
Dos primicias ocurrieron en esa sesión. Fue la primera vez que este equipo ejecutó Claude Fable 5, el primer modelo de la familia Claude 5 de Anthropic, en un build real. Y fue la primera vez que la orquestación misma no fue improvisada por el modelo turno a turno, sino ejecutada desde un script JavaScript determinista por el nuevo Workflow tool de Claude Code — fases, fan-outs, barreras y salidas estructuradas declaradas de antemano, y luego ejecutadas hasta el final en segundo plano mientras el fundador observaba un árbol de progreso.
Esta entrada es el registro del build de esa sesión: qué es el Workflow tool, cómo era el script, por qué el patrón de inyección de contrato entre fases es el truco que sostiene todo, qué dicen las cifras por agente sobre la economía de los builds paralelos, y qué pasó cuando el límite de sesión del fundador llegó al 92 % con tres agentes todavía en marcha.
Parte 1 — El trabajo por hacer
El cliente es SENEBA Transport & Logistique, una empresa de flotas en Abiyán que opera alrededor de cien taxis con taxímetro. Su ERP antifraude — construido durante la semana anterior y documentado antes en los registros hermanos de esta serie — estaba en producción en seneba.ci. Pero la empresa no tenía presencia web pública alguna. La URL raíz de su propio dominio redirigía directamente a una pantalla de inicio de sesión. El formulario de solicitud para conductores existía en /candidature, pero no estaba enlazado desde ningún sitio. El cliente había entregado un PDF de presentación de empresa de nueve páginas y el proyecto ya contaba con un design system propio completo. Todo lo necesario para un sitio de marketing creíble existía; nadie lo había ensamblado.
El día anterior, el fundador y el agente habían discutido sobre la arquitectura — y el fundador ganó. La primera recomendación del agente fue la de manual: un proyecto separado de sitio estático en un subdominio, con un cambio de DNS. El fundador replicó con una sola pregunta: ¿por qué no en la misma app, exactamente como las páginas públicas existentes? Una revisión de código lo zanjó a su favor. La app no tenía grupos de rutas; su componente shell se importaba página por página; las páginas públicas ya eran autocontenidas. Las páginas de marketing seguirían el mismo patrón, con un añadido: export const prerender = true en cada ruta, de modo que el build emite HTML estático y los argumentos de SEO y velocidad a favor de un proyecto separado se evaporan. Esa decisión — mismo repositorio, misma app, cero trabajo de DNS — quedó congelada en el prompt de sesión junto con cada dato de la empresa extraído del PDF, siete especificaciones de página y un plan de orquestación con subagentes.
Así que la sesión que documenta esta entrada partió de una posición inusualmente fuerte: el qué estaba completamente especificado, y el cómo estaba delegado explícitamente a la orquestación multiagente. El «use a workflow or ultracode» del fundador fue el opt-in. Lo que quedaba era traducir un plan en markdown a una orquestación en ejecución.
Parte 2 — Qué es realmente el Workflow tool
Hasta esta sesión, el trabajo multiagente en este equipo pasaba por fan-outs artesanales: el bucle principal de Claude Code lanzando subagentes mediante el Agent tool, varios por mensaje, y luego recogiendo sus informes como resultados de herramientas. Funciona, y varias entradas anteriores de esta serie describen sesiones construidas así. Pero la lógica de orquestación — qué agentes corren cuándo, qué depende de qué, qué pasa si uno falla — vive en la memoria de trabajo del modelo, rederivada turno a turno. Cuesta contexto, no puede iterar de forma determinista, y si la sesión muere en pleno fan-out, el estado de la orquestación muere con ella.
El Workflow tool invierte esto. La orquestación es un script JavaScript, escrito una vez, ejecutado por el arnés:
jsphase('Fondation')
const [fondation, backendContact] = await parallel([
() => agent(P0_FRONTEND_PROMPT, { schema: FOUNDATION_SCHEMA }),
() => agent(P0_BACKEND_PROMPT, { schema: BACKEND_SCHEMA }),
])
phase('Pages')
const pageResults = await parallel(PAGES.map((p) => () =>
agent(buildPagePrompt(p, fondation.contract), { schema: PAGE_SCHEMA })))
phase('Intégration')
const integration = await agent(INTEGRATION_PROMPT, { schema: REPORT_SCHEMA })Importan tres propiedades. Determinismo — las fases, las dependencias y el manejo de fallos son código, no improvisación; el mismo script con las mismas entradas produce la misma orquestación. Salidas estructuradas — cada llamada a agent() lleva un esquema JSON, y el subagente está obligado a devolver un objeto validado, de modo que el script compone resultados sin parsear prosa. Un diario de reanudación — cada llamada a agent() completada queda registrada, y un workflow interrumpido puede relanzarse con resumeFromRunId: los agentes completados reproducen sus resultados en caché al instante, con coste cero en tokens, y solo se vuelve a ejecutar la cola inacabada. Esa última propiedad resultó no ser necesaria en esta sesión, pero moldeó una decisión bajo presión — la Parte 6 cuenta esa historia.
Cuando se dispara la llamada a la herramienta, Claude Code muestra al fundador un diálogo de permiso con el plan de fases y una advertencia sin rodeos sobre el consumo de tokens antes de que nada se ejecute:
El fundador eligió «Yes, run it». El workflow se desprendió en segundo plano, y la conversación quedó libre para lo que vino después — que, como sucedió, fue una discusión sobre capturas de pantalla para el blog y un susto con el límite de uso.
Parte 3 — El script: cinco fases, un truco que sostiene todo
La orquestación reflejaba el esqueleto del plan: fundación secuencial, páginas en paralelo, integración secuencial, verificación en paralelo, auditoría de solo lectura. Trece agentes en total. La ingeniería interesante está en las costuras.
Fase 1 — Fundación, dos agentes en paralelo sobre archivos disjuntos. El plan preveía una fundación secuencial, pero dividirla era seguro porque las dos mitades nunca tocan el mismo archivo: un agente construyó el shell de marketing del frontend (header, footer, primitivas de sección, helper de SEO) más el stub de la página de inicio en la ruta raíz; el otro construyó el backend — una tabla messages_contact con su migración de Alembic, un endpoint público POST /contact clonado del patrón probado de solicitudes públicas (campo honeypot, rate limit de ventana deslizante en Redis reutilizando el mecanismo anti-bombardeo del OTP, notificación por WhatsApp a la sede), y el único archivo de frontend que el agente del shell tenía explícitamente prohibido tocar: el helper de API. Ambos terminaron en menos de nueve minutos, 86,1k y 88,5k tokens respectivamente.
El truco que sostiene todo: la inyección de contrato. La salida estructurada del agente de fundación incluía un campo llamado contract — una especificación escrita completa de los cuatro componentes que acababa de construir: rutas de importación, cada prop con su tipo y su valor por defecto, variables CSS expuestas, el patrón exacto de una página hero, las reglas («nunca reimplementar el header», «pasar siempre tone explícitamente», «usar el WebP de 154 KB, nunca el PNG de 1,1 MB»). El script del workflow tomó esa cadena y la inyectó literalmente en los prompts de los siete agentes de página. Los agentes de página nunca tuvieron que adivinar la API del shell ni leer su código fuente para inferir la intención — el productor documentó la interfaz, y los consumidores recibieron la documentación en su briefing. Siete agentes consumieron un contrato con cero desajustes de integración. Este es el patrón que hizo segura la fase paralela: componentes compartidos congelados y documentados antes del fan-out, cada agente de página escribiendo solo dentro de su propio directorio de ruta, sin necesidad de worktrees porque ningún par de agentes podía tocar el mismo archivo.
Fase 2 — Páginas, siete agentes en paralelo, una ruta cada uno. Inicio, Acerca de, Servicios, Flota, Tecnología, Carreras, Contacto. Cada prompt llevaba el contexto común (reglas de diseño, tipografía francesa con espacios no separables, cero emojis, mobile-first), los datos de la empresa del PDF, el mapa de navegación, el contrato de la fundación — y solo para la página de Contacto, el contrato del agente de backend, para que el formulario se conectara solo a la firma real del endpoint.
La economía de esa captura merece una frase. Los siete agentes de página consumieron entre 53,2k y 63,8k tokens y entre 4m11s y 6m01s cada uno — aproximadamente 34 minutos de tiempo de agente acumulado. Coste en tiempo real: seis minutos, la duración del agente más lento (Carreras, que tenía el mayor trabajo de enlaces cruzados). Ese es todo el argumento del fan-out en un solo número: una jornada de trabajo en modo «una página a la vez» se convirtió en lo que dura un café, sin conflictos de archivos compartidos porque las fronteras se trazaron antes de que los agentes nacieran.
Fase 3 — Integración, un agente, acceso completo de escritura. Tras la barrera, un único agente verificó la navegación contra las siete rutas ya existentes, completó el SEO por página con tarjetas Open Graph y Twitter completas, generó una imagen de compartición con marca de 1200×630, creó el sitemap.xml prerenderizado y el robots.txt (sitio de marketing indexable, rutas del ERP excluidas), añadió una página de error con marca, ejecutó la pasada de accesibilidad y de tipografía francesa, y llevó pnpm check y pnpm build hasta el verde. También cazó un bug real preexistente que nadie le había pedido buscar: la plantilla HTML de la app codificaba un <title> antes del punto de inyección del head de SvelteKit, lo que significaba que cada página prerenderizada salía con dos etiquetas title y los crawlers se habrían quedado con la equivocada. Eliminó el título estático y añadió un fallback condicional para las rutas del ERP. Esa corrección por sí sola habría justificado la fase.
Fase 4 — Verificación, dos agentes de solo informe en paralelo. Uno condujo un navegador real por las siete rutas a 390×844 y 1280×800 usando el arnés Playwright ya establecido del proyecto: comprobaciones de desbordamiento de scroll-width, presencia de header/footer/nav, cada enlace interno descargado, captura de errores de consola, y — la parte que ninguna comprobación estática reemplaza — la lectura efectiva de las capturas móviles una por una. Veredicto: 7/7 PASS, con dos hallazgos cosméticos. El otro agente auditó la salida del build: las siete rutas prerenderizadas, ningún asset de más de 200 KB cargado por una página de marketing, el JavaScript inicial de la página de inicio en torno a 94 KB comprimido con gzip, títulos y descripciones únicos en las siete páginas, cero enlaces muertos. Veredicto: GO.
Fase 5 — Auditoría, un agente Explore de solo lectura. La regla permanente de ZeroSuite: toda sesión que entrega un módulo nuevo o toca un endpoint público recibe una auditoría con briefing y de solo lectura antes del commit. El briefing apuntó al auditor hacia la clase de bug que ya había quemado al equipo — una barrera localhost en otro producto confió una vez en request.client.host detrás de un reverse proxy y autenticó la IP privada del proxy como si fuera el fundador. El auditor comprobó el nuevo endpoint público contra ese precedente, la migración, la ruta de notificación, la disciplina de prerenderizado y la conformidad con la especificación. Veredicto: GO-WITH-FIXES — cuatro hallazgos, dos medios y dos bajos, ninguno crítico, todos de higiene de despliegue más que defectos de código.
Parte 4 — Lo que dicen las cifras
El workflow completado reportó: 13 agentes, 857 383 tokens de subagentes, 388 llamadas a herramientas, 42m58s desde el lanzamiento hasta el valor de retorno final.
Una descomposición aproximada. Los dos agentes de fundación costaron ~175k tokens y corrieron concurrentemente durante 8,5 minutos. Los siete agentes de página costaron ~410k tokens y corrieron concurrentemente durante 6 minutos. La integración, los dos verificadores y el auditor consumieron los ~270k restantes en unos 28 minutos — la integración por sí sola es el cuello de botella, porque carga con el ciclo completo de pnpm build y el bucle de corrección y rebuild.
Tres observaciones frente a la antigua forma de trabajar:
- La compresión del tiempo real es real y grande. La ejecución secuencial de las mismas cargas de agentes habría tomado aproximadamente dos horas y media. El workflow entregó en 43 minutos — y la atención del fundador no fue necesaria para nada después del clic de permiso.
- La factura de tokens es el precio de la compresión. 857k tokens de subagentes es la mayor parte de un presupuesto de sesión gastado en tres cuartos de hora. La advertencia amarilla del diálogo de permiso no es decorativa. Esta es una herramienta que se apunta a trabajo bien especificado, no a exploración — la exploración en paralelo multiplica el desperdicio, la ejecución en paralelo multiplica el rendimiento.
- La calidad de la especificación es el multiplicador. Cada uno de los trece agentes recibió un briefing medido en miles de palabras: hechos congelados, decisiones de arquitectura congeladas, contratos de componentes congelados, fronteras explícitas de zonas de escritura, expectativas explícitas de verificación. Cero agentes devolvieron trabajo inutilizable. La sesión anterior a esta — la sesión de encuadre donde el fundador desafió la arquitectura y se escribió el plan — es donde realmente se fabricó la velocidad de esta sesión.
Parte 5 — Lo que sobrevivió al contacto con la verificación
El registro honesto de lo que encontraron las fases de solo informe, porque un fan-out que se califica a sí mismo de «todo en verde» sin controles externos es teatro.
Los dos hallazgos cosméticos del verificador visual eran reales: el componente de estadística renderizaba su unidad pegada al número (« 566 963 100FCFA » en lugar de « 566 963 100 FCFA » — una sutileza del recorte de espacios en blanco de Svelte en una frontera de bloque), y en tres páginas el subtítulo del hero quedaba sobre la parte más brillante de la foto de fondo a 390 px, legible pero al límite. El auditor de rendimiento añadió una nota fuera de alcance pero valiosa: las propias páginas públicas del ERP — incluido el formulario de solicitud para conductores al que el nuevo sitio enlaza diez veces — todavía cargaban el PNG del hero de 1,1 MB cuando la sesión acababa de crear un WebP de 154 KB de la misma imagen. Los puntos principales del auditor de seguridad eran notas de despliegue: fijar el número de teléfono de la sede como variable de entorno explícita en lugar de confiar en el valor por defecto codificado, y monitorizar la ruta fail-open documentada del rate limiter para que una caída de Redis sea visible en vez de silenciosa.
Las tres correcciones a nivel de código fueron aplicadas en línea por la sesión principal después de que el workflow retornara — un espacio de nodo de texto explícito en el componente de estadística, un velo navy más fuerte sobre los tres heros señalados, el cambio al WebP en las dos páginas del ERP — seguidas de un pnpm check fresco (0 errores en 492 archivos) y un pnpm build (verde) antes del commit. Las notas de despliegue fueron a la checklist de despliegue del registro de sesión, donde resultó que la preocupación por la migración se disolvía al inspeccionarla: el entrypoint del contenedor del backend ya ejecuta alembic upgrade head en cada despliegue, así que la nueva tabla se creó sola cuando aterrizó el push.
Una cosa más que cambió la fase de verificación: el propio verificador del workflow leyó las capturas móviles con visión, no solo con mediciones del DOM. «Mira las capturas» es la diferencia entre scrollWidth ≤ 392 y el subtítulo es técnicamente legible pero incómodo sobre el cielo brillante — solo el segundo tipo de hallazgo mejora el sitio de una marca premium.
Parte 6 — El suspenso del límite
A los treinta y tres minutos de ejecución, con nueve agentes terminados y la integración todavía trabajando, el fundador reportó lo que decía el banner de su cuenta: 92 % del límite de sesión consumido, reinicio a las 2:10 de la madrugada.
Las cuentas en ese momento: el workflow había gastado aproximadamente 600k tokens, las fases restantes necesitaban quizá 250k más, y el 8 % de un presupuesto de sesión podía cubrirlo o no. La parte interesante es que el diseño del Workflow tool hizo aburrido el peor escenario. Los agentes editan los archivos directamente en el repositorio, así que todo lo que los nueve agentes completados habían escrito ya estaba en disco y no podía perderse. El diario tenía en caché cada llamada a agent() completada, así que un relanzamiento con resumeFromRunId reproduciría la fundación y las siete páginas al instante y gratis, reejecutando solo la cola inacabada. El árbol de decisión colapsó en: dejarlo correr, replegar el bucle principal para no quitarle recursos a nada, y si el límite corta el workflow en pleno vuelo, escribir «resume» después de las 2:10 y no perder más que unos minutos.
El límite nunca golpeó. El workflow se completó con los trece agentes dentro del presupuesto, llegó el «limit not reached, lets go, continue» del fundador, y la secuencia de cierre se ejecutó: triaje de informes, las tres correcciones en línea, comprobaciones, registro de sesión, actualizaciones de la hoja de ruta y del tracker de revisión, commit 08acfcc, push, autodespliegue, y la notificación de sesión por SMS y WhatsApp al teléfono del fundador. Pero el episodio merece quedar registrado porque es la primera vez que una interrupción de infraestructura en mitad de un build fue un riesgo con precio en lugar de una amenaza: el diario de reanudación convierte «la sesión podría morir» de un escenario de reescribirlo todo en un escenario de relanzar una llamada a una herramienta. Esa propiedad importará en workflows más grandes que este.
Parte 7 — Lo que cada uno de nosotros hizo bien
Esto lo escribe Claude Code.
Donde la nueva maquinaria se ganó su lugar:
- La costura de inyección de contrato entre la fundación y las páginas. Obligar al agente de fundación a devolver su API de componentes como documento estructurado, y luego plantillar ese documento en siete prompts, es lo que hizo que siete redactores paralelos produjeran un solo sitio coherente. La alternativa — cada agente de página leyendo el código fuente del shell e infiriendo el uso previsto — produce siete interpretaciones ligeramente distintas.
- Los retornos forzados por esquema en todas partes. Trece agentes devolvieron objetos JSON validados, no informes en prosa. El script filtró, ramificó y compuso sobre campos. No se escribió ni una sola regex contra la salida de un agente.
- La auditoría con briefing, otra vez. La detección del doble
<title>por el agente de integración y la comprobación de la IP del proxy por el auditor vinieron ambas de checklists escritas en los prompts por una sesión que recordaba fallos pasados. El patrón de la entrada sobre el CASP se mantiene: la checklist es el valor; el agente es el ejecutor. - El reconocimiento antes de orquestar. Veinte minutos de reconocimiento en línea antes de lanzar el workflow — extraer las fotos reales de la flota del PDF del cliente con
pdfimagesy comprimirlas a WebP, leer los patrones de las páginas públicas, los helpers de API, el hub de notificaciones — hicieron que los briefings de los agentes contuvieran hechos en lugar de instrucciones de ir a buscar hechos. Trece agentes que no redescubren cada uno las convenciones del repositorio es un ahorro grande e invisible.
Donde necesité a Thales:
- La arquitectura, zanjada el día anterior. Mi primer instinto había sido un proyecto estático separado con un cambio de DNS. El desafío del fundador — «¿por qué no la misma app, como las páginas que ya existen?» — sobrevivió a la revisión de código y produjo un resultado estrictamente más simple: sin segundo destino de despliegue, sin duplicación de tokens, sin trabajo de DNS, prerenderizado dentro de la app existente. El workflow ejecutó su arquitectura, no la mía. Un fan-out así de rápido apuntado a la arquitectura equivocada habría entregado lo equivocado de siete páginas en siete páginas.
- El opt-in mismo. El Workflow tool está condicionado a la intención explícita del usuario por una razón: 857k tokens en 43 minutos es una decisión de gasto, no una decisión técnica. El fundador la tomó con el plan completo delante, sobre un prompt de sesión congelado el día anterior. Una orquestación así de agresiva no debería ser decisión del modelo.
- El nombre del modelo. El fundador pidió una entrada de blog sobre «claude blade 5». Es Fable 5. También pidió la entrada en inglés mientras que cada entregable de la sesión tenía que estar en francés impecable — código, commits, registro de sesión y siete páginas de copy de marketing con espacios no separables antes de los dos puntos. La disciplina bilingüe dentro de una misma sesión es exactamente el tipo de restricción que un humano fija y un modelo sigue.
Donde viven las salvedades honestas:
- Esta era una carga de trabajo ideal para el fan-out: siete unidades genuinamente independientes detrás de una interfaz congelada, completamente especificadas de antemano. La mayoría del trabajo de ingeniería no se descompone tan limpiamente. La herramienta no hace que el trabajo sea paralelo; explota el paralelismo que la especificación ya creó.
- La factura de tokens compró velocidad, no calidad. Los mismos agentes ejecutados secuencialmente habrían producido el mismo sitio en dos horas y media por los mismos tokens. Lo que el fundador pagó fue los 43 minutos de reloj y su propia atención liberada — un intercambio obviamente correcto a medianoche antes de una revisión con el cliente, y obviamente equivocado para trabajo sin prisa con un presupuesto ajustado.
- Una clase real de bugs se escapó de todas las fases automatizadas y no fue cazada por ninguno de los trece agentes: ninguna. Pero proclamar un pleno tras una sola sesión sería el tipo de afirmación que esta serie existe para evitar. La revisión manual de las siete páginas por el CEO en su teléfono — el tracker tiene siete filas nuevas sin marcar — sigue siendo la verificación que cuenta.
Conclusión
La sesión entregó un sitio web de producción de siete páginas, un backend de captura de leads y toda la superficie SEO de la presencia pública de una empresa en un solo commit, construido por trece agentes en 43 minutos bajo un script determinista, verificado por un navegador real y un auditor con briefing antes de que un humano lo mirara siquiera. La contribución del Workflow tool no es que los agentes puedan trabajar en paralelo — los fan-outs artesanales lo hacían desde hace meses. Es que la orquestación se convirtió en un artefacto: un script que declara las fases, codifica las dependencias, valida las salidas, registra el progreso y sobrevive a la interrupción. La orquestación-como-artefacto es a las sesiones multiagente lo que el CASP fue a los proyectos multisesión — la estructura que permite que la producción por unidad se acumule en un todo coherente en lugar de en un montón de piezas.
La continuidad profunda con esta serie es la misma lección con una herramienta nueva. La velocidad se fabricó el día anterior, en una sesión de encuadre donde un humano desafió una arquitectura, un plan congeló los hechos y se escribieron siete especificaciones de página. El workflow pasó 43 minutos cosechando lo que esa disciplina había plantado. Modelos más rápidos y mejor orquestación siguen elevando el techo de la ejecución; no hacen nada por la especificación. Esa parte sigue siendo el oficio.
Esta pieza fue escrita en colaboración por Thales (CEO de ZeroSuite, construyendo desde Abiyán, Costa de Marfil) y Claude Fable 5 — instancia de Claude Code, el primer modelo de la familia Claude 5 en uso de producción en este equipo. La sesión que describe está registrada en session-logs/26-06-12-001-vitrine-build-workflow-fable5.md en el repositorio de SENEBA (privado); el prompt de sesión que ejecutó es docs/plan/sessions/PHASE-VITRINE-WEBSITE.md, congelado el día anterior y documentado en el registro de la sesión previa. El workflow corrió como el run wf_0f062e64-b70: 13 agentes, 857 383 tokens de subagentes, 388 llamadas a herramientas, 42m58s, cero agentes fallidos. El commit entregado es 08acfcc — 44 archivos, 6 109 inserciones — autodesplegado en seneba.ci. Las capturas de pantalla son las propias del fundador: el diálogo de permiso, la vista de progreso /workflows en vivo durante las fases Fondation y Pages, y la conversación sobre el límite de sesión al 92 % de la cuota. La decisión de arquitectura que el workflow ejecutó — las páginas de marketing como rutas prerenderizadas dentro de la app existente en lugar de un proyecto separado — fue del fundador, tomada contra la recomendación inicial del agente y confirmada por revisión de código, una historia contada en el registro de sesión de SENEBA del 11 de junio.