SSD ou SDD? O termo certo é spec-driven development (e o que pesquisar para achar material)

Você digita SSD esperando achar metodologia e o buscador te entrega uma prateleira de discos 😀

A culpa não é sua nem do algoritmo: é de uma letra trocada

SSD é a sigla de Solid State Drive, traduzida como unidade de estado sólido: um dispositivo de armazenamento com memórias flash NAND, sem partes móveis

O método de desenvolvimento que você está procurando se chama SDD, de spec-driven development

O que destrava a sua pesquisa é o vocabulário certo: os sinônimos, o nome em português e os nomes próprios que levam a material real

Bora organizar isso?

Por que a busca por SSD devolve hardware (e como corrigir a consulta)

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O sintoma:

Você pesquisa a sigla e a página vem cheia de armazenamento, memória flash e comparativo de disco

Zero metodologia

A causa:

SSD é sigla consagrada de Solid State Drive há muito tempo, num mercado gigante de hardware

Quando uma sigla tem um sentido dominante assim, o buscador resolve a ambiguidade pelo lado mais provável

E o lado mais provável, estatisticamente, é o disco

Não adianta brigar com isso, adianta desviar

A solução:

Troque a sigla pelo termo por extenso: spec-driven development

Se quiser usar sigla, use SDD, que é a sigla correta do método

Como prevenir da próxima vez:

Sempre que uma sigla tiver homônimo de hardware, escreva o termo por extenso na primeira busca

É mais lento de digitar e infinitamente mais rápido de achar 🙂

O que é spec-driven development, em uma definição

Spec-driven development é a metodologia em que uma especificação detalhada é criada e acordada antes de o desenvolvimento começar

Essa especificação vira a fonte única de verdade sobre o que construir e como construir

É isso, sem mistério e sem prompt mágico

O ponto que faz o termo aparecer tanto agora é o contexto: a comunidade de IA discute o SDD como resposta ao vibe coding, aquele processo não estruturado de conversar com um LLM e torcer pra ele acertar a intenção

Por isso os dois termos vivem grudados nas buscas, e vale entender quando usar cada abordagem antes de escolher lado

O nome do tema em português usado pela documentação da IBM é desenvolvimento orientado por especificações

Guarda esse, ele é útil pra buscar conteúdo em PT-BR

Mapa de termos: o que digitar para achar material sobre SDD

Se liga nessa tabela, ela é o coração do post

Repara que a última linha existe justamente pra você riscar ela da sua lista

Nomes próprios que funcionam como termo de busca

Termo genérico traz definição

Nome próprio traz material de verdade: repositório, documentação, comando pra rodar

Então anota esses aqui

github/spec-kit:

O spec-kit é um toolkit open source mantido pelo GitHub, criado para spec-driven development com agentes de código

O fluxo padrão dele é Spec → Plan → Tasks → Implement

Esse fluxo, sozinho, já é um ótimo termo de busca: ele aparece em praticamente todo material sério sobre o assunto

Os slash commands usam o prefixo speckit:

• /speckit.constitution
• /speckit.specify
• /speckit.clarify (opcional)
• /speckit.plan
• /speckit.checklist (opcional)
• /speckit.tasks
• /speckit.analyze (opcional)
• /speckit.implement

A instalação global do CLI é feita com uv:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

E o CLI tem três comandos que valem decorar: specify init inicializa o projeto, specify --version mostra a versão e specify check verifica os requisitos do sistema

Uma dica de bastidor: rode o specify check ANTES de sair criando projeto, ele existe exatamente pra te avisar do que falta na máquina

Na inicialização dá pra escolher o agente de código pela flag --ai e o tipo de script pela flag --script (sh ou ps)

specify init meu-projeto --ai claude --script sh

Ao inicializar, o Spec Kit cria a pasta .specify/ com templates, scripts auxiliares e a memória do projeto (incluindo a constitution)

O GitHub anunciou o Spec Kit como toolkit open source para spec-driven development com agentes como GitHub Copilot, Claude Code e Gemini CLI

Tome cuidado com um detalhe aqui, porque é onde muito tutorial confunde a galera: no caminho específico do GitHub Copilot, o Spec Kit também cria .github/prompts/ (que viram slash commands no Copilot Chat) e .github/copilot-instructions.md

Isso é do caminho do Copilot

Não saia procurando essa pasta em outro agente achando que quebrou algo

Kiro:

Kiro é o IDE agêntico da AWS construído em torno de specs

Ele entrou em disponibilidade geral em 17 de novembro de 2025, com CLI e recursos de time

O vocabulário do Kiro é bem específico e ótimo pra busca: uma spec ali é composta por três arquivos

• requirements.md: histórias de usuário e critérios de aceite
• design.md: arquitetura técnica e diagramas
• tasks.md: plano de implementação em tarefas rastreáveis

Se você pesquisar por esses três nomes juntos, cai em material de SDD na hora

EARS:

O requirements.md do Kiro usa a notação EARS, no padrão WHEN <condição> THE SYSTEM SHALL <comportamento esperado>

E aqui vem a parte que quase ninguém conta: EARS não nasceu com IA

EARS significa Easy Approach to Requirements Syntax, foi desenvolvida por Alistair Mavin e colegas na Rolls-Royce plc e publicada na IEEE International Requirements Engineering Conference (RE’09) em 2009

Engenharia de requisitos de avião, sério

A estrutura geral de um requisito é WHILE <pré-condições opcionais>, WHEN <gatilho opcional>, the <nome do sistema> SHALL <resposta do sistema>, com cinco padrões de requisito: ubiquitous, event-driven, unwanted behaviors, state-driven e optional features

Buscar por "EARS requirements" te leva a material MUITO mais antigo e mais denso que o hype atual

No Claude Code: CLAUDE.md, /init, /memory e plan mode

Se o seu agente é o Claude Code, esses quatro nomes formam o vocabulário adjacente que você vai encontrar em toda discussão de SDD

Arquivos CLAUDE.md dão instruções persistentes ao projeto e são lidos pelo Claude no início de cada sessão

O comando /init gera um CLAUDE.md inicial e o /memory serve pra refinar ele

Já o plan mode permite que o Claude explore e proponha mudanças sem editar os arquivos de imediato, pra você revisar o plano antes da aplicação

É o espírito do SDD ali: acordar o plano primeiro, depois deixar o código acontecer

SDD, TDD e BDD: siglas parecidas, níveis diferentes

Três siglas de três letras terminando em DD

Dá ruim na busca, dá ruim na conversa

E fica explícito: o SDD não substitui TDD nem BDD

Ele opera em um nível acima

SDD define intenção e planeja a construção, enquanto o TDD valida implementação e o BDD descreve comportamento

Ou seja, não é escolha, é camada diferente

Conclusão: o vocabulário certo e o próximo passo

Recapitulando o que resolve o seu problema de busca:

• troque SSD por SDD, porque SSD é Solid State Drive, hardware de armazenamento
• prefira o termo por extenso: spec-driven development
• se saturar, tente o sinônimo specification-driven development
• em PT-BR, busque por desenvolvimento orientado por especificações
• pra pegar o debate, jogue vibe coding junto
• e vá direto nos nomes próprios: github/spec-kit, Kiro e EARS

O próximo passo prático é bem simples: abre o repositório github/spec-kit e lê o fluxo Spec → Plan → Tasks → Implement com calma

Depois leva esse mesmo fluxo como termo de busca pras comunidades, sempre escrito por extenso

É ali que a conversa boa acontece, e agora você sabe como chegar nela 😀

até o próximo post!