Spec Kit en Full-Stack Real: Cómo 17 Sprints Llevaron el Rastreador de Hábitos a Producción

Spec-Driven Development logró llegar no solo a una demostración de una noche, sino a un lanzamiento full-stack completo. El caso LifeSync describe 17 sprints de desarrollo de un rastreador de hábitos y objetivos, dos repositorios separados, cientos de pruebas y un lanzamiento a producción — y conduce a la conclusión principal: a escala, SDD es valioso no por la velocidad de generación de código, sino por evitar la pérdida de control cuando backend, frontend e infraestructura comienzan a tirar el proyecto en direcciones diferentes. El estudio de caso utiliza un servicio B2C para hábitos y objetivos como ejemplo.

El backend se construye en Spring Boot 3.5 y Java 21, organizado usando arquitectura hexagonal en seis módulos Maven, utiliza jOOQ en lugar de JPA, Kafka para lógica orientada a eventos, JWT RS256 y OpenAPI 3.1 como contrato de API principal.

El frontend se construye en React 19, TypeScript 5.9, Vite 8, TanStack React Query, Zustand y shadcn/ui con Tailwind CSS. Durante 17 sprints, el proyecto creció a 251 pruebas del lado del servidor y 77 pruebas del lado del cliente, recibió 19 migraciones Liquibase y fue lanzado a producción: backend implementado en Railway, frontend en Vercel.

El insight central del caso es que la escala exigió una disciplina diferente para trabajar con IA. Si un proyecto pequeño podría arreglárselas con un chat pensante y un entorno de ejecución, el autor llegó a un esquema de tres chats para el proyecto full-stack. Se necesita un contexto separado para backend, uno separado para frontend, y otro para coordinar decisiones comunes que afecten a ambos repositorios: implementación, características transversales, cambios de API y retrospectivas.

Esto se complementa con dos archivos de constitución diferentes. Para backend, el documento creció con el tiempo de una plantilla a 437 líneas e incorporó reglas sobre migraciones, commits, estilo y OpenAPI. Para frontend, la constitución era mucho más compacta — 137 líneas, porque el stack y los patrones fueron más estrictamente definidos desde el inicio.

Se hace especial énfasis en el comando speckit.analyze, que el autor utiliza como un bucle de retroalimentación obligatorio después de cada sprint. No reemplaza las pruebas y no pretende ser un linter, sino que reconcilia entre spec.

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

Según el autor, exactamente este tipo de análisis ayudó a detectar un problema crítico en el sprint Kafka del backend: la publicación de eventos en múltiples casos de uso estaba ocurriendo dentro de una transacción sin un try-catch protector. En el entorno de prueba, el error no se manifestó porque Kafka en contenedores siempre estaba disponible, pero en una falla real podría haber revertido datos ya guardados y dejado el sistema en un estado inconsistente. Después del análisis, se agregó protección al código, la lógica de reintentos se mejoró y las verificaciones de integración se expandieron.

Otro pilar importante es el enfoque API-first como contrato entre los dos repositorios. En el proyecto, se asigna un módulo separado para esto con una especificación OpenAPI de aproximadamente 2.669 líneas y 32 endpoints.

El backend genera interfaces de controladores Java a partir de ella, y el frontend utiliza el mismo YAML como la única fuente de verdad y mantiene manualmente tipos TypeScript para escenarios reales de UI. El autor señala específicamente que speckit.analyze no puede validar automáticamente la consistencia entre dos repositorios, por lo que las verificaciones entre repositorios aún deben hacerse manualmente a través del contexto de coordinación.

Pero incluso de esta forma, 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 aparece en la etapa de generación de interfaz o compilación del frontend. La conclusión práctica de este caso es bastante estricta: SDD escala, pero solo si lo tratas como un sistema de gestión de cambios, no como una forma de pedirle a IA que escriba una feature. En tareas cortas podrías no notar la diferencia, pero durante el curso de docenas de sprints, los elementos aburridos del proceso comienzan a pagarse — constituciones vivas, contextos separados, artefactos formales y verificaciones regulares de su consistencia.

El caso es interesante porque muestra SDD no en un MVP de juguete, sino en un proyecto que ya tiene producción, un bucle de prueba, repositorios separados y costo real de errores arquitectónicos y de contrato.