SDD: O "Novo" Padrão que Tem 40 Anos

Sabe aquela sensação de quando você está usando uma técnica há anos, ninguém liga, e de repente todo mundo começa a falar dela como se fosse a última novidade? Pois é. Bem-vindo ao mundo do Spec-Driven Development (ou Schema-Driven Development, dependendo de quem você perguntar).

Disclaimer: não sou nenhum acadêmico nem estudioso de metodologias. Sou só um dev que trabalha com isso no dia a dia e que, quando viu o hype do SDD, pensou "ué, mas isso eu já faço há anos". Fui pesquisar e descobri que muita gente também.

O Hype Atual: "Vibe Coding vs SDD"

Em fevereiro de 2025, Andrej Karpathy cunhou o termo "vibe coding" pra descrever aquele fluxo de trabalho onde você basicamente conversa com uma IA, pede pra ela escrever código, aceita o que vier, e vai iterando até funcionar. Legal pra protótipos de fim de semana, desastroso pra produção.

A resposta da comunidade? "Precisamos de algo mais estruturado!" E aí surge o SDD, o Spec-Driven Development, como se fosse o santo graal do desenvolvimento com IA. O GitHub lançou o Spec-Kit. Ferramentas como Kiro, Tessl e OpenSpec apareceram. Todo mundo falando em "especificação como fonte única de verdade" e "execução determinística de intenções".

E eu aqui, tomando meu café, pensando: "Gente, isso existe desde antes de eu nascer."

Um Pouco de História (Que Ninguém Conta)

Os Anos 1960-1970: NASA e Métodos Formais

A ideia de especificar antes de codar não nasceu ontem. Na verdade, a Wikipedia menciona que as raízes do SDD remontam aos workflows da NASA nos anos 1960 e aos primeiros métodos formais que priorizavam verificação lógica antes da implementação.

Pensa bem: quando você está mandando gente pro espaço, "vibe coding" não é exatamente uma opção.

Os Anos 1980: Bertrand Meyer e o Design by Contract

Em 1986, um cara chamado Bertrand Meyer formalizou algo chamado Design by Contract (DbC) enquanto criava a linguagem Eiffel. A ideia era simples e genial: você define contratos formais para componentes de software (pré-condições, pós-condições e invariantes) antes de escrever qualquer linha de código.

Meyer foi fortemente influenciado por Edsger Dijkstra (programação estruturada) e C.A.R. Hoare (semântica axiomática, aquele paper de 1969 sobre base axiomática para programação). Ou seja, a fundamentação teórica vem dos anos 60 e 70.

O mantra do DbC é basicamente: "Defina obrigações e benefícios claros entre quem chama e quem é chamado." Parece familiar?

Os Anos 2000-2010: OpenAPI, Swagger e API-First

Em 2010, Tony Tam começou a trabalhar no que viria a ser o Swagger. Em 2015, a especificação foi doada para a Linux Foundation e renomeada OpenAPI Specification. O conceito central? Contract-first development: você define o contrato da API primeiro, programa a lógica de negócio depois.

Isso não é SDD? É sim. Só que chamavam de "API-First" ou "Design-First".

Um artigo da 99designs de 2021 já falava em "Schema-Driven Development" como uma forma eficiente de desenvolver APIs, onde a comunicação entre times melhora drasticamente porque todo mundo trabalha a partir de um schema compartilhado.

E tem mais: GraphQL popularizou a abordagem SDL-first (Schema Definition Language first) lá pelos idos de 2015-2016. gRPC usa Protocol Buffers como especificação desde 2015. JSON Schema existe desde 2009.

O Que Mudou? (Spoiler: Os Nomes)

Então por que agora todo mundo age como se SDD fosse novidade?

Porque a IA generativa criou um problema que essa técnica resolve muito bem.

Quando você pede pra uma IA escrever código no modo "vibe", ela não tem contexto suficiente. Ela não sabe quais são suas restrições de arquitetura, seus padrões de projeto, suas regras de negócio. Ela adivinha. E adivinhar em software é receita pra desastre.

Uma pesquisa da Final Round AI de agosto de 2025 mostrou que 16 de 18 CTOs entrevistados relataram desastres em produção causados diretamente por código gerado por IA sem supervisão adequada.

O SDD resolve isso ao dar à IA (e aos humanos) uma especificação clara como ponto de partida. Não é mágica. É bom senso empacotado com um nome novo.

A Ironia

Aqui está a parte engraçada: o SDD de 2025 é basicamente o que engenheiros de software disciplinados fazem há décadas. A diferença é que agora:

1. A especificação pode ser em linguagem natural (porque LLMs entendem)

2. A execução pode ser automatizada (porque LLMs podem gerar código)

3. A validação pode ser contínua (porque podemos comparar output com spec)

Mas o princípio central, definir intenção antes de implementação, é o mesmo de sempre.

Como disse Brad Shimmin, analista do Futurum Group: "Estamos pegando ideias antigas (lembra de literate programming?) e usando-as para melhor definir nossa 'intenção' ao guiar workflows de agentes."

O Que Eu Já Fazia (E Você Provavelmente Também)

Se você já:

• Escreveu um documento de requisitos antes de codar

• Definiu schemas de API antes de implementar endpoints

• Criou interfaces/contratos antes das classes concretas

• Usou TypeScript types como especificação

• Trabalhou com TDD (Test-Driven Development)

• Usou BDD (Behaviour-Driven Development)

...você já estava fazendo uma forma de SDD. Só não tinha o hype de IA pra valorizar isso.

O Que Realmente Importa

Não me entenda mal: as ferramentas novas são úteis. Ter um Kiro ou Spec-Kit que integra especificações com agentes de IA é legal. Poder gerar código determinístico a partir de specs bem definidas é poderoso.

Mas não vamos fingir que inventamos algo novo.

O que a era da IA fez foi ressignificar práticas que estavam meio esquecidas. Muita gente abandonou especificações formais porque "agile quer working software over comprehensive documentation". Só que o Manifesto Ágil nunca disse pra jogar clareza fora. Ele disse pra priorizar software funcionando, não pra trabalhar no escuro.

SDD, como bem coloca um artigo sobre o tema, não conflita com agilidade. Specs não são o objetivo final; são o andaime que ajuda a estabilizar a intenção através das iterações.

Conclusão: Celebre a Redescoberta, Mas Conheça a História

Se você está entrando agora no mundo do SDD por causa da IA, ótimo! Bem-vindo ao clube. Vai te ajudar muito.

Mas se alguém vier te dizer que isso é revolucionário e inovador, você pode gentilmente apontar que:

• 1969: Hoare publica "An Axiomatic Basis for Computer Programming"

• 1976: Dijkstra lança "A Discipline of Programming"

• 1986: Meyer formaliza Design by Contract

• 2009: JSON Schema é criado

• 2010: Swagger começa a ser desenvolvido

• 2015: OpenAPI Initiative é fundada

• 2017: Artigo sobre Schema-Driven Development na Medium

• 2021: 99designs escreve sobre SDD para APIs

• 2025: Todo mundo "descobre" SDD por causa da IA

São mais de 50 anos de evolução, não uma invenção de 2025.

O melhor código é aquele que nasce de intenções claras. Isso era verdade antes da IA, é verdade com IA, e vai continuar sendo verdade depois que a próxima onda de hype passar.

Agora, se me dão licença, vou voltar a escrever minhas specs como sempre fiz. Só que agora com uma IA pra me ajudar a executar mais rápido.

P.S.: Se você está lendo isso e pensando "mas eu nunca ouvi falar de SDD antes de 2025", tudo bem. O importante não é ter conhecido antes, é aplicar bem agora. Só não deixe o marketing te convencer de que é algo sem precedentes. A história da computação é rica demais pra ser ignorada.

Referências e Leitura Adicional:

• Meyer, B. "Design by Contract" (1986)

• Hoare, C.A.R. "An Axiomatic Basis for Computer Programming" (1969)

• OpenAPI Specification - openapis.org

• "Schema-driven development in 2021" - 99designs Engineering Blog

• "Spec-Driven Development: When Architecture Becomes Executable" - InfoQ (2026)

• "From Vibe Coding to Spec-Driven Development" - Tessl.io (2026)