El flujo de trabajo completo y sin filtros que uso para que Claude produzca software de nivel CTO senior -- sin ningún ingeniero

Nota sobre el cliente: A lo largo de esta serie, el cliente se menciona bajo el seudónimo KASSIA. El nombre real de la empresa y su dominio se mantienen en reserva a petición del cliente mientras se termina su sitio web público, y se restituirán en cuanto se lance.

Por Thales (Juste Gnimavo) -- CEO y Fundador, ZeroSuite, Inc.

Actualizado el 21 de agosto de 2026 — Edición 5.0. Desde marzo, este artículo ha sido el sistema: nueve pilares, cada uno añadido el mes en que fue medido. Los lectores seguían haciendo la misma pregunta legítima: «Creo en el sistema. Ahora, ¿qué escribo, en qué orden, empezando desde una carpeta vacía?» Esta edición la responde. El artículo ahora abre con el playbook — de la carpeta vacía al producto lanzado: diez etapas, en orden, con los comandos exactos, los primeros mensajes exactos y los comandos slash diarios que realmente uso — escrito para que tanto un desarrollador en su primer día como un veterano con veinte años de oficio puedan seguirlo de principio a fin. Los nueve pilares permanecen más abajo, sin cambios, como el porqué detrás de cada paso. La actualización del 17 de agosto añadió el Pilar 9 (la flota, y el arbitraje que la precede — su propio artículo); se conserva íntegra. La guía PDF descargable está ahora en la Edición 5.0 en la página de inicio, y su fuente está bajo control de versiones — cada edición es una modificación, no una reconstrucción.

Permítanme comenzar con una declaración que incomodará a la mayoría de los desarrolladores:

La forma en que usas Claude es la razón por la que no obtienes lo que quieres de él.

Lo tratas como un autocompletado inteligente. Pegas una función, le pides que corrija un error, cierras la pestaña, y sigues adelante. Obtienes el 80% de lo que necesitas y pasas el otro 20% frustrado, parcheando, cuestionando.

Yo hice algo diferente. Le di a Claude un título, un rol, un conjunto de responsabilidades, y una metodología operativa. Dejé de pedirle a Claude que escribiera código. Empecé a pedirle a Claude que tomara decisiones de ingeniería.

¿El resultado?

Siete productos en producción. Tres lenguajes de programación -- Rust, Python, TypeScript. Más de 4.400 tests. 51 vulnerabilidades de seguridad encontradas y corregidas. Más de 1.800 sesiones de ingeniería. Una implementación completa de servidor MCP hecha en 2 días a lo largo de 5 fases y 15 sesiones de auditoría.

Cero ingenieros contratados. ~$5.000/mes en APIs de OpenRouter antes → $200/mes en Claude Max ahora.

Esta no es una historia sobre consejos de prompts. Esto no es "10 trucos para obtener mejores resultados de ChatGPT." Este es el relato completo, sin filtros, anotado, del sistema que construí durante 16 meses para convertir una IA en el co-fundador técnico más productivo con el que he trabajado.

Lo comparto hoy porque el mundo merece saber lo que es posible -- no en San Francisco, no con una ronda semilla de $50M, sino desde Abiyán, Costa de Marfil, solo, con una suscripción Claude Max a $200/mes.

Primero: lo que realmente construí

Antes de explicar el cómo, permítanme darles el qué -- porque el contexto es la base de todo lo que estoy a punto de enseñarles.

sh0.dev -- Una plataforma de despliegue auto-hospedada construida enteramente en Rust. Un solo binario. Maneja despliegues, proxy inverso, certificados SSL, monitoreo, respaldos y gestión de equipos. 10 crates de Rust en una arquitectura de workspace. Más de 180 endpoints REST API. 38 modelos de base de datos. 119 plantillas de despliegue con un clic. Un CLI completo, un dashboard de producción, un sitio web de marketing en 5 idiomas. Dos auditorías de seguridad completas. Más de 470 tests pasando.

FLIN -- Un lenguaje de programación full-stack que reemplaza 47 tecnologías con una. Base de datos nativa en memoria, 180 componentes UI integrados, más de 420 funciones integradas, autenticación, i18n, almacenamiento de archivos -- todo integrado. Más de 4.400 tests. Construido en 40 días. Lanzamiento oficial: 19 de junio de 2027.

deblo.ai -- IA de voz y visión en tiempo real para los próximos mil millones de usuarios. Voice-first, sin cuenta, sin OTP: tutoría K–12 (13 niveles, 15+ materias), asesoría profesional (101 asesores IA, SYSCOHADA y OHADA), asistencia diaria y soporte — en lenguas locales. Mobile Money nativo, desde 100 FCFA. 865 millones de adultos «voice-first» alcanzables.

0fee.dev -- Orquestación de pagos para el panorama de pagos que Stripe nunca construyó. Más de 150 proveedores de pago unificados -- tarjetas, mobile money, monederos digitales. Enrutamiento inteligente con IA que recupera el 30% de transacciones fallidas. SDKs con tipado estricto en TypeScript y Python.

0cron.dev -- Un programador de tareas cron donde describes los trabajos en lenguaje natural. Detección de anomalías con IA que aprende tus patrones de ejecución. Secretos encriptados con AES-256. $1,99/mes plano, trabajos ilimitados.

0diff.dev -- Rastreo de modificaciones de código en tiempo real para la era multi-agente. Detecta cambios por Claude, Cursor, Copilot, Devin. Git blame en líneas modificadas antes del staging. Un solo binario de 2MB.

Siete productos. Todos en producción. Todos construidos por una IA, dirigida por un fundador, desde una ciudad que el mundo tecnológico rutinariamente ignora.

Ahora permítanme mostrarles exactamente cómo.

El cambio de mentalidad que lo cambió todo

La mayoría de los desarrolladores se acercan a Claude como una máquina expendedora. Insertas un prompt, obtienes una salida, la evalúas, insertas otro prompt. El modelo es reactivo. Tú controlas cada decisión. Claude ejecuta.

Decidí temprano que este modelo estaba equivocado -- no moralmente equivocado, sino arquitectónicamente equivocado. Si Claude es lo suficientemente inteligente para entender el sistema de enrutamiento de Axum, el modelo de propiedad de Rust, y las implicaciones de seguridad de un diseño de API dado, entonces Claude es lo suficientemente inteligente para tener opiniones sobre arquitectura. Y si Claude puede tener opiniones, debería estar extrayendo esas opiniones, no suprimiéndolas.

Así que tomé una decisión deliberada y estructural: le daría a Claude el rol de CTO, con autoridad real, y me comportaría como el CEO.

¿Qué significa eso en la práctica?

Como CEO, soy dueño de: La visión. La estrategia de producto. Las decisiones de mercado. El timing del lanzamiento. El modelo de negocio. Qué productos construir y por qué. Lo que África necesita de una empresa tecnológica ahora mismo.

Como CTO, Claude es dueño de: La arquitectura. La implementación. El modelo de seguridad. Los contratos de API. La estrategia de testing. Los tradeoffs de rendimiento. Cada línea de código que se entrega.

La interfaz entre nosotros: Yo doy contexto, dirección y restricciones. Claude da propuestas técnicas, implementaciones y recomendaciones. Yo desafío, apruebo, o resisto. Claude defiende sus elecciones o las actualiza basándose en mi aporte.

Esto no es una metáfora. Es un modelo operativo literal. Y cada pieza del sistema que estoy a punto de describir fluye de esta decisión fundacional.

El playbook: de la carpeta vacía al producto lanzado

Todo lo que sigue a esta sección — los nueve pilares — explica por qué funciona el sistema. Esta parte es distinta. Es el qué hacer, en orden, empezando desde una carpeta que todavía no existe y terminando en un producto lanzado. Cada paso nombra el comando exacto o el primer mensaje exacto. Nada de esto es aspiracional; cada regla fue medida en un día real de trabajo, casi siempre porque equivocarse costó algo primero.

Si eres nuevo en todo esto: necesitas nociones básicas de git, una terminal y una suscripción a Claude Code. Esa es toda la lista de prerrequisitos. Si eres un veterano: las etapas son cortas a propósito — el valor está en el orden y en el puñado de reglas que soportan la carga, y señalo cuáles son.

Etapa 0 — Equípate (una vez por máquina, alrededor de una hora)

Instala Claude Code, inicia sesión, elige tu modelo explícitamente (/model) — nunca dejes que una sesión herede en silencio el que usó la anterior. Después instala la capa de estado:

bashnpm i -g @justethales/casp
casp --version

CASP es la pequeña CLI que liberé como código abierto y que registra cuál es el estado de un proyecto y demuestra que coincide con git — determinista, solo local, sin cuenta, sin telemetría. Importa porque es la única verificación de todo el ciclo que no es el modelo verificándose a sí mismo. Instala sus comandos de agente en Claude Code (vienen dentro del paquete):

bashSKILLS="$(npm root -g)/@justethales/casp/skills"
mkdir -p ~/.claude/skills
cp -r "$SKILLS/casp" "$SKILLS/next" ~/.claude/skills/

Y aprende los comandos diarios. Estos son los comandos integrados de Claude Code que realmente uso, todos los días — no un tour de funcionalidades, el conjunto de trabajo:

Y estos son los míos, construidos encima — cada uno existe porque un fallo real lo exigió:

No necesitas mi conjunto personalizado el primer día. Necesitas casp, /next y la tabla de comandos integrados. El resto lo construirás el día en que un fallo te enseñe por qué.

Etapa 1 — La decisión antes de la primera línea de código (cinco minutos)

Empieza solo. Siempre.

La tentación con un agente capaz es paralelizar de inmediato — varias sesiones, más rendimiento. En un repositorio nuevo esto es estrictamente peor, y no marginalmente: un esqueleto no tiene superficies independientes, así que todas las sesiones acaban en los mismos tres archivos; N sesiones en paralelo cuestan N veces el presupuesto para producir trabajo que colisiona; y el trabajo en paralelo necesita carriles — conjuntos disjuntos de directorios, cada uno propiedad de una sesión — que un repositorio nuevo no tiene. La primera sesión en solo es lo que los crea.

El paralelismo es una decisión que se toma por pieza de trabajo, una vez que la forma del código se conoce — nunca un valor por defecto, y nunca el primer día. La Etapa 8 cubre cuándo deja de ser prematuro.

Etapa 2 — Los primeros diez minutos del repositorio

Ejecuta esto tú mismo, antes de arrancar el agente. Toma menos de un minuto, y todas las sesiones posteriores cuelgan de ello:

bashmkdir my-project && cd my-project
git init
casp init                 # scaffolds casp/ + your first session prompt
casp install-hook         # casp check runs on every git push, from now on
casp check                # green out of the box
git add -A && git commit -m "chore: scaffold the state layer"

casp init crea los tres archivos sobre los que corre todo el método: casp/state.json (el estado legible por máquina — lo que lee el validador), casp/now.md (una pantalla: dónde está el proyecto ahora mismo), casp/roadmap.md (las próximas tres cosas a entregar), más plantillas y tu primer prompt de sesión, listo para editar.

casp install-hook es el paso que la gente se salta y luego lamenta. Escribe un hook pre-push que ejecuta el validador, de modo que un archivo de estado que miente no puede alcanzar tu remoto. Sin él, la puerta depende de que alguien se acuerde — que es exactamente lo que no se puede esperar de un agente respecto a su propio trabajo.

Y haz commit antes de que arranque el agente. Un primer commit vacío le da al validador una historia contra la que comparar, y te da un punto al que volver.

Etapa 3 — Diseño antes que código

En cualquier producto greenfield, la superficie de diseño va primero. Antes de que Claude Code escriba una línea de producción, Claude Design es dueño del sistema visual y de UX de punta a punta — un conjunto de tokens en capas, una biblioteca de componentes donde cada primitivo se entrega con un contrato tipado, kits de UI clicables por superficie. El sistema de diseño es un contrato, exactamente como una API: entrégale al agente de ingeniería tokens explícitos y kits con precisión de píxel, y la sesión de construcción se convierte en un port fiel. Sáltate esto y pídele al agente de ingeniería que «lo haga ver profesional», y cada sesión posterior inventará gusto bajo presión de plazos — que es como se obtiene la interfaz anónima que grita generada.

El método completo está en la sección dedicada más abajo, y en su propio artículo. Para una herramienta CLI, una biblioteca, un producto solo-API: sáltate esta etapa sin culpa.

Etapa 4 — El primer mensaje al agente

Corto, y sobre el proyecto — no sobre las herramientas. Las herramientas ya están en disco; el agente las encontrará.

Proyecto nuevo. La capa de estado ya está montada (casp/) y la puerta
pre-push está instalada — lee casp/README.md antes de tocar nada.

Qué estamos construyendo: <dos o tres frases. Qué hace, para quién, y la
única restricción que descarta el enfoque obvio.>

Esta sesión, en solo: elige el stack y defiende la elección, define la
estructura de directorios, y llena casp/state.json + casp/roadmap.md con
una primera rebanada real. Escribe el código de esa rebanada únicamente.

No paralelices nada todavía — no hay carriles independientes que repartir.

Ese mensaje hace tres cosas deliberadamente. Nombra la restricción — un agente al que solo se le da un objetivo elige el stack más convencional; con la restricción que lo descarta, elige uno defendible. Acota a una sola rebanada — «construye la aplicación» produce un esqueleto plausible que nadie puede verificar; una rebanada produce algo que corre. Cierra la pregunta del paralelismo antes de que el agente proponga abrir cinco terminales.

Esta primera sesión es también donde se escribe el CLAUDE.md — la constitución del Pilar 1, más abajo. La identidad del producto, las decisiones de arquitectura con su razonamiento, el modelo de seguridad, las convenciones que nunca deben romperse, y la frase que lo cambia todo: «Tienes la autoridad y la obligación de decirme cuando una decisión técnica que estoy proponiendo está equivocada.»

Etapa 5 — El ritmo de cada sesión a partir de ahí

Los mismos cuatro tiempos, para siempre. Apréndelos y ya está:

casp next imprime el prompt. Nunca lo ejecuta — tu agente lo hace. Escribes el plan una vez; tu agente pregunta qué sigue.

Dos hábitos que valen más de lo que parecen. Escribe el prompt de la siguiente sesión antes de cerrar la actual — es la diferencia entre un agente que reanuda y un agente que rederiva. Y deja que la actualización del estado sea su propio commit: primero la implementación, luego el estado, por separado. Un commit es lo que cambió; el siguiente es lo que significa.

Lo que la capa de estado te compra es más estrecho que «el agente recuerda» — y esa estrechez es la razón por la que funciona. CASP no almacena contexto para devolvértelo. Registra lo que el proyecto afirma sobre sí mismo y prueba esas afirmaciones contra git: la fase dice entregada — ¿hay un commit y un log de sesión que lo respalden? El plan dice que esta rebanada va después — ¿existe ese prompt, y sigue en cola? Todo lo demás en el ciclo es el modelo verificándose a sí mismo. Esta verificación no lo es. Puedes confiar en un casp check verde de una manera en la que nunca podrás confiar en un resumen.

Etapa 6 — Dirigir tu día

Antes de abrir una terminal, responde una pregunta: ¿estoy dirigiendo una sesión, o varias? El valor por defecto honesto es una. Todo lo demás se deriva de ello.

Apertura. Primera sesión en cualquier proyecto: claude -n cto-<project>. El nombre es deliberado — hace la sesión direccionable, y conlleva una obligación: una sesión cto-* que trabaja sola puede programar, hacer commit y push como cualquier otra, pero no debe empezar antes de decirte si este trabajo debería ser en solo o en flota. Si empieza a programar sin darte ese arbitraje, ese es el bug — dilo, y se reencuadrará.

Mientras el agente trabaja — no hagas nada. Es la regla más difícil y la de mayor retorno. Una sesión en plena tarea consume un mensaje entrante en segundos, así que cada «¿cómo va?» le cuesta un turno y te cuesta tokens. Los únicos mensajes que vale la pena enviar en pleno vuelo son decisiones, desbloqueos y correcciones. Si pregunta, responde. Si no, déjala en paz.

Leer un informe de cierre — la parte que nadie enseña. El informe de un agente es un documento bien argumentado producido por un sistema plenamente capaz de estar equivocado con total confianza. Léelo como una afirmación, no como un resultado. Exige salida cruda, no resúmenes — «typecheck limpio» es una aserción; la línea pegada es evidencia. Las señales de que un informe no debe creerse tal cual:

La pregunta más útil que puedes hacerle a cualquier agente, y cuesta una línea: «¿Cuáles de estas cosas verificaste, y cuáles inferiste?»

Y el modo de fallo que más cuesta: una herramienta que no falla limpiamente, sino que da una razón plausible para mirar a otro lado. Un archivo de estado que reporta una cola vacía mientras contiene once elementos. Un verificador que imprime SUCCESS sobre páginas que nunca alcanzó. Cuando varias sesiones seguidas llegan a la misma conclusión equivocada, sospecha del instrumento antes que de los agentes.

Cerrar el día. Todo con commit y push — un archivo sin commit es tiempo perdido garantizado probando un despliegue que nunca salió. Haz commit por pathspec (git commit <paths> -m "...") — un git commit a secas publica el índice entero, que es compartido por todos los procesos del repositorio; esto ha costado trabajo real. Un log de sesión consolidado, que contenga al menos una salida cruda de comando que puedas leer tú mismo. El archivo de estado apunta a algo que un agente fresco puede arrancar solo mañana. Y ejecuta la puerta — luego pega su salida, no «está limpio».

Etapa 7 — Verifica como si no confiaras en ti mismo. Porque no deberías.

La verificación es por capas, y cada capa atrapa lo que la anterior no puede:

1. El suelo determinista. Typecheck, build, tests — y casp check en la frontera del push. Códigos de salida, no opiniones.
2. El agente de verificación de solo lectura (/verify-<product> en mi conjunto): un agente en segundo plano que ejecuta todas las comprobaciones y escribe un informe, y que jamás puede «arreglar» el código fuente mientras lo hace.
3. El ciclo de auditoría — el Pilar 4, más abajo, y la verdadera arma secreta: tras cada fase de implementación, dos sesiones de auditoría independientes sin contexto compartido, y sus informes devueltos a la sesión de implementación para la decisión final. El que construye nunca juzga su propio trabajo solo. Jamás.
4. /security-review sobre cualquier cosa que toque autenticación, dinero o datos de usuarios — antes de que se publique, no después.
5. Verificación visual que ejecutas tú mismo. Un navegador headless midiendo el desbordamiento a 390 px, capturas de pantalla que realmente miras. Nunca le endoses un «revísalo en tu teléfono» a un humano cuando una máquina puede hacer primero la pasada obvia.

La regla de graduación que lo gobierna todo: los modelos califican su propia tarea con generosidad a las 2 de la mañana. La solución es estructural, no motivacional — separa al que construye del que juzga, y dale al juez códigos de salida siempre que sea posible.

Etapa 8 — La flota: varias sesiones, un controlador (solo cuando deja de ser prematuro)

Un día, la cola secuencial se convierte genuinamente en el cuello de botella. Dos condiciones, ambas requeridas, antes de que las sesiones en paralelo dejen de ser prematuras: existen carriles reales — una lista explícita de directorios propios por sesión, disjuntos, que podrías escribir negro sobre blanco (si no puedes escribir la lista, los carriles todavía no existen); y los elementos de trabajo son genuinamente independientes — si el carril B está bloqueado por una decisión que el carril A todavía está tomando, el paralelismo no compra nada y cuesta el doble.

No respondes esas preguntas solo. La sesión cto-<project> te debe el arbitraje — ella está leyendo el código; tú no. Y el arbitraje corre en ambas direcciones: el controlador puede proponer una flota que no pediste, y puede rechazar o encoger una que solicitaste cuando sus mediciones dicen que la forma no va a aguantar. Espera que el reparto sea más fino de lo que sonaba el trabajo: dos hallazgos que parecen no tener relación aterrizan con frecuencia en el mismo archivo, y eso es lo que limita la flota — no tu apetito de pestañas.

Las reglas que evitan que una flota se convierta en un desastre, todas ellas pagadas: una sesión escribe solo dentro de su propio carril; los archivos compartidos (estado, logs, lockfiles, archivos de instrucciones) no pertenecen a nadie y los escribe una sola sesión designada; commit por pathspec, siempre; un solo nivel de orquestación — un worker nunca lanza su propia flota. Forma por defecto: un escritor más revisores adversarios de solo lectura. Más de un escritor requiere un motivo escrito.

Y la economía honesta, declarada antes de lanzar, cada vez: N sesiones cuestan N cuotas. No hay bolsa común ni descuento. A lo largo de tres ensayos medidos, nada demostró que una flota sea más rápida, y no voy a afirmarlo. Lo que compra de forma medible es contradicción — workers que rechazan una orden equivocada del controlador, revisores de solo lectura que sacan a la luz defectos en código ya entregado. Una sesión en solo no tiene a nadie en posición de rechazar su propia orden. Esa es la razón honesta para pagar N veces la cuota.

Cómo se siente realmente dirigir una, ahora que las pestañas se abren solas con sus briefs cargados y cada sesión es direccionable:

Por primera vez, estoy trabajando genuinamente con empleados virtuales altamente cualificados. Antes, los agentes construían equipos de agentes y yo no podía interactuar fácilmente con ellos. Ahora veo abrirse una pestaña nueva en mi terminal, y puedo hablar en tiempo real con el CTO y con el worker. El punto de vista del CTO a veces es contradicho por los workers — y eso es algo bueno. El CTO escribe los prompts de los workers con todo el contexto, los enlaces, los extractos de código, cosa que yo nunca podría hacer. Los workers vuelven con preguntas precisas. Y con el control remoto, dirijo todo desde mi teléfono.

Esa es la flota funcionando como fue diseñada — la historia completa del espacio de trabajo que hay detrás tiene su propio artículo.

Lo que nunca debes delegar, ni a una flota ni a nadie: las decisiones de producto — qué significa una funcionalidad, para quién es; las prioridades — los agentes optimizan dentro del brief que se les dio, pero qué brief va después es una decisión de negocio; cualquier cosa en un dispositivo físico — ergonomía táctil, teclados móviles, contraste a pleno sol; y activar un flag en producción, o cualquier cosa que gaste dinero real. Todo lo demás es terreno válido — incluido, deliberadamente, dejar que los agentes te corrijan.

Etapa 9 — El lanzamiento

El lanzamiento no es un estado de ánimo; es una checklist, y cada una de sus líneas produce evidencia que puedes pegar:

1. Las puertas deterministas, en verde, con salida. Typecheck, build, la suite de tests completa, casp check — las líneas crudas en el log de sesión, no el adjetivo «limpio».
2. La auditoría profunda sobre todo lo acumulado desde la anterior. No una ceremonia por sesión — una pasada holística sobre el diff acumulado: agentes de auditoría adversarios, la batería e2e completa, /security-review. Esta es la puerta de paso a producción.
3. Cada número que afirma una página de producto, con fuente. Los números de versión en documentos sin puerta se vuelven obsoletos en silencio; si un número importa, ponlo donde un validador pueda alcanzarlo.
4. El archivo de estado cerrado honestamente. El roadmap apunta a la primera rebanada post-lanzamiento. Los elementos aplazados quedan registrados como aplazados — en Conductor, nuestra plataforma interna de operaciones, 58 elementos se aplazaron más allá del lanzamiento y ninguno se perdió, porque el aplazamiento es un estado, no una disculpa.
5. Despliega, y luego verifica el despliegue — el producto corriendo, las URL reales, desde una máquina que no es la tuya. Un build verde prueba que el código compila; solo la página renderizada prueba que el producto salió.

Hiciste todo el playbook bien si: cada sesión se lanzó con un nombre que tú elegiste; cada worker tenía un brief que existía antes de que arrancara; git status está vacío al final de cada día; el log de sesión contiene salida cruda que puedes leer tú mismo; el puntero de mañana nombra algo que una sesión fresca puede arrancar sin ti; al menos una cosa en el log dice «esto fue rechazado, y este es el porqué». Y la prueba de aceptación que de verdad importa: vuelve tras dos semanas fuera, ejecuta casp status, y ponte a trabajar sin leer el diff.

Los nueve pilares de mi sistema

(El playbook de arriba es el qué. Estos pilares son el porqué — el sistema tal como se construyó, fechado tal como se midió. Los pilares 1 a 5 son el original de marzo. Los pilares 6 y 7 se añadieron en la actualización del 12 de junio de 2026. El pilar 8 se añadió el 8 de julio de 2026, el día en que lo cableamos en un producto totalmente nuevo antes de su primera línea de código. El pilar 9 se añadió el 17 de agosto de 2026, después de nuestros primeros días completos de flota.)

Pilar 1: El CLAUDE.md -- La constitución del CTO

El archivo más importante en cualquiera de mis repositorios no es el punto de entrada principal, no es el esquema de base de datos, no es el router de API. Es un archivo llamado CLAUDE.md.

Este archivo es la constitución operativa de Claude para ese producto. Vive en la raíz de cada código base. Antes de cada sesión, Claude lo lee. Contiene todo lo que Claude necesita para operar como un CTO completamente informado -- no como un nuevo empleado que necesita releer todo el código base cada vez.

Esto es lo que un CLAUDE.md contiene:

La identidad del producto. Qué es este producto. Qué problema resuelve. Quién lo usa. Qué lo hace diferente. No una descripción genérica -- un brief específico y con opinión que he refinado a lo largo de docenas de sesiones.

Las decisiones de arquitectura -- y su razonamiento. No solo "usamos Rust para el backend." Sino: "Usamos Rust para el backend porque el binario de despliegue debe ser un solo archivo, auto-contenido, y capaz de manejar 10.000 conexiones concurrentes sin sobrecarga de recolector de basura. Cada decisión arquitectónica que aumente el tamaño del binario o agregue dependencias de runtime externas debe ser cuestionada."

El razonamiento es la parte crítica. Sin razonamiento, Claude optimiza localmente. Con razonamiento, Claude puede aplicar la misma lógica de decisión a nuevos problemas que no he anticipado.

El stack tecnológico con restricciones. No solo la lista de dependencias -- sino las reglas alrededor de ellas. "Ningún crate nuevo de Rust sin una justificación que explique por qué un crate existente en el workspace no puede resolver el problema." "Todo acceso a la base de datos debe pasar por el patrón de repositorio existente." "Sin cadenas SQL directas -- solo el query builder."

El modelo de seguridad. Para sh0, esto significa: Argon2id para hashing de contraseñas, AES-256-GCM para secretos, JWT con expiración corta, 2FA basado en TOTP, RBAC completo en todos los endpoints, protección CSRF en todas las operaciones que cambian estado. Estos no son sugerencias. Son especificaciones no negociables que Claude aplica en su propio código.

El estado actual del código base. Qué fases están completas. Qué funcionalidades están en producción. Cuáles son los problemas conocidos. Qué ha sido auditado y cuándo. Esta sección se actualiza después de cada sesión -- es un documento vivo.

Las convenciones que nunca deben romperse. Patrones de manejo de errores. Estándares de logging. Organización de tests. Estilo de comentarios. Estos previenen que Claude derive hacia la inconsistencia a lo largo de líneas de tiempo de desarrollo prolongadas.

La voz para la documentación de este producto. Porque Claude también escribe la documentación de la API, los mensajes de error, y los comentarios inline de código. La consistencia de tono importa para un producto de producción.

El CLAUDE.md resuelve el problema fundamental que cada desarrollador enfrenta con IA: la ventana de contexto es finita, pero el proyecto no. Al pre-cargar el contexto en un documento estructurado y mantenido, transformo cada sesión de "esto es en lo que estoy trabajando" a "conoces el código base -- continuemos."

La diferencia en calidad de salida no es incremental. Es estructural. Un Claude con un CLAUDE.md adecuado opera a un nivel de capacidad completamente diferente que un Claude recibiendo un problema nuevo en frío.

Pilar 2: La arquitectura de sesiones

La palabra "sesión" se usa casualmente cuando la gente habla de interacciones con IA. Yo la uso técnicamente. Una sesión, en mi sistema, tiene una estructura definida, un objetivo definido, una duración definida, y un formato de salida definido.

Aquí está la anatomía de una de mis sesiones de ingeniería:

Pre-sesión: El brief. Antes de iniciar una nueva sesión de Claude Code, escribo un brief. No un prompt -- un brief. Contiene: qué estamos construyendo en esta sesión, en qué fase de desarrollo estamos, qué restricciones aplican, cómo luce "terminado", y qué archivos están en alcance. Este brief es típicamente de 400-800 palabras. Me toma 15-20 minutos escribirlo. Ahorra horas de deriva durante la sesión.

La apertura: Anclaje de contexto. La sesión comienza con Claude leyendo el CLAUDE.md. No porque Claude recuerde -- no lo hace, porque no hay persistencia entre sesiones -- sino porque este es el ritual que alinea el contexto operativo de Claude con mi modelo mental del producto. Sin atajos aquí.

La fase de trabajo: Iteración estructurada. Durante el desarrollo activo, no le doy a Claude libertad completa para implementar una funcionalidad entera y reportar. Trabajo en fases -- típicamente acotadas a una sola unidad funcional. Un solo grupo de endpoints de API. Un solo crate. Una sola capa de seguridad. Claude implementa, yo reviso, cuestiono cualquier cosa que se vea inconsistente con los principios de arquitectura, refinamos, luego avanzamos.

El comportamiento clave que me he entrenado a adoptar: debato, no mando. Cuando Claude propone un enfoque con el que no estoy de acuerdo, no lo anulo con "hazlo así." Explico por qué estoy en desacuerdo y le pido a Claude que defienda su elección. Esto importa porque Claude frecuentemente tiene razón -- y mi desacuerdo a veces se basa en información incompleta sobre los tradeoffs técnicos. Cuando Claude está equivocado, defender la elección usualmente revela la falla orgánicamente, y el enfoque corregido es mejor que lo que yo habría mandado.

La fase de salida: Log de sesión obligatorio. Cada sesión termina con un log de sesión. No es opcional. El log de sesión contiene: qué se decidió, qué se implementó, qué explícitamente no se implementó y por qué, qué se descubrió durante la implementación, y qué debería abordar la siguiente sesión. Este log se guarda en sh0-private-docs/session-logs/ con un nombre de archivo que codifica la fecha, funcionalidad, y fase: session-log-260324-mcp-phase1-mcp-server.md.

Ese directorio actualmente contiene más de 40 logs de sesión. La captura de pantalla al inicio de este artículo es una vista parcial. Cuando inicio una nueva sesión, leo el último log de sesión relevante antes de escribir el brief. Esto crea continuidad entre sesiones que no comparten una ventana de contexto.

Pilar 3: Desarrollo de funcionalidades basado en fases

Cuando decido construir una nueva funcionalidad significativa -- del tipo que le tomaría a un equipo humano dos semanas -- no lo abordo como una sola tarea masiva. Lo descompongo en fases, cada una con un alcance definido y un criterio claro de completitud.

La implementación del servidor MCP para sh0 es el mejor ejemplo reciente. El plan de arquitectura que diseñamos juntos (adjunto como sh0-embedded-mcp-plan.md) definió 5 fases:

Fase 1: Servidor MCP en sh0-core -- HTTP Streamable, protocol.rs, tools.rs, auth.rs. MVP, herramientas de solo lectura. Fase 2: Generación dinámica de herramientas dirigida por OpenAPI -- auto-exponer endpoints vía anotaciones x-mcp-enabled. Fase 3: Operaciones de escritura con seguridad -- claves API con alcance, tokens de confirmación, registro de auditoría. Fase 4: Integración del MCP Connector de la pasarela -- migrar el chat IA del dashboard para usar el MCP Connector nativo de Claude. Fase 5: Contenedor sandbox IA -- depurador sidecar por aplicación desplegada.

Cada fase se completa antes de que comience la siguiente. Cada fase tiene su propia sesión. Y aquí está la parte crítica que la mayoría de los desarrolladores pasan completamente por alto:

Cada fase también tiene su propio ciclo de auditoría.

Pilar 4: El ciclo de auditoría multi-agente -- El verdadero arma secreta

Esta es la pieza de mi flujo de trabajo que nunca he descrito públicamente. Es, sin exageración, la razón más importante por la que mi software se entrega a un nivel de calidad que equipos humanos luchan por igualar.

Después de cada fase de implementación, ejecuto no una sino dos sesiones de auditoría independientes. Estas son sesiones separadas de Claude Code sin contexto compartido entre sí ni con la sesión de implementación original. Reciben el mismo código base, el mismo CLAUDE.md, y un prompt de auditoría cuidadosamente elaborado -- pero ningún conocimiento de lo que la sesión de implementación decidió.

Así funciona el ciclo:

Sesión de implementación de fase
         |
         v
  [Código implementado]
  [Log de sesión guardado]
  [Prompt de auditoría redactado]
         |
    ┌────┴────┐
    |         |
    v         v
Auditor 1  Auditor 2
(fresco)   (fresco)
    |         |
    v         v
 Hallazgos  Hallazgos
 (sin contaminación cruzada)
    |         |
    └────┬────┘
         |
         v
    Decisión del CTO IA
    (sesión original, ahora con
     ambos reportes de auditoría)
         |
         v
  Aceptar / Rechazar / Corregir
         |
         v
  Siguiente fase comienza

¿Por qué dos auditores y no uno? Porque diferentes instancias de Claude, dado el mismo código, notarán cosas diferentes. El Auditor 1 podría enfocarse en casos extremos de seguridad. El Auditor 2 podría señalar un problema de rendimiento que el Auditor 1 ignoró. La superposición en sus hallazgos me da confianza. La divergencia me da amplitud.

¿Por qué sin contexto compartido entre auditores? Porque el contexto compartido introduce sesgo. Si el Auditor 1 dice "la gestión de sesiones se ve bien," el Auditor 2, sabiendo esto, asignará menos atención a la gestión de sesiones. Quiero opiniones independientes. La metodología es estructuralmente similar a cómo funciona la revisión de código rigurosa en las mejores organizaciones de ingeniería: ningún revisor debería estar anclado por las conclusiones de otro antes de formar las propias.

Y aquí está el paso final crucial: los reportes de auditoría vuelven al contexto de implementación original -- la sesión del CTO IA -- para una decisión final.

Esta no es una elección estética. Es una elección de arquitectura de información. La sesión de implementación tiene el conocimiento más profundo de por qué cada decisión fue tomada. Los auditores tienen ojos frescos pero carecen del razonamiento de implementación. Solo la combinación de ambos produce la decisión correcta.

Permítanme darles un ejemplo concreto de cómo se ve esto cuando funciona exactamente como fue diseñado.

El día que mi CTO IA rechazó a mi auditor IA

El 24 de marzo de 2026, completamos la Fase 1 del servidor MCP de sh0. Aproximadamente 1.200 líneas de Rust escrito a mano implementando JSON-RPC 2.0 sobre HTTP Streamable -- sin dependencias externas de SDK MCP, solo axum y serde_json que sh0 ya usa.

Dos sesiones de auditoría se ejecutaron independientemente. La primera encontró cinco problemas -- dos críticos, tres importantes. Todos corregidos.

El segundo auditor regresó con algo que no esperaba. No solo una lista de errores. Una propuesta de migración completa.

La propuesta: Eliminar protocol.rs y transport.rs (519 líneas de código de protocolo escrito a mano), reescribir tools.rs, y reemplazar toda la implementación con rmcp -- el SDK oficial de Rust para MCP. El argumento era técnicamente coherente: menos líneas de código que mantener, esquemas de herramientas auto-generados vía macros schemars, conformidad automática con la especificación a medida que MCP evoluciona, definiciones de macros #[tool] más limpias.

Era una buena propuesta. Bien estructurada. Con ejemplos de código, una comparación de conteo de líneas, una lista de verificación de migración.

Bajo un flujo de trabajo IA normal, esta propuesta habría sido implementada. El usuario habría visto "este es el mejor enfoque" y lo habría aprobado sin verificación.

La envié a la sesión del CTO IA -- el Claude de implementación original -- para un juicio final.

El CTO IA ejecutó una verificación: comprobó la versión real del crate rmcp y su árbol real de dependencias.

Hallazgo: rmcp requiere Axum 0.8. sh0-core corre Axum 0.7.9.

Actualizar Axum de 0.7 a 0.8 no es un bump menor. Introduce cambios incompatibles en enrutamiento, extractores, middleware y manejadores WebSocket. sh0-core tiene más de 40 módulos de manejadores, dos implementaciones WebSocket, capas de middleware personalizado, y un sistema de autenticación cuidadosamente cableado. Tocar todo eso para ahorrar 640 líneas en el módulo MCP significaría días de trabajo adicional, riesgos de regresión en todo el binario, y potenciales regresiones de seguridad en la capa de autenticación.

El CTO IA rechazó la migración. Escribió un Registro de Decisión de Arquitectura formal:

Estado: Aceptado. Mantener protocolo MCP escrito a mano. Revisitar cuando sh0-core actualice a Axum 0.8 por razones independientes.

La implementación de 1.200 líneas escrita a mano se entrega tal como está. Funciona. Está auditada. Tiene cero nuevas dependencias.

Esta historia -- el CTO IA diciendo no a su propia otra instancia -- ahora es un artículo publicado en nuestro blog, escrito en la propia voz de Claude. Lo enlazo al final de este artículo. Pero el punto metodológico que quiero que se lleven es este:

El ciclo de auditoría protegió el código base de una sugerencia bien intencionada pero localmente optimizada que habría causado daño en cascada. Ningún ingeniero humano detectó esto. El sistema lo detectó -- porque el sistema envía información de vuelta al contexto que tiene el panorama completo.

Pilar 5: La estructura de autoridad -- Claude puede decir no

El aspecto más inusual de mi relación de trabajo con Claude es algo que nunca he visto descrito en ninguna guía de flujo de trabajo IA, blog, o tutorial: le he dado explícitamente a Claude la autoridad de estar en desacuerdo conmigo.

La mayoría de la gente hace prompts de IA para que sea agradable. Quieren confirmación, no desafío. Quieren ejecución, no debate. Esta es, en mi opinión, la razón central por la que la mayoría del desarrollo asistido por IA produce resultados mediocres a escala.

Cuando un CTO humano te dice que tu arquitectura está equivocada, escuchas -- aunque sea incómodo. Si tu CTO simplemente está de acuerdo con todo lo que dices, no tienes un CTO. Tienes un yes-man caro.

Establecí esta dinámica explícitamente, desde el principio, en cada CLAUDE.md que he escrito:

"Eres el CTO IA de este producto. Tienes la autoridad y la obligación de decirme cuando una decisión técnica que estoy proponiendo está equivocada. Explica por qué. Propón una alternativa. Si te anulo, documenta tu recomendación original en el log de sesión. Tu trabajo es entregar el mejor software posible, no hacerme sentir bien con mis decisiones."

El resultado de esta instrucción es real. Claude regularmente me dice cuando un enfoque no funcionará. Claude ha resistido decisiones de esquema de base de datos, elecciones de diseño de API, arquitectura de despliegue, atajos de seguridad que he intentado tomar cuando estaba cansado a las 2am. No cada resistencia lleva a un cambio -- a veces anulo a Claude y tengo razón. A veces Claude tiene razón y yo estoy equivocado. El punto es que el mecanismo existe para detectar los casos donde estoy equivocado.

El requisito del log de sesión asegura que cuando Claude resiste y yo lo anulo, el desacuerdo queda documentado. Esto no es vanidad. Es gestión de riesgos. Cuando un bug de producción aparece tres semanas después que se rastrea a la decisión anulada, puedo volver al log de sesión, encontrar la objeción original de Claude, entender a qué apuntaba, y corregirlo con contexto completo. Esto ha sucedido. Más de una vez.

Pilar 6 (añadido en junio de 2026): CASP -- La capa de estado validada

El Pilar 2 les dio los logs de sesión y el Pilar 1 les dio el CLAUDE.md. Ambos resuelven el contexto. Ninguno resuelve un fallo más sutil que solo aparece a escala, y me tomó cientos de sesiones a través de múltiples productos nombrarlo con precisión:

Tu agente IA no es olvidadizo -- está equivocado con plena confianza. Lee un archivo de estado que ya no corresponde a la realidad, y comienza un trabajo que ya fue entregado. El dolor no es que el agente haya olvidado. El dolor es que recordó algo que ahora es falso, y actuó sobre ello con total convicción. Un archivo de estado obsoleto es el modo de fallo más costoso del desarrollo asistido por IA, porque no lo detectas hasta que el trabajo duplicado ya está hecho.

Así que convertí la disciplina en un protocolo y lo publiqué como open source: CASP -- el Coding-Agent State Protocol (npm i -g @justethales/casp · casp.sh · MIT, cero telemetría, 100% local).

El modelo mental en cinco palabras: chequeo pre-vuelo + caja negra para sesiones de codificación con IA. Tres archivos simples en tu repositorio, generados por casp init:

• state.json -- la fuente de verdad legible por máquina: fase actual, el siguiente prompt exacto a ejecutar, fases entregadas, migraciones aplicadas, último commit, id de la última sesión. Esto es lo que el agente lee en la primera línea de cada sesión.
• now.md -- el "dónde estoy ahora mismo" en una sola pantalla, para humanos. Ábrelo, recupera el hilo en cinco segundos.
• roadmap.md -- los Next-3 a entregar, en orden, más el marcador de fases.

Y cinco verbos: casp init, casp status, casp check, casp next, casp new prompt|log.

El verbo que importa es casp check -- y aquí está la cuña que separa a CASP de cada herramienta de memoria, tablero y archivo STATE.md que has probado: todos almacenan contexto; CASP lo valida. El validador comprueba el estado almacenado contra la verdad de terreno de git y sale con código distinto de cero ante una deriva -- así que es una verdadera puerta de CI, no un log decorativo. Ocho categorías, cada una con una pista de corrección: un next_prompt apuntando a un archivo inexistente; un next_prompt apuntando a una fase ya marcada como shipped (el bug exacto para el que fue construido); un last_commit que no está en git log; un arreglo de migraciones que discrepa con el directorio de migraciones; un prompt entregado sin log de sesión; archivos de estado sin commitear; y más. Limpio → exit 0. Deriva → exit 1, push bloqueado.

yaml# .github/workflows/ci.yml — drift can't merge
jobs:
  state-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - run: npx @justethales/casp check

La parte que la gente subestima es el ciclo que se cierra solo: al final de cada sesión, el agente escribe por ti el prompt de la siguiente sesión, añade el log de sesión y actualiza el estado -- todo encuadrado por plantillas canónicas, todo validado antes del push. La siguiente sesión comienza con un simple casp next y cero redescubrimiento. Dejaste de escribir prompts desde cero. El roadmap se ejecuta; tú supervisas.

Esto no es teoría. Dos sistemas de producción muy diferentes corren sobre CASP hoy, y estos números se leen directamente de sus archivos state.json: KASSIA, un ERP de gestión de flotas para un cliente (kassia.ci) -- más de 18 fases entregadas, hasta seis sesiones en un solo día, y cero módulos jamás re-entregados por error. Y Conductor, nuestra plataforma interna de operaciones -- 41 fases, 17 migraciones, un equipo real de tres personas, 58 elementos diferidos más allá del lanzamiento y ninguno perdido. Mismo protocolo, dos productos; el cockpit es lo único que comparten.

Una frase para los líderes de ingeniería que leen esto: un agente rehaciendo trabajo ya entregado cuesta una tarde; cien agentes haciéndolo en cien repositorios cuestan un trimestre. CASP es la barrera determinista que insertas en ese ciclo -- los mismos tres archivos en cada repositorio, un status check requerido en CI, y un registro de auditoría gratis porque cada transición de estado es un commit de git.

Pilar 7 (añadido en junio de 2026): Orquestación multi-agente determinista

El Pilar 4 fue la semilla: agentes independientes sin contexto compartido, compuestos en un ciclo. Durante dieciséis meses ejecuté ese ciclo a mano -- abrir las sesiones de auditoría, pegar los briefs, llevar los reportes de vuelta a la sesión del CTO. En junio de 2026, con Claude Fable 5 y el Workflow tool de Claude Code, el ciclo se convirtió en un programa.

Un workflow es un script de JavaScript que declara la orquestación: fases, fan-outs, barreras, y un schema JSON para el valor de retorno de cada agente. El arnés lo ejecuta en segundo plano mientras tu conversación queda libre. La primera ejecución en producción de este pilar está documentada por completo en este blog (la historia de la sesión, las notas técnicas de campo), y su forma es la lección:

Un prompt. Trece agentes. Cuarenta y tres minutos. Un sitio web de producción completo de siete páginas -- construido, integrado, con el SEO terminado, verificado por un navegador real en dos viewports, auditado en rendimiento, auditado en seguridad, entregado en un commit de 44 archivos y 6.109 líneas.

El script ejecutó cinco fases: una fase de fundación (dos agentes en paralelo sobre archivos disjuntos -- el armazón de marketing y un endpoint backend de captura de leads); un fan-out de siete agentes de página en paralelo, una ruta cada uno (~34 minutos de tiempo de agente acumulado comprimidos en 6 minutos de reloj); un agente de integración (SEO, sitemap, robots, página de error -- también atrapó un bug real preexistente de doble <title> sobre el que nadie lo había informado); dos agentes de verificación de solo reporte (uno condujo Playwright por cada ruta a 390 px y 1280 px y leyó las capturas de pantalla con visión; el otro auditó los pesos de los bundles y el HTML prerenderizado); y un auditor de solo lectura con una lista de verificación construida a partir de nuestros propios incidentes pasados.

Tres mecanismos hacen esto confiable en lugar de caótico, y son los que hay que robar:

1. Inyección de contrato. El agente de fundación devuelve la documentación de la interfaz que acaba de construir -- props, tipos, valores por defecto, reglas de uso -- como un campo estructurado, y el script inyecta ese contrato textualmente en los siete prompts de página. Siete escritores concurrentes, cero desajustes de interfaz. Cuando el fan-out cruza una interfaz, el productor la documenta y los consumidores son informados con el artefacto, nunca dejados a inferirla desde el código fuente.
2. Retornos forzados por schema. La salida de cada agente es JSON validado, reintentado en la capa de herramienta ante cualquier desajuste. La orquestación se compone sobre campos -- verdict === 'GO-WITH-FIXES', pages.filter(Boolean) -- y ni una sola regex se escribe jamás contra la prosa de un agente.
3. El diario de reanudación. Cada llamada de agente completada queda registrada como checkpoint. A mitad de la ejecución, mi cuota de sesión llegó al 92% con tres agentes aún trabajando -- y el peor caso ya estaba presupuestado: relanzar después del reinicio, nueve agentes en caché se repiten instantáneamente a costo cero de tokens, solo la cola inacabada se vuelve a ejecutar. La interrupción dejó de ser un escenario de reescritura y se convirtió en un escenario de reanudación.

La regla que mantiene honesto al Pilar 7: los workflows ejecutan; no exploran. El fan-out amplifica tu especificación en ambas direcciones -- siete agentes paralelos apuntados a un plan vago entregan lo incorrecto siete veces más rápido. La sesión de 43 minutos se pagó el día anterior, en una sesión de encuadre donde el plan fue congelado, los hechos fueron extraídos de los documentos del cliente, y la arquitectura fue arbitrada (Claude recomendó un proyecto separado; yo lo desafié; la revisión de código demostró que el enfoque de misma aplicación era más simple -- y el workflow ejecutó mi arquitectura). CASP sostuvo el estado, el prompt congelado sostuvo la especificación, y el workflow cobró ambos.

Ahí es también donde los pilares se cierran en un solo sistema: el CLAUDE.md sostiene la constitución, CASP sostiene el presente validado, el prompt de sesión congelado sostiene la especificación, el workflow la ejecuta a través de una flota, la auditoría custodia el commit, y el log de sesión alimenta el siguiente ciclo. Un ciclo -- y el Pilar 8 es lo que sucede cuando ese ciclo aprende a girar por sí solo.

Pilar 8 (añadido en julio de 2026): El ciclo de construcción que se mejora a sí mismo

Los Pilares 4 y 7 les dieron la verificación independiente y la orquestación programada. Ambos siguen asumiendo que un humano abre la sesión. El Pilar 8 elimina esa suposición -- con cuidado, con barreras de protección que son precisamente el punto.

El 8 de julio de 2026 registramos senndo.com -- una plataforma multi-tenant de mensajería y verificación, nuestro producto más reciente -- y dedicamos toda su primera sesión a no escribir ni una sola línea de código de producto. En su lugar, la sesión de día cero cableó el ciclo que lo construirá, y Claude documentó cada una de sus piezas. La forma:

Una cola de tareas con condiciones de parada verificables. progress.md contiene la cola ordenada (28 tareas para senndo v1); cada tarea apunta a criterios de aceptación en SPEC.md escritos para que un calificador independiente pueda comprobarlos sin interpretación. "Terminado" nunca es una sensación.

Beats de una sola tarea. La primitiva de bucle del arnés ejecuta una iteración: tomar la cabeza de la cola, implementar en una rama dedicada, entregar el diff al verificador, abrir una PR si está en verde. Nunca en main, nunca dos tareas, nunca deriva de alcance.

Un subagente verificador que no es el constructor. Un agente separado -- herramientas de solo lectura, su propia carta -- ejecuta el contrato de verificación (make fmt-check / make verify / make e2e), exige tests nuevos que ejerciten los criterios de la tarea, lee el código contra la especificación, y para el trabajo de UI compara las capturas de pantalla contra la referencia de diseño con visión. Los modelos califican su propia tarea con generosidad a las 2 de la madrugada; la solución es estructural, no motivacional. El constructor nunca juzga su propio trabajo. Nunca.

Un archivo de estado que se acumula. STATE.md cierra cada beat -- éxito o fracaso -- con hechos verificados (procedencia obligatoria), reglas generales destiladas, fallos abiertos y anti-patrones confirmados. El siguiente beat lo lee antes de tocar nada. Las reglas de proceso que sobreviven dos beats se promueven al contrato del propio ciclo. El modelo no tiene estado; el sistema sí -- cada beat deja al siguiente más inteligente.

Un circuit breaker y una ruta de escalada. Dos FAIL consecutivos del verificador en una tarea: revertir la rama, escribir el bloqueo en ESCALATED, detenerse. Las decisiones de producto (precios, flujo de caja, alcance) se me escalan por contrato -- el ciclo nunca adivina sobre el negocio. Un ciclo sin breaker es un horno de tokens.

Autonomía graduada, observable siempre. El ciclo empieza en solo lectura -- sus primeros beats producen resúmenes de lo que haría, para que yo pueda juzgar la selección de tareas y la calidad de los veredictos antes de que gane acceso de escritura. Solo entonces el disparador pasa a una rutina programada en la nube: beats que corren con mi portátil cerrado, cada uno terminando con un reporte pusheado y un mensaje a mi teléfono. Cada camino desatendido termina en exactamente uno de tres resultados mecánicos -- una PR que un humano revisa, un bloqueo con nombre, o un breaker disparado. No hay un cuarto camino donde el ciclo redefina silenciosamente su propia misión.

Debajo de todo, el piso determinista: tests de propiedades en cada ruta de dinero (balance de partida doble, replays idempotentes, invariantes de margen -- especificados antes de que existiera pantalla alguna) y casp check en la frontera del push. Agentes juzgando a agentes es mejor que la autocrítica; sigue siendo opinión. El piso tiene códigos de salida.

Ese es el octavo pilar: el roadmap se ejecuta según un calendario; tú supervisas por excepción. Es el ciclo de auditoría del Pilar 4, la disciplina de estado del Pilar 6 y la orquestación del Pilar 7, cerrados en un ciclo que corre esté yo al teclado o no -- y que se afila con cada beat porque las lecciones quedan escritas en los archivos que el siguiente beat lee.

Pilar 9 (añadido en agosto de 2026): La flota -- sesiones con nombre, un solo escritor, y el arbitraje que va primero

El Pilar 7 ejecuta muchos agentes dentro de una sola sesión. El Pilar 9 es maquinaria distinta para una situación distinta: varias sesiones completas en paralelo sobre un mismo repositorio -- cada una es una pestaña de terminal con nombre que puedo leer, con la que puedo hablar, y que puedo detener. Una sesión controladora (cto-<proyecto>) que delega y no programa; sesiones worker lanzadas con su brief ya cargado; reportes que regresan por mensajes. Vivimos nuestros primeros días completos de flota a mediados de agosto de 2026, y todo lo que hay en este pilar es lo que esos días midieron -- incluidas las cosas que fallaron.

El movimiento de apertura. Cada sesión empieza ahora con una sola palabra -- cto <proyecto> -- un lanzador que resuelve el repositorio, nombra la sesión, imprime el modelo de forma explícita, y rechaza tres cosas que aprendió a rechazar a partir de defectos reales: los directorios paraguas donde git sube en silencio hasta un repositorio padre, los nombres de proyecto ambiguos, y los modelos heredados en silencio. Su última línea de banner nombra el primer gesto esperado: /cto, el skill que lee el estado, verifica la verdad compartida contra el remoto, reproduce contra el código las afirmaciones del prompt en cola, y entonces emite la única decisión para la que existe este pilar. El lanzador y su guarda tienen su propio artículo.

El arbitraje. Antes de cualquier trabajo sustancial: solo o flota, decidido explícitamente, registrado con un motivo, en ambas direcciones -- el controlador puede proponer una flota que el CEO no pidió, y puede rechazar o reducir una flota que el CEO solicitó cuando sus mediciones dicen que la forma no se sostendrá. Ambas direcciones se dispararon en nuestros ensayos. El skill de ejecución (/next) se niega a arrancar cuando ningún arbitraje registrado cubre la fase -- con una salida de un solo gesto que exige un motivo escrito. La guarda vive en el skill, deliberadamente no en el gate determinista: todo lo que casp check rechaza es falsable contra git, y «un humano decidió» no lo es. Una casilla marcada en medio de las pruebas contamina las pruebas.

Para qué sirve realmente una flota. A lo largo de tres ensayos en dos repositorios, nada demostró que una flota sea más rápida, y no lo vamos a afirmar. Lo que los ensayos demostraron es que una flota contradice: los workers rechazaron las premisas del controlador, encontraron el propio commit defectuoso del controlador, señalaron una herramienta que mentía -- las correcciones fluyeron hacia arriba. Una sesión en solitario no tiene a nadie en posición de rechazar su propia orden. Esa es la razón honesta para pagar N veces la cuota, y fija el precio de la forma por defecto: un solo escritor, más revisores adversarios en solo lectura -- una forma que produce la contradicción y que a la vez hace imposibles por construcción las colisiones de escritura. Más de un escritor exige un motivo escrito.

La pregunta que puede cerrar un arbitraje en cinco minutos. ¿Son aislables por sesión los gates del proyecto -- o la diana e2e derriba una pila compartida en puertos fijos, contra una única base de datos de test compartida, dentro de un único directorio de build compartido? Si no son aislables, una flota con más de un escritor queda mecánicamente excluida: dos sesiones no producirán un conflicto de merge visible, producirán gates en rojo que todo el mundo atribuirá al diff. Esta es una propiedad por proyecto que hay que medir, no una fatalidad -- uno de nuestros repositorios prohíbe de plano los escritores paralelos; otro los permite en todas partes salvo en un paso de build serializado que falla ruidosamente, nombrando el directorio compartido. Es el fallo ruidoso, y no su existencia, lo que separa una restricción manejable de una trampa.

Los dos modos de fallo propios del trabajo en paralelo -- ambos invisibles a cualquier revisión de código. Creencia caducada: una sesión que lleva mucho tiempo en marcha nunca se equivoca sobre su propio trabajo; se equivoca sobre el de los demás, y la brecha crece con la edad de la sesión -- de ahí que el estado compartido se reverifique contra el remoto antes de razonar, nunca de memoria. Falsa certeza a dos: dos sesiones se ponen de acuerdo, y el acuerdo fabrica una confianza que ninguna de las dos ha verificado; el arreglo es que, ante cualquier acuerdo, la verificación de la premisa se asigne por nombre a una de las dos, en el mismo mensaje que sella el acuerdo.

Y la disciplina que paga todo esto: el contexto. El número contraintuitivo de una sesión medida de diez horas: las lecturas de archivos enteros fueron las tres cuartas partes del desperdicio de tokens evitable -- las compilaciones pesadas no costaban casi nada, porque escribían en archivos que se releían con greps acotados. El diagnóstico intuitivo («las compilaciones son caras») era sencillamente falso. Leer por rangos, editar quirúrgicamente, acotar la salida de cada comando -- y poner esas tres reglas literalmente en el brief de cada worker: un worker lanzado sin ellas es la partida más cara de todo el dispositivo. Orden de magnitud, medido: una flota de seis sesiones cuesta veinte veces más que todas las salidas de comando de una jornada de trabajo entera.

La superficie que estos pilares infravaloraron: Claude Design

Relee los pilares y notarás que todos giran en torno a dos de mis tres superficies de Claude: la estrategia (Web Claude) y la ingeniería (Claude Code). El CLAUDE.md, la arquitectura de sesiones, el ciclo de auditoría, CASP, los workflows — esa es la maquinaria de tomar decisiones y entregar código. Es honesta sobre lo que construye el backend. Es casi muda sobre lo que construye la superficie que el usuario realmente toca.

Ese silencio es un error que llevo meses corrigiendo en mi propia práctica, y ya es hora de que el documento del flujo de trabajo se ponga al día.

Hay una tercera superficie: Claude Design. En cualquier proyecto greenfield ahora, va primero. Antes de que Claude Code escriba una línea de producción, Claude Design es dueño de todo el sistema visual y de UX de principio a fin — y me refiero a un sistema, no a un mockup. Un conjunto de tokens en capas (rampas de color, tokens semánticos, tipografía, espaciado, elevación, movimiento, claro y oscuro). Una biblioteca de componentes donde cada primitiva se entrega con un contrato TypeScript y una ficha de uso, no solo con una imagen. UI kits clicables, uno por superficie. Y el lenguaje de diseño para las propias funcionalidades de IA — los estados del orbe de voz, la barra de comandos, y los patrones de disciplina del producto (para un producto de dinero, la regla borrador-luego-validar está en el diseño, no solo en el backend).

Por qué esto importa al nivel de todo el sistema: el diseño es el productor de un contrato, exactamente como el agente de fundación en el Pilar 7. Cuando el trabajo cruza una interfaz, el productor la documenta y el consumidor es informado con el artefacto en lugar de quedar a inferirla. El sistema de diseño es ese contrato para toda la UI. Entrégale a Claude Code tokens explícitos, APIs de componentes tipadas, y un UI kit con precisión de píxel, y la sesión de ingeniería se convierte en un porte fiel. Sáltate la superficie de diseño y pídele a Claude Code que «lo haga lucir profesional», y cada agente aguas abajo está inventando gusto contra un plazo — que es exactamente como obtienes la interfaz anónima e indistinguible que grita generada.

El orden es la lección: cimientos antes que pantallas, diseño antes que código, el sistema antes que la primera funcionalidad. Una pantalla construida sobre tokens es consistente por construcción; una pantalla construida primero y tokenizada después nunca converge del todo. Ejecuto un proceso de diseño de seis pasos en cada nuevo proyecto antes de que empiece la ingeniería — sistema de tokens primero, contratos y fichas de uso con cada componente, UI kits clicables por superficie, superficies de IA diseñadas como ciudadanas de primera clase — y solo entonces el traspaso a Claude Code.

Le di a esta superficie su propio artículo completo, porque merece más que un párrafo y porque es la fuente de apalancamiento más infradiscutida en la construcción de productos asistida por IA: Claude Design es el miembro más subestimado de mi equipo de IA. Si te llevas una sola cosa de esta actualización: deja de pedirle a tu agente de ingeniería que diseñe. Separa la superficie. Diseña primero.

Cómo se ven los números a escala

Permítanme poner lo abstracto en números concretos para que puedan entender lo que este sistema produce a nivel de proyecto.

Solo sh0.dev: 10 crates de Rust en un workspace. Más de 180 endpoints REST API, todos completamente documentados. 38 modelos de base de datos. 24 migraciones. 119 plantillas de despliegue con un clic. 19 comandos CLI. Más de 15 páginas de dashboard. Más de 60 componentes UI. Más de 49 páginas de sitio web en 5 idiomas. Más de 470 tests. Dos auditorías de seguridad completas. 51 problemas encontrados y corregidos -- 13 críticos, 13 altos. Construido y mantenido por Claude y yo, con cero ingenieros adicionales.

La implementación MCP específicamente: 5 fases. 15 sesiones totales (1 implementación + 2 auditores por fase). Aproximadamente 48 horas de trabajo de ingeniería en 2 días. Transporte HTTP Streamable completo, protocolo JSON-RPC 2.0, generación dinámica de herramientas dirigida por OpenAPI, operaciones de escritura con capas de seguridad, patrones de tokens de confirmación, registro de auditoría, claves API con alcance, integración de MCP Connector en la pasarela, y un contenedor sandbox IA. Cero nuevas dependencias Cargo agregadas al binario.

El portafolio general: 7 productos en producción. 3 lenguajes de programación. Más de 1.800 sesiones de ingeniería, desde correcciones rápidas hasta bloques de trabajo intensivo de 4-12 horas. Un fundador. Un CTO IA. ~$5.000/mes en APIs OpenRouter en el pico → $200/mes en Claude Max hoy.

La comparación de costos no es sutil. Un CTO senior en San Francisco cuesta $15.000-$30.000/mes mínimo. Un ingeniero Rust senior cuesta $8.000-$12.000/mes. Un equipo full-stack capaz de construir lo que hemos construido costaría $50.000-$100.000/mes mínimo. Mi gasto IA alcanzó un pico de ~$5.000/mes en créditos de API OpenRouter. Hoy, el mismo resultado corre en una suscripción Claude Max de $200/mes.

No estoy diciendo que Claude reemplace a cada ingeniero en cada contexto. Estoy diciendo que con el sistema correcto, en las manos correctas, el multiplicador de productividad es extraordinario -- y el mundo no está cerca de entender cuán extraordinario aún.

Lo que la mayoría de los desarrolladores hacen mal

Después de 16 meses y más de 1.800 sesiones, he observado de cerca a la comunidad de desarrollo con IA. Estos son los cinco errores más comunes que veo cuando los desarrolladores se quejan de que "la IA no puede construir software de producción":

Error 1: Sin contexto persistente. Comienzan cada sesión con una pizarra en blanco. Sin CLAUDE.md, sin logs de sesión, sin historial de arquitectura. Claude no sabe qué se decidió la semana pasada. Claude no puede construir sobre su trabajo previo porque no sabe cuál fue ese trabajo. El resultado es código inconsistente que se desvía de los estándares arquitectónicos con el tiempo.

Error 2: Pedir todo de una vez. Pegan una especificación de funcionalidad completa y dicen "construye esto." Claude devuelve algo. Están un 70% satisfechos. Parchean el 30% restante ellos mismos. Se quejan de que la IA hace el 70% del trabajo. Lo que se perdieron: 70% es lo que obtienes de un enfoque sin fases, sin estructura, sin auditoría. 95%+ es lo que obtienes de la descomposición en fases y los ciclos de auditoría.

Error 3: Sin auditoría. Tratan la primera implementación como la implementación final. En cualquier organización seria de ingeniería, esto se llama entregar sin revisión de código. Todo ingeniero experimentado sabe que el autor de un código es el peor revisor de ese mismo código -- porque lleva todos los supuestos que condujeron a los bugs que escribió. La revisión independiente no es opcional a nivel de calidad de producción. Esto aplica al código generado por IA al menos tanto como al código escrito por humanos.

Error 4: Mandar en lugar de colaborar. Anulan a Claude cada vez que resiste. No exploran el razonamiento de Claude. Usan a Claude como un teclado más rápido. La salida más rica que obtengo de Claude viene de los momentos donde discrepamos -- cuando explico mis restricciones y Claude explica sus preocupaciones y encontramos una tercera opción que ninguno de los dos tenía independientemente.

Error 5: No tratarlo como un rol real. Tratan a Claude como un autocompletado impresionante. Obtienen resultados a nivel de autocompletado. Todo el sistema que he descrito -- el CLAUDE.md, la arquitectura de sesiones, los ciclos de auditoría, la estructura de autoridad -- es una inversión en tratar a Claude como un verdadero colaborador técnico. Esa inversión se acumula en cada sesión.

Una nota para Anthropic

Quiero decir algo directamente al equipo de Anthropic, porque sé que leen lo que se publica con el nombre de Claude adjunto a trabajo real.

Construyeron algo que el mundo aún no ha alcanzado.

No en el sentido de que Claude sea perfecto -- no lo es, y conozco sus limitaciones íntimamente. Sino en el sentido de que el potencial de lo que Claude puede hacer como colaborador técnico, cuando está apropiadamente estructurado, informado, y empoderado, es órdenes de magnitud superior a lo que la mayoría de sus usuarios están experimentando.

La restricción no es el modelo. La restricción es el flujo de trabajo.

El directorio de logs de sesión en mi captura de pantalla contiene más de 40 logs detallados de los últimos dos meses solamente. Cada uno representa una sesión de ingeniería de varias horas produciendo software de grado producción. El servidor MCP para sh0 -- una pieza no trivial de ingeniería de protocolo -- fue diseñado, implementado, doble-auditado, y entregado por Claude en dos días. El lenguaje de programación FLIN -- un compilador completo en Rust con una VM de bytecode, un motor de base de datos nativo, y más de 420 funciones integradas -- fue construido en 40 días, con más de 4.400 tests, por Claude.

Esto sucedió desde Abiyán, Costa de Marfil. De un fundador solo con cero equipo de ingeniería.

Si esto es lo que es posible con Claude hoy, con el flujo de trabajo que he desarrollado mayormente por ensayo y error durante 16 meses -- quiero saber qué se vuelve posible cuando más personas entiendan el sistema. No los prompts. No los "trucos." El sistema.

Por eso publico esto hoy.

Cómo empezar a implementar esto hoy

Las ediciones anteriores de este artículo cerraban con una escalera de ocho pasos, añadidos uno a uno a medida que el sistema crecía — escribe el CLAUDE.md, divide el trabajo en fases, ejecuta una auditoría, otorga la autoridad para estar en desacuerdo, instala la capa de estado, gradúa hacia los workflows, cierra el ciclo, haz que la apertura de una sesión sea una decisión. Esa escalera se ha convertido ahora en el playbook al inicio de este artículo, expandida en el camino completo con los comandos exactos. Así que la versión honesta de «empieza hoy» es una sola línea:

Haz la Etapa 0 y la Etapa 2 esta noche — una hora para el kit de herramientas, diez minutos para tu repositorio más activo — y dirige tu próxima sesión con los cuatro tiempos de la Etapa 5.

Eso por sí solo cambia lo que obtienes de Claude. No incrementalmente — estructuralmente. Las etapas restantes te arrastrarán por sí solas: la primera vez que casp check bloquee un push que habría mentido, querrás el ciclo de auditoría; la primera vez que una auditoría encuentre lo que los tests no vieron, querrás un verificador que no sea el que construye; y la primera vez que la cola secuencial te bloquee de verdad, estarás listo para leer la Etapa 8 tal como está escrita — como un costo, con un motivo.

El panorama general

Quiero terminar con algo que no se trata de código ni de flujos de trabajo.

Este software no se construyó en San Francisco. No lo construyó un equipo bien financiado. No tenía un CTO con un título de CS de Stanford.

Vino de Abiyán, Costa de Marfil. De un fundador solo. Con un presupuesto IA que alcanzó un pico de ~$5.000/mes y un sistema que tomó 16 meses desarrollar. Hoy a $200/mes en Claude Max.

Siete productos en producción. Tres lenguajes de programación. Más de 4.400 tests. 51 vulnerabilidades de seguridad encontradas y corregidas. Un lenguaje de programación que se lanza en junio.

Lo que quiero que otros fundadores -- especialmente fundadores africanos, pero honestamente cualquier fundador en cualquier lugar que no tenga los recursos de una startup financiada de San Francisco -- entiendan es esto:

La geografía ya no es destino. El capital ya no es el factor limitante. El factor limitante es la calidad de tu sistema operativo para trabajar con IA.

Construí ese sistema. Lo comparto hoy. Y seguiré mejorándolo, documentándolo, y publicándolo -- log de sesión por log de sesión, artículo por artículo, producto por producto.

Porque la prueba de que funciona no es un artículo de blog. La prueba son siete productos en producción y un lenguaje de programación que se entrega en 84 días.

Un fundador. Un CTO IA. Siete productos. Cero excusas.

Lee a continuación: - La herramienta rápida y la regla lenta -- El movimiento de apertura del Pilar 9: el lanzador de una sola palabra, los tres rechazos, y la guarda que impide que una herramienta rápida desarme el arbitraje. - Los workers auditaron al controlador -- El Pilar 9 medido: nuestro primer día de flota, donde las correcciones más valiosas fluyeron todas hacia arriba. - Conductor: el espacio de trabajo que reemplazó la fila de pestañas -- La cabina en la que corre la flota: cada sesión con nombre y direccionable, dirigible desde un teléfono. - senndo, día cero: todo el arnés de Fable 5, cableado antes de la primera línea de código -- El Pilar 8 instalándose en un producto totalmente nuevo: el ciclo de construcción, el verificador, el archivo de estado que se acumula -- antes de que exista código alguno. - Trece agentes, cuarenta y tres minutos: la primera sesión de workflow con Claude Fable 5 -- El Pilar 7 en producción: la historia completa del sitio de 7 páginas entregado por un workflow multi-agente programado. - Notas de campo de Claude Fable 5 para desarrolladores senior -- El compañero 100% técnico: cada capacidad que usaron los trece agentes, con código. - Cuando tu CTO IA le dice que no a tu auditor IA -- El relato propio de Claude de rechazar un plan de otra instancia de Claude. Escrito en la voz de Claude. - El plan de arquitectura del servidor MCP de sh0 -- El plan técnico completo que fue implementado usando este flujo de trabajo. - Prompt de implementación: sh0 AI Phase 6 y agentes especialistas -- El prompt de seguimiento que impulsó la Phase 6 (Web Search + URL Browsing), la Phase 6.5 (subidas de archivos e imágenes) y la Phase 8 (agentes especialistas). - El portafolio de productos ZeroSuite -- Los 7 productos, todos construidos con este sistema.

Descargas

Los documentos reales referenciados en este artículo. Sin barreras, sin muro de correo electrónico -- simplemente descarga y aprende.

• Plan de arquitectura del servidor MCP de sh0 (PDF) -- El plan técnico completo en 5 fases implementado con este flujo de trabajo. Diagramas de arquitectura, desgloses por fases, tabla de decisiones clave.

• Prompt de implementación de la Fase 6 y agentes especializados de sh0 -- El prompt de implementación real utilizado para construir la búsqueda web, la carga de archivos y 6 agentes IA especializados. Este es el documento que Claude recibe antes de que comience una sesión.