Por Thales (Juste Gnimavo) — CEO y fundador, ZeroSuite, Inc.
Nota sobre el cliente: cuando se hace referencia a un proyecto de cliente, este aparece bajo el seudónimo KASSIA. El nombre real de la empresa y su dominio se omiten a petición del cliente mientras terminan su sitio web público.
La pregunta que recibo más que ninguna otra es alguna versión de: «¿Cómo saco lo mejor de Claude?»
Quienes la hacen casi siempre buscan un mejor prompt. Una formulación mágica. Un system prompt que desbloquee un nivel oculto del modelo. Y entiendo el instinto, pero es el marco equivocado, y perseguirlo es la razón por la que la mayoría se estanca en «autocompletado impresionante».
Aquí va la respuesta real, y me tomó dieciséis meses y siete productos en producción llegar a ella: lo mejor de Claude no es un genio en un solo chat. Son tres superficies especializadas de Claude, operadas como un equipo, sobre un único hilo de estado compartido que sobrevive al hecho de que ninguna de ellas recuerda nada.
Esa frase tiene dos mitades, y ambas importan. La primera mitad — el trío — trata de usar la superficie correcta para la tarea correcta. La segunda mitad — el hilo compartido y validado — trata del problema del que nadie te advierte: las tres superficies no comparten memoria, y sin una solución deliberada, cada traspaso entre ellas pierde contexto. La solución es un pequeño protocolo open source que construí, llamado CASP. Este artículo trata de cómo encajan las dos mitades en un único sistema operativo.
El sistema operativo en una sola imagen: tres superficies de Claude, cada una un contexto sellado sin memoria de las otras, conectadas por un único hilo de estado validado. La estrategia fluye hacia el diseño y hacia la implementación; cada traspaso lee y escribe los mismos archivos CASP — y casp check bloquea el push en el momento en que ese estado deja de coincidir con git.
El trío: tres superficies, tres trabajos
Claude no es un único producto con el que conversas. Son al menos tres contextos operativos distintos, y quienes le sacan más provecho son los que dejaron de tratarlos como intercambiables.
Claude Web (claude.ai, el chat) es el estratega y cofundador. Aquí es donde mantengo conversaciones estratégicas de largo aliento, a lo largo de varios días: posicionamiento de producto, razonamiento de mercado, los documentos SPEC, el copywriting, el arbitraje de arquitectura. El Claude de Web sostiene un argumento largo a lo largo de muchos turnos, hace referencia a cosas que dije hace una hora y — cuando lo he configurado correctamente — me planta cara cuando mi enfoque se desvía. He llegado a que me cite mi propio mensaje anterior y se niegue a validar un giro hasta que produje una señal de mercado. Eso es un asesor estratégico, no una caja de búsqueda.
Claude Design (claude.ai/design) es el diseñador principal. Es dueño de todo el sistema visual y de UX de principio a fin — tokens, una biblioteca de componentes tipados, kits de UI clicables, el lenguaje de diseño para las funciones de IA dentro del producto. No mockups: un sistema de diseño versionado y de calidad de producción, producido a partir de un brief. Escribí un artículo entero solo sobre esta superficie, porque es la más subestimada de las tres: Claude Design es el miembro más subestimado de mi equipo de IA.
Claude Code (la CLI) es el ingeniero senior con un equipo de subagentes. Tickets estructurados, ramas Git en paralelo, grafos de dependencias, bucles de auditoría multiagente, commits a prueba de regresiones. Aquí es donde las decisiones se convierten en código desplegado. El sistema de ingeniería completo alrededor de esta superficie — la constitución CLAUDE.md, la arquitectura de sesiones, el doble bucle de auditoría, la autoridad para decir que no — es su propio artículo largo: El flujo de trabajo completo y sin filtros que uso para que Claude construya software de nivel producción.
Cada superficie tiene sus propias fortalezas, su propio formato de entrada y su propio listón de calidad. Operar bien el Claude de Web no es la misma habilidad que operar bien Claude Code. Operar el trío es la habilidad de un CEO dirigiendo a tres especialistas — un estratega, un diseñador, un ingeniero — no la habilidad de un aficionado pidiéndole a un bot que escriba código. Esa parte la mayoría de los constructores serios la acaban descubriendo.
Aquí va la parte que no.
El problema del que nadie te advierte: el trío tiene amnesia
Las tres superficies no comparten ninguna memoria. Ninguna.
La conversación estratégica que tuve con el Claude de Web el lunes — la que fijó todo el posicionamiento de una función — no existe para Claude Code el martes. El sistema de diseño que produjo Claude Design vive en su espacio de trabajo; la sesión de ingeniería que tiene que portarlo arranca a ciegas sobre cómo se razonó. Y Claude Code en sí mismo no tiene persistencia entre sesiones: cada sesión empieza desde cero contexto, por diseño, porque no hay memoria entre ellas.
Así que lo que realmente tienes, cuando operas el trío, son tres especialistas brillantes encerrados en tres salas separadas, cada uno con amnesia total sobre lo que ocurre en las otras salas — y sobre lo que ellos mismos hicieron ayer. El estratega olvida. El diseñador olvida. El ingeniero olvida. Cada traspaso entre ellos es una puerta donde el contexto se cae al suelo.
Este es el verdadero cuello de botella para sacar lo mejor de Claude a escala. No es la calidad del modelo — los modelos son extraordinarios. Es que cuanto más capaz se vuelve cada superficie, más devastadora se vuelve la amnesia. Los nuevos modelos funcionan durante horas, incluso días, ejecutando fase tras fase. Una superficie que hace más entre tus puntos de control es una superficie cuyo estado registrado puede dejar de coincidir silenciosamente con la realidad a lo largo de una brecha cada vez más grande. La capacidad empeora el problema de la memoria, no lo mejora.
La gente tapa esto con tableros, tarjetas, páginas de Notion, un archivo STATE.md que actualizan a mano. Nada de eso funciona, por dos razones. Primero, es manual, así que se pudre — dejas de actualizarlo el día que estás ocupado, que es todos los días. Segundo, y peor: el agente no puede leerlo de forma fiable, y no puede demostrar que sea cierto. Un archivo de estado que dice «siguiente: construir la función de cámara» cuando la cámara se desplegó la semana pasada no solo deja de ayudar — hace que tu agente esté confiadamente equivocado. Empieza un trabajo que ya existe. Pierdes una tarde deshaciéndolo. Un archivo de estado obsoleto es el modo de fallo más caro en el desarrollo asistido por IA, porque no lo detectas hasta que el trabajo duplicado ya está hecho.
CASP: la memoria que el trío no tiene — y que no puede mentir
Así que construí la capa que faltaba y la liberé como open source: CASP — el Coding-Agent State Protocol (npx @justethales/casp · casp.sh · MIT, cero telemetría, sin SaaS, nada sale de tu máquina).
CASP es el hilo compartido y validado que las tres superficies de Claude no tienen por sí solas. Es deliberadamente diminuto — tres archivos planos que un agente puede leer en la primera línea de cualquier sesión, generados en un directorio casp/ mediante casp init:
state.json— la fuente de verdad legible por máquina: fase actual, el next-prompt exacto a ejecutar, fases desplegadas, migraciones aplicadas, último commit, último id de sesión. Esto es lo que cualquiera de las tres superficies lee para saber dónde está realmente el proyecto.now.md— el «dónde estoy ahora mismo» de una pantalla, para humanos. Ábrelo y recuperas el hilo en cinco segundos.roadmap.md— los Next-3 a desplegar, en orden, más un marcador de fases.
Eso por sí solo sería simplemente un STATE.md más ordenado. Lo que hace que CASP importe es un único verbo: casp check. Todo el mundo almacena contexto — tableros, herramientas de memoria, notas. CASP lo valida. La verificación lee tu estado almacenado y lo comprueba contra la verdad de terreno de git: un next_prompt que apunta a una fase ya desplegada, un last_commit que no está en el historial, una lista de migraciones que discrepa del directorio de migraciones — todo detectado, de forma determinista, con un pass/fail tajante. Las salidas limpias terminan en cero. La deriva termina con un código distinto de cero y bloquea el push. Ponlo en CI y un archivo de estado mentiroso nunca podrá llegar a tu remoto.
yaml# .github/workflows/ci.yml — la deriva no puede mergear
jobs:
state-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with: { fetch-depth: 0 }
- run: npx @justethales/casp check
casp check sobre un estado con deriva (arriba) frente a uno limpio (abajo). Valida el estado almacenado contra la verdad de terreno de git y devuelve un pass/fail tajante — de modo que el hilo compartido del que dependen las tres superficies nunca puede empezar a mentir en silencio.
Esta es la propiedad que lo hace funcionar como memoria compartida para el trío: el hilo no solo es compartido, es demostrablemente cierto. Las herramientas de memoria almacenan y recuperan con similitud difusa; CASP ejecuta una verificación síncrona y determinista contra git y te detiene cuando el estado miente. Una memoria compartida que puede derivar por sí misma no vale nada — vuelves a estar confiadamente equivocado, un nivel más arriba. Una memoria compartida controlada contra la verdad de terreno es lo sobre lo que realmente puedes construir un flujo de trabajo multisuperficie. (CASP no es una capa de memoria de IA en el sentido de Mem0 / Letta — esas recuerdan quién eres; CASP rastrea dónde está el proyecto y lo demuestra. Artefacto distinto, fallo distinto prevenido. Escribí el artículo dedicado aquí: CASP: la pequeña CLI que arregló mi flujo de trabajo con IA.)
Cómo corre el trío sobre un único hilo CASP — un día concreto
Esto es cómo se ve un día real cuando las tres superficies y la capa de estado operan como un solo sistema. No es el diagrama de un ideal; es el bucle que de hecho ejecuto.
Estrategia, en el Claude de Web. Abro una conversación de largo aliento para decidir qué se despliega a continuación y por qué. Discutimos el posicionamiento, sopesamos los compromisos, congelamos la decisión. La salida no es código — es una spec congelada y un siguiente paso claro. Esa decisión aterriza en el proyecto como la siguiente fase en roadmap.md y un prompt de sesión redactado a partir de la plantilla canónica (casp new prompt — las plantillas son controles, no sugerencias, así que cada prompt tiene la misma forma).
Diseño, en Claude Design. Si la fase tiene una superficie, Claude Design produce o extiende el sistema para ella — los tokens, el componente, la pantalla del kit de UI — y devuelve un artefacto de calidad de producción: contratos tipados y una referencia exacta al píxel. Ese artefacto es el contrato que la superficie de ingeniería va a consumir. La decisión de diseño está ahora escrita, no atrapada en un espacio de trabajo que nadie más puede leer.
Ingeniería, en Claude Code. La sesión abre con un solo comando: casp next. Claude Code lee state.json en la primera línea, conoce la fase exacta y el next-prompt exacto — sin redescubrimiento, sin «recuérdame dónde estábamos» — y ejecuta. Porta el artefacto de diseño contra su contrato, corre el trabajo en fases estructuradas y dispara el bucle de auditoría independiente. Al final, la sesión escribe su propia bitácora de sesión, redacta el prompt de la siguiente sesión y actualiza el estado — luego casp check valida todo el conjunto contra git antes de que nada se empuje. Desplegar deriva es imposible.
Fíjate en lo que acaba de ocurrir. La decisión del estratega llegó al ingeniero sin que ninguno de los dos compartiera una ventana de contexto. El artefacto del diseñador llegó al portador como un contrato explícito, no un vago «haz que se parezca al mockup». Y la sesión de mañana — una instancia distinta y en blanco de Claude Code — abrirá state.json y sabrá con precisión dónde está el proyecto, porque ahora el proyecto se recuerda a sí mismo, en una forma que es legible por máquina y demostrada cierta. La amnesia sigue ahí. CASP simplemente hizo que dejara de importar.
Ese es todo el truco. No arreglas la memoria de ninguna superficie individual. Le das a las tres superficies un único hilo externo que no miente, y los traspasos dejan de perder contexto.
Cómo empezar — esta semana
No necesitas siete productos para correr esto. Necesitas las dos mitades.
Mitad uno — opera el trío, deja de cazar el prompt mágico. Para tu próximo trabajo real, divídelo deliberadamente entre las tres superficies. Haz la estrategia y la spec en una conversación larga con el Claude de Web, y dale permiso para plantarte cara. Haz el sistema de diseño — primero los tokens, luego los componentes con contratos — en Claude Design antes de cualquier código de producción (el artículo sobre Design es el manual de juego). Haz la implementación en Claude Code con fases estructuradas y al menos una sesión de auditoría independiente. Tres superficies, tres trabajos, un director: tú.
Mitad dos — dales un único hilo validado. npx @justethales/casp init en tu repositorio más activo. Rellena state.json con honestidad una vez. Termina tu próxima sesión dejando que el agente redacte el prompt de la siguiente sesión y actualice el estado. Ejecuta casp check antes de empujar — y ponlo en CI esa misma semana. A partir de ese punto, cada superficie abre cada sesión sabiendo exactamente dónde está el proyecto, y un archivo de estado mentiroso nunca podrá llegar a tu remoto.
El cambio de mentalidad lo es todo: deja de intentar extraer más de un solo Claude. Empieza a operar tres, y dales una memoria que no pueda derivar. El apalancamiento no está en el prompt. Está en la orquestación.
El panorama general
Construyo desde Abiyán, con una suscripción Claude Max, como único ingeniero de siete productos en producción. Nada de eso es posible siendo astuto con una sola ventana de chat. Es posible porque dejé de preguntar «¿cómo saco lo mejor de Claude?» y empecé a preguntar «¿cómo opero un equipo virtual de especialistas Claude para que el proyecto nunca se olvide de sí mismo?».
El modelo sostiene el contexto. El trío hace el trabajo — estrategia, diseño, ingeniería, cada uno sobre la superficie construida para ello. Y CASP demuestra que el estado es cierto, de modo que tres superficies sin memoria compartida pueden aun así comportarse como un solo equipo que nunca pierde el hilo.
Así es como sacas lo mejor de Claude. No un mejor prompt. Un mejor sistema operativo.
Lee a continuación:
- Claude Design es el miembro más subestimado de mi equipo de IA — la inmersión profunda en la superficie de diseño y el proceso de seis pasos.
- El flujo de trabajo completo y sin filtros que uso para que Claude construya software de nivel producción — el sistema de ingeniería completo de siete pilares alrededor de Claude Code.
- CASP: la pequeña CLI que arregló mi flujo de trabajo con IA — la historia dedicada de la capa de estado. Código en GitHub, npx @justethales/casp init.
Un fundador. Tres superficies de Claude. Un hilo validado. Siete productos.