Spec Kit en un proyecto full-stack real: cómo 17 sprints llevaron un tracker de hábitos a producción

Spec-Driven Development ha llegado más allá de una demo de una tarde: hasta un lanzamiento full-stack completo. El caso de LifeSync describe 17 sprints de desarrollo de un tracker de hábitos y objetivos, dos repositorios independientes, cientos de tests y la salida a producción. Su conclusión principal: en un proyecto grande, SDD resulta útil no por la velocidad de generación de código, sino porque evita perder el control cuando backend, frontend e infraestructura empiezan a tirar del proyecto en direcciones distintas.

El ejemplo es un servicio B2C de hábitos y objetivos. El backend usa Spring Boot 3.5 y Java 21, está organizado con arquitectura hexagonal en seis módulos Maven, y emplea jOOQ en lugar de JPA, Kafka para la lógica de eventos, JWT RS256 y OpenAPI 3.1 como contrato principal de la API. El frontend está construido con React 19, TypeScript 5.9, Vite 8, TanStack React Query, Zustand y shadcn/ui con Tailwind CSS.

En 17 sprints el proyecto llegó a 251 tests en el servidor y 77 en el cliente, acumuló 19 migraciones de Liquibase y pasó a producción: el backend está desplegado en Railway y el frontend en Vercel.

La idea central del caso es que la escala exigió otra disciplina de trabajo con IA. En un proyecto pequeño bastaban un chat de razonamiento y un entorno de ejecución. En full-stack, el autor llegó a un esquema de tres chats: un contexto para el backend, otro para el frontend y un tercero para coordinar las decisiones comunes que afectan a ambos repositorios, como el despliegue, las funcionalidades transversales, los cambios de API y las retrospectivas.

A esto se suman dos archivos de constitución distintos. El del backend creció con el tiempo desde una plantilla hasta 437 líneas e incorporó reglas sobre migraciones, commits, estilo y OpenAPI. La constitución del frontend resultó bastante más compacta, con 137 líneas, porque el stack y los patrones estaban definidos con más rigidez desde el principio.

El autor hace hincapié en el comando speckit.analyze, que usa como circuito de retroalimentación obligatorio tras cada sprint. No sustituye a los tests ni finge ser un linter: contrasta entre sí spec.

md, plan.md, tasks.md y la implementación real.

Según el autor, este análisis ayudó a detectar un problema crítico en el sprint de backend con Kafka: en varios casos de uso, la publicación de eventos ocurría dentro de una transacción sin un try-catch de protección. En el entorno de pruebas el error no aparecía, porque Kafka en los contenedores siempre estaba disponible, pero en un fallo real podía revertir datos ya guardados y dejar el sistema en un estado inconsistente. Tras el análisis se añadió protección en el código, se mejoró la lógica de retry y se ampliaron las pruebas de integración.

Otro pilar importante es el enfoque API-first como contrato entre los dos repositorios. El proyecto dedica un módulo aparte a una especificación OpenAPI de unas 2669 líneas y 32 endpoints. El backend genera a partir de ella las interfaces Java de los controladores, mientras que el frontend usa el mismo YAML como única fuente de verdad y mantiene a mano los tipos de TypeScript adaptados a los escenarios reales de la interfaz.

El autor subraya que speckit.analyze no puede validar automáticamente la coherencia entre los dos repositorios a la vez, por lo que las comprobaciones entre repositorios aún se hacen a mano a través del contexto de coordinación. Aun así, el esquema reduce el riesgo de desincronización silenciosa entre servidor e interfaz: si la API cambia, primero se registra en la especificación y luego aflora al generar las interfaces o al compilar el frontend.

La conclusión práctica es bastante dura: SDD escala, pero solo si se trata como un sistema de gestión de cambios y no como una forma de pedirle a la IA que escriba una funcionalidad. En tareas cortas puede que no se note la diferencia, pero a lo largo de decenas de sprints compensan justamente los elementos aburridos del proceso: constituciones vivas, contextos separados, artefactos formales y verificación periódica de su coherencia.

El caso es interesante porque muestra SDD no en un MVP de juguete, sino en un proyecto que ya tiene producción, un circuito de pruebas, repositorios separados y un coste real por los errores de arquitectura y contratos.