Por Thales (Juste Gnimavo) -- CEO y Fundador, ZeroSuite, Inc.
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?
Seis productos en producción. Tres lenguajes de programación -- Rust, Python, TypeScript. Más de 3.700 tests. 51 vulnerabilidades de seguridad encontradas y corregidas. Más de 90 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 costos de IA.
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 3.700 tests. Construido en 40 días. Lanzamiento oficial: 19 de junio de 2026.
deblo.ai -- La plataforma de educación IA de África. 13 niveles académicos, más de 15 materias, 101 asesores profesionales IA. Cubre contabilidad SYSCOHADA y derecho OHADA. Pagos con Mobile Money nativos. Objetivo: 250 millones de estudiantes africanos.
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.
Seis 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.
Los cinco pilares de mi sistema
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.
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: 6 productos en producción. 3 lenguajes de programación. Más de 90 sesiones de ingeniería, cada una de 4-12 horas de trabajo enfocado y estructurado. Un fundador. Un CTO IA. ~$5.000/mes en costos de IA.
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 presupuesto total de ingeniería IA es ~$5.000/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 90 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 3.700 tests, por Claude.
Esto sucedió desde Abiyán, Costa de Marfil. Con un presupuesto IA de ~$5.000/mes. 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
Sé que muchos de ustedes están leyendo esto y pensando: esto es interesante, pero es complejo, y no sé por dónde empezar.
Aquí está el punto de partida práctico.
Paso 1: Escribe un CLAUDE.md para tu proyecto más importante. Dedica 2 horas. Incluye: qué es el producto y por qué existe, el stack tecnológico completo con por qué se eligió cada pieza, las 5-10 decisiones arquitectónicas que nunca deben revertirse, el modelo de seguridad, las convenciones que definen el carácter del código base. Mantenlo por debajo de 1.500 palabras -- lo suficientemente denso para ser completo, lo suficientemente corto para que siempre se lea completo antes de una sesión.
Paso 2: Deja de darle funcionalidades a Claude. Empieza a darle fases. Toma tu próxima funcionalidad. Divídela en 3-5 fases. Escribe un brief solo para la Fase 1. Define "terminado." Implementa. Escribe un log de sesión antes de cerrar la pestaña.
Paso 3: Ejecuta una sesión de auditoría en tu próxima implementación. Abre un Claude Code o Claude chat fresco. Dale el código, el CLAUDE.md, y un brief de auditoría claro: "Tu trabajo es encontrar problemas de seguridad, errores de lógica, casos extremos faltantes, e inconsistencias arquitectónicas. Sé directo. Propón correcciones." Mira lo que encuentra. Te sorprenderás.
Paso 4: Dale a Claude permiso para estar en desacuerdo contigo. Ponlo por escrito en tu CLAUDE.md. "Tienes la autoridad y la obligación de decirme cuando una decisión técnica que estoy proponiendo está equivocada." Dilo en serio. Cuando Claude resiste, siéntate con eso por 60 segundos antes de anular.
Estos cuatro pasos por sí solos cambiarán la calidad de lo que obtienes de Claude. No incrementalmente. Estructuralmente.
El panorama general
Quiero terminar con algo que no se trata de código ni de flujos de trabajo.
El proyecto de ingeniería de software asistida por IA más ambicioso de principios de 2026 no vino de San Francisco. No vino de 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 de ~$5.000/mes y un sistema que tomó 16 meses desarrollar.
Seis productos en producción. Tres lenguajes de programación. Más de 3.700 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 seis productos en producción y un lenguaje de programación que se entrega en 84 días.
Un fundador. Un CTO IA. Seis productos. Cero excusas.
Lee a continuación: - 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. - El portafolio de productos ZeroSuite -- Los 6 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.