Hoy el script de ayer se convierte en un aplicativo de verdad
En la S2 le pedisteis a Claude Code un script que caza solapamientos en un CSV de redes. Hoy ese script deja de estar suelto: se convierte en un módulo de un aplicativo de verdad, con su base de datos y su interfaz.
El salto de hoy no es de herramienta, es de método. Construir algo entre ocho, sobre los mismos datos y sin pisarse, no se improvisa con prompts sueltos. Necesita un método. Ese método es lo primero que vemos.
La intención por delante de la ejecución. Escribes el contrato primero; el código viene después.
Cuando genera más rápido de lo que puedes revisar, la velocidad se vuelve deuda. Y los síntomas ya los conocéis.
Le faltaba el detalle, así que rellenó los huecos a su manera. Funciona, pero no era lo que hacía falta.
Dos personas lo piden con palabras distintas y salen dos soluciones que no encajan. Nadie sabe cuál vale.
El código parecía bien. El fallo aparece cuando ya cuesta caro: en la revisión, en pruebas o ante el cliente.
La causa no es el modelo: es el encargo. Un trabajo mal definido produce el mejor código posible para una pregunta mal formulada.
Una spec incompleta no produce código malo por accidente: produce el mejor código posible para una pregunta mal formulada.
El principio que sostiene todo lo que hacemos hoy
Una tarea normal son varios pasos encadenados. Si cada uno sale "casi bien" y el error se arrastra al siguiente, la cuenta no es la que parece.
Cada paso hereda el error del anterior. La spec no hace que cada paso sea más listo: hace que los cinco apunten al mismo sitio. Por eso, con el contrato escrito antes, el 90% deja de multiplicarse a la baja.
"Spec" asusta menos de lo que suena. No es un documento enorme: es un texto corto que dice qué quieres, con qué reglas y cómo se sabe que está bien.
El mismo agente, el mismo modelo. Lo único que cambia entre un buen resultado y uno malo es el encargo que le das. La spec es ese encargo, por escrito y por adelantado.
SDD es un bucle de tres tiempos. La gracia está en que los tres se hacen contra el mismo contrato: el plan lo escribe, la ejecución lo cumple, la verificación lo comprueba.
Antes de tocar código, defines qué quieres y cómo se sabrá que está bien. Lo revisas tú. Aquí es donde ganas o pierdes el día.
Claude implementa la spec sin improvisar: rama, tests, código. No adivina lo que no está escrito; lo hace lo que está escrito.
¿Cumple cada criterio, sí o no? No es una opinión: es contrastar el resultado con el contrato que firmasteis al principio.
El método necesita una herramienta que lo lleve por raíles. Esa herramienta se llama OpenSpec, y se maneja con comandos.
OpenSpec es el andamiaje que convierte "plan → ejecutar → verificar" en un flujo real dentro de Claude Code. No ejecuta nada por su cuenta: ordena el trabajo y guarda el contrato.
Cuatro órdenes que llevan un cambio de la idea hasta el cierre. Las escribís vosotros; el trabajo pesado lo hace Claude.
Cada artefacto queda escrito en el repo. El proyecto entero le sirve de contexto a Claude para construir lo que vosotros queréis, no lo genérico.
Si la spec es clara, el código sale bien. Si la spec es ambigua, el código también lo será. Ahí es donde se decide todo.
De la idea al cierre, siempre el mismo camino. Hoy lo veréis entero una vez, y luego cada uno entra por el segundo paso.
Convierte la idea en el cambio y genera todos los artefactos de una vez: proposal, spec, design y tasks. El qué, el porqué y el cómo.
El agente implementa la spec: rama, código y tests. No improvisa: hace lo que el contrato dice, tarea a tarea.
La IA contrasta lo construido con la spec y las tareas. Marca lo que falla antes de que lo veáis en el PR.
La spec verificada se archiva como fuente de verdad. No se tira: es el contexto de la siguiente pieza.
Cada cambio abre su propia carpeta en openspec/changes/<nombre>/. Cuatro archivos que no son documentación: son las instrucciones que la IA sigue.
Por eso el contexto no se pierde. El contrato está en el repo, no en la cabeza de nadie ni en un chat que se borra. Claude lo lee antes de construir — y por eso construye lo vuestro.
Media hora. Son dos piezas distintas y conviene no confundirlas: Claude Code ya lo tenéis; hoy añadimos el kit y la base de datos.
Es la confusión número uno. En la S2 instalasteis Claude Code sin Node ni permisos de admin. El kit SDD es otra pieza, y esa sí trae sus requisitos.
La herramienta con la que habláis en la terminal. Se instaló sola en la S2 y se actualiza sola. No necesita Node.
El harness que trae el ciclo /opsx:*. Se instala con npm, así que este sí necesita Node.js. Son piezas distintas.
Y una tercera pieza: el portal guarda datos, así que necesita una base de datos. La levantamos con Docker Desktop — un comando y ya está corriendo, sin instalar Postgres a mano.
Como en la S2: nadie se queda atrás. Si a alguien le falla uno, se pone con el de al lado y lo arreglamos en la pausa.
Comprobad que sigue: claude --version os devuelve un número. Si es así, este paso ya está de la S2.
Instaláis Node y luego el harness: npm i -g @fission-ai/openspec. Es lo que activa los comandos /opsx:*.
Para la base de datos del portal. Con docker compose up arranca Postgres y la aplicación juntos.
Ya trae el andamiaje montado y vuestro cambio pre-cocido. No partís de una carpeta vacía: partís de vuestro contrato.
Es el proyecto que vais a construir hoy: ya trae el andamiaje y vuestro cambio pre-cocido. El primer paso, antes de nada, es traerlo a vuestra máquina.
git clone https://github.com/david-ramos-23/daratel-claude-code-s3.git
No es público: solo puede clonarlo quien esté invitado como colaborador, cada uno con su cuenta de GitHub.
Un error de permisos al clonar significa que falta vuestra invitación. Levantad la mano y os añade al momento.
Lo que vais a construir. El sitio donde, por fin, se ve de un vistazo qué tiene en servicio cada cliente.
Hoy, para saber todo lo que tiene un cliente —sus sedes, su direccionamiento, sus equipos, sus servicios— hay que saltar entre varias hojas de cálculo. Y lo que está en un Excel suelto no lo comprueba nadie.
Y no es un ejercicio de juguete. Es el dolor que salió en la encuesta: la información de los clientes, dispersa y sin comprobar. Hoy le ponéis la primera piedra.
No hace falta ser desarrollador para entender la forma. Son tres cosas, y encajan igual que en cualquier aplicativo que uséis a diario.
El programa que recibe las peticiones y responde: "dame los clientes", "da de alta esta subred". La lógica vive aquí.
Postgres, donde queda guardado todo de forma ordenada. Sustituye al Excel: un solo sitio, consultable y con reglas.
Una pantalla para las personas y una lista de operaciones en /docs para probar cada módulo sin escribir código.
Y todo se levanta con un comando. docker compose up y tenéis la aplicación y su base de datos corriendo. Ni instalar Postgres, ni pelear con versiones. Ese es medio truco del método.
El portal lo construís ocho, cada cual su pieza, sobre los mismos datos. Todas cuelgan de la ficha de Cliente, que montamos juntos en la demo.
Alta, consulta y baja de cada sede del cliente.
Gestiona las subredes y valida el CIDR en el alta.
Una IP en su rango y sin duplicar. La lógica de la S2, ya de verdad.
Routers, switches y firewalls de cada sede, en un solo sitio.
La cartera de cada cliente y el estado de cada servicio.
Sedes, subredes, IPs, servicios y equipos en una respuesta. El corazón.
Entra un CSV validado por fila; sale un CSV para quien lo necesite.
"El firewall de la sede de Madrid" y aparece.
Primero miráis el ciclo entero una vez. Luego lo hacéis vosotros, cada uno con su módulo. Aquí es donde deja de ser una charla.
Nadie hace el ciclo entero a ciegas. Lo veis una vez completo, sobre la ficha de Cliente, y solo después entráis vosotros — y entráis con el contrato ya escrito.
Por eso hoy no hay caos. Ocho personas construyendo a la vez, pero cada una sobre su contrato y su carpeta. Se juntan al final, no por el camino.
Sesenta minutos. Llegar al tests en verde ya es haberlo conseguido; el PR es el remate.
Abre openspec/changes/<tu-módulo>/ y léete la spec: entiende qué te van a pedir que cumpla.
El agente crea el módulo, el código y los tests. Tú lees lo que propone y apruebas. Sin barra libre.
Lanza los tests. Si pasan, tu módulo cumple el contrato. Si no, se lo dices a Claude y afina.
La IA comprueba lo construido contra la spec. La segunda red antes del PR.
Abres el Pull Request y David lo revisa con vosotros. Esa revisión es la firma.
Si os lleváis una idea de hoy, que sea esta: el método no va de fiarse de la IA, va de ponerle un contrato delante y comprobar que lo cumple.
Y al revés: spec ambigua, código ambiguo. Lo que lo arregla es afinar la spec, no insistir.
Tests en verde y /opsx:verify antes del PR. "Parece que va" no es "va". Se comprueba.
Vuestro portal existe. En la S4 le ponemos encima un agente que lo consulta y responde. Sin portal, no había S4.
Habéis construido una pieza real de un aplicativo real. Ocho módulos, una fuente de verdad. El Excel empieza a sobrar. Nos vemos en la S4.
Sobre todo las de
"a mí el apply no me ha hecho lo que esperaba".