Spec Kit em um projeto full-stack real: como 17 sprints levaram um tracker de hábitos à produção

O Spec-Driven Development foi além de uma demo de uma noite e chegou a um lançamento full-stack completo. O caso do LifeSync descreve 17 sprints de desenvolvimento de um tracker de hábitos e metas, dois repositórios separados, centenas de testes e a chegada à produção. A principal conclusão: em um projeto grande, o SDD é útil não pela velocidade de geração de código, mas por evitar a perda de controle quando backend, frontend e infraestrutura começam a puxar o projeto em direções diferentes.

O exemplo é um serviço B2C de hábitos e metas. O backend usa Spring Boot 3.5 e Java 21, é organizado em arquitetura hexagonal com seis módulos Maven, e adota jOOQ no lugar de JPA, Kafka para a lógica de eventos, JWT RS256 e OpenAPI 3.1 como contrato principal da API. O frontend é construído com React 19, TypeScript 5.9, Vite 8, TanStack React Query, Zustand e shadcn/ui com Tailwind CSS.

Em 17 sprints, o projeto chegou a 251 testes no servidor e 77 no cliente, ganhou 19 migrações Liquibase e foi para produção: o backend está implantado no Railway e o frontend na Vercel.

A ideia central do caso é que a escala exigiu outra disciplina de trabalho com IA. Em um projeto pequeno, bastavam um chat de raciocínio e um ambiente de execução. No full-stack, o autor chegou a um esquema de três chats: um contexto para o backend, outro para o frontend e um terceiro para coordenar as decisões comuns que afetam os dois repositórios, como deploy, funcionalidades transversais, mudanças de API e retrospectivas.

Isso é complementado por dois arquivos de constituição diferentes. O do backend cresceu com o tempo, de um template a 437 linhas, e incorporou regras sobre migrações, commits, estilo e OpenAPI. A constituição do frontend ficou bem mais compacta, com 137 linhas, porque o stack e os padrões já eram definidos de forma mais rígida desde o início.

O autor dá destaque ao comando speckit.analyze, que usa como ciclo obrigatório de feedback após cada sprint. Ele não substitui os testes nem finge ser um linter: confronta entre si spec.

md, plan.md, tasks.md e a implementação real.

Segundo o autor, essa análise ajudou a pegar um problema crítico no sprint de backend com Kafka: em vários casos de uso, a publicação de eventos acontecia dentro da transação, sem um try-catch de proteção. No ambiente de testes o erro não aparecia, porque o Kafka nos contêineres estava sempre disponível, mas, em uma falha real, poderia reverter dados já salvos e deixar o sistema em estado inconsistente. Depois da análise, o código ganhou proteção, a lógica de retry foi aprimorada e as verificações de integração foram ampliadas.

Outro pilar importante é a abordagem API-first como contrato entre os dois repositórios. O projeto tem um módulo dedicado a isso, com uma especificação OpenAPI de cerca de 2669 linhas e 32 endpoints. O backend gera a partir dela as interfaces Java dos controllers, enquanto o frontend usa o mesmo YAML como única fonte da verdade e mantém manualmente os tipos TypeScript para os cenários reais da interface.

O autor ressalta que o speckit.analyze não consegue validar automaticamente a consistência entre os dois repositórios ao mesmo tempo, então as verificações entre repositórios ainda precisam ser feitas manualmente pelo contexto de coordenação. Mesmo assim, o esquema reduz o risco de dessincronização silenciosa entre servidor e interface: se a API muda, isso é registrado primeiro na especificação e depois aparece na geração das interfaces ou na compilação do frontend.

A conclusão prática é bem dura: o SDD escala, mas só se for tratado como um sistema de gestão de mudanças, e não como um jeito de pedir para a IA escrever uma feature. Em tarefas curtas, talvez não se perceba a diferença, mas ao longo de dezenas de sprints são justamente os elementos chatos do processo que compensam: constituições vivas, contextos separados, artefatos formais e verificação regular da consistência entre eles.

O caso é interessante porque mostra o SDD não em um MVP de brinquedo, mas em um projeto que já tem produção, ciclo de testes, repositórios separados e um custo real para erros de arquitetura e de contratos.