Spec-Driven Development.
Escreva primeiro uma especificação explícita e autoritativa e, então, derive dela a implementação, os testes e o código gerado — mantendo a especificação como a única fonte da verdade.
##Intent
Faça de uma especificação precisa o artefato primário do desenvolvimento. A implementação, os testes e até o código gerado por IA são derivados da especificação e verificados em relação a ela, em vez de a especificação ser um documento descartável escrito antes do trabalho "de verdade".
##Problem
Os requisitos geralmente vivem na cabeça das pessoas, em conversas de chat ou em documentos desatualizados. A implementação se distancia da intenção e, quando isso acontece, não há referência autoritativa para definir o que o sistema deveria fazer.
Isso é mais doloroso na programação assistida por IA: um prompt vago produz um código de aparência plausível que pode não corresponder ao que realmente se queria, e não há nada concreto para verificá-lo.
##Solution
Capture o comportamento pretendido em uma especificação clara e versionada — cenários, critérios de aceitação e contratos — e trate-a como a fonte da verdade. Gere ou guie a implementação (muitas vezes com a assistência de IA) a partir da especificação, derive testes de conformidade da mesma especificação e verifique a implementação em relação a eles.
Quando o comportamento precisar mudar, você muda a especificação primeiro e deixa a implementação e os testes seguirem. A especificação, não o código, é o que a equipe revisa e discute.
##Structure
- Especificação — intenção, cenários, critérios de aceitação e contratos/schemas, mantidos sob controle de versão.
- Geração / implementação — código produzido ou guiado para satisfazer a especificação.
- Testes de conformidade — verificações derivadas da especificação que a implementação deve passar.
- Ciclo de feedback — discrepâncias atualizam a especificação, que reorienta o código e os testes.
##Applicability
- Use em desenvolvimento assistido por IA, onde uma especificação precisa transforma um prompt vago em uma intenção verificável.
- Use em APIs contract-first, coordenação entre múltiplas equipes e sistemas regulados ou auditáveis.
- Evite especificações pesadas para scripts minúsculos ou spikes exploratórios, onde elas custam mais do que retornam.
##How to Implement
- Escreva a especificação: intenção, cenários concretos, critérios de aceitação e quaisquer contratos ou schemas.
- Revise-a com as partes interessadas — é aqui que as divergências são resolvidas.
- Derive testes de aceitação / conformidade a partir dos cenários.
- Implemente para satisfazer a especificação, frequentemente com a assistência de IA guiada pela especificação.
- Rode os testes de conformidade; trate as falhas como bugs ou como sinais para refinar a especificação.
- Mantenha a especificação como autoridade — atualize-a primeiro sempre que o comportamento mudar.
##Pros & Cons
- Uma única fonte da verdade, revisável, mantém a intenção explícita.
- Combina naturalmente com a geração de código por IA, transformando prompts em contratos verificáveis.
- A conformidade pode ser verificada automaticamente, reduzindo o desvio.
- As decisões são debatidas sobre a especificação, antes de o código ser escrito.
- Exige esforço inicial real para escrever e manter a especificação.
- Especificações apodrecem e enganam se não forem mantidas em sincronia com a realidade.
- O ferramental e as convenções ainda estão amadurecendo.
- Especificar demais pode ser tão prejudicial quanto especificar de menos.
