OpenSpec vs. Spec Kit vs. Superpowers: ferramentas de SDD comparadas

Toda vez que posto sobre o meu setup de spec-driven development, voltam as mesmas perguntas. Como isso se compara ao OpenSpec? Ao Spec Kit? Ao Superpowers? Não é só AGENTS.md com mais burocracia? Perguntas justas, e merecem uma resposta direta em vez de um pitch.

Vou responder a partir de produção, não de uma matriz de features. Eu entreguei uma fintech cripto de 13 apps em 70 dias, sozinho, com agentes de IA movimentando dinheiro de verdade. O que decidiu em qual ferramenta eu podia confiar nunca foi a lista de features. Foi uma pergunta só: quando o agente me entrega um rascunho que parece pronto, ele tem permissão para rodar? Porque o rascunho que parece pronto foi o que mais me custou caro.

Então aqui está o mapa honesto. Cinco jeitos de dar a um agente de IA a intenção que ele não tem sozinho, ordenados mais ou menos por quanto processo cada um impõe. Um deles é meu (pi-sdd-kit). Ele vem por último, para você julgá-lo contra os outros, e vou dizer claramente onde ele é a escolha errada.

Se o método em si é novidade para você, comece por O que é spec-driven development?. Este texto parte do princípio de que você já comprou o porquê e está escolhendo a ferramenta.

Todas resolvem o mesmo problema

Um agente de IA vive num eterno presente. Toda sessão começa do zero. Ele não lembra da restrição que você adicionou às 22h, do edge case que você decidiu deixar fora do escopo, do motivo de ter escolhido Postgres em vez de SQLite. Então ele reinventa essas decisões, de um jeito diferente, a cada execução. E, se deixar, ele corre direto para o código antes de vocês concordarem sobre o que o código deveria fazer.

Você sente isso como o rascunho confiante. Você descreve a feature, o agente escreve sessenta linhas, a demo roda, o terminal fica verde. Parece pronto. Aí a produção encontra o que o rascunho deixou de fora: o timeout que você nunca especificou, o retry que cobra o cliente duas vezes, o registro gravado pela metade. O agente escreveu o caminho feliz. Tudo o que só aparece quando o código encontra algo real foi pulado, em silêncio, e ele fez isso sem mudar de expressão.

Esse é o problema inteiro. Um defeito em código gerado por IA não é um bug no código. É uma lacuna na intenção que você nunca escreveu. Expliquei o mecanismo em Spec-driven development vs. vibe coding. Cada ferramenta abaixo é uma resposta à mesma pergunta: onde a intenção mora, e quanto você é obrigado a escrevê-la antes de o agente rodar?

A lacuna já não é anedota

+98%

mais pull requests com IArelatório DORA 2025

+243%

mais incidentes por pull requesto throughput não veio de graça

31%

mais PRs mergeados sem nenhum review humanosaída confiante, ninguém olha duas vezes

As ferramentas diferem num eixo mais do que em qualquer outro: quanto processo elas impõem. De nenhum a muito. Esse é o espectro.

1. Memória simples: AGENTS.md e mais nada

A opção sem instalação. Você mantém de dois a quatro arquivos markdown pequenos no repositório (AGENTS.md, ou CLAUDE.md, um conventions.md, um decisions.md) com as regras duráveis, a stack e as escolhas que não podem mudar pelo caminho. Em toda sessão, o agente lê esses arquivos. Você atualiza à mão.

Isso vale mais do que a maioria das pessoas acha. Alguém comentou num post meu descrevendo exatamente isso: 2 a 3 docs curtos por projeto, um limite rígido de 5kb para nunca estourar a context window, enxugados à mão depois de cada tarefa grande. Numa base de código com menos de 5.000 linhas, onde você refatora sem dó, isso realmente basta. Não adicione ferramenta nenhuma.

Onde quebra: não há enforcement. Os docs são memória, não um workflow. Nada impede o agente de ler um arquivo que parece plausível e codar a coisa errada. Não há spec por feature, nem gate, nem estrutura para “é isto que esta mudança específica deve fazer”. É um ótimo piso. Não é um método.

2. OpenSpec: uma camada leve de spec, fluida de propósito

O OpenSpec (@fission-ai/openspec, MIT) se diz o framework de spec mais amado, e faz jus ao slogan. Ele adiciona uma camada fina de spec sobre o agente que você já usa, e hoje suporta mais de 30. Você instala com npm ou Homebrew, roda openspec init e depois conversa com o assistente por slash commands: /opsx:explore para pensar uma ideia, /opsx:propose para transformá-la numa mudança, /opsx:apply para implementar, /opsx:archive para incorporar o resultado de volta às specs. Um perfil expandido adiciona etapas como /opsx:verify e /opsx:continue quando você quer mais estrutura.

O modelo mental são duas pastas. openspec/specs/ é a fonte da verdade atual. openspec/changes/<name>/ é uma mudança proposta, cada uma na sua pasta, com um proposal.md, specs/, design.md e tasks.md. Vocês concordam sobre a mudança, o agente implementa, depois ela é arquivada e as specs absorvem o que foi para produção. As versões mais novas trazem os Stores (em beta): as mesmas specs e mudanças, guardadas num repositório de planejamento próprio, para que uma feature que cai em três repositórios ainda tenha um plano só.

A escolha que o define está na própria documentação: “update any artifact anytime, no rigid phase gates.” O OpenSpec é fluido de propósito. Foi feito para brownfield e não obriga você a parar e aprovar formalmente cada etapa. Isso é uma feature. É também exatamente o que o separa do que eu construí.

Onde se encaixa: você quer spec como fonte da verdade e propostas de mudança limpas, em qualquer agente que use, sem cerimônia. Onde talvez não: se “sem gates rígidos entre fases” é justamente a disciplina que você esperava que a ferramenta impusesse, o OpenSpec deliberadamente não impõe.

3. Spec Kit: o pipeline estruturado do GitHub

O Spec Kit (GitHub, MIT, cerca de 140k estrelas) é a ponta estruturada do spec-first, e chegou à 1.0 em agosto. Você instala a CLI specify com uv (precisa de Python 3.11 ou mais novo), roda specify init com a integração do seu agente e depois conduz o agente por uma sequência fixa. /speckit-constitution roda uma vez por projeto e escreve os princípios que toda feature precisa respeitar. Depois, por feature: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement. Etapas opcionais entram quando você quer checagens extras: /speckit-clarify antes do plano, /speckit-analyze para consistência entre os artefatos, /speckit-checklist para o que na prática são testes unitários para o texto da spec.

A etapa que entrou em junho é a interessante. /speckit-converge compara o que foi construído com a spec, o plano e as tasks, e adiciona o que falta como tasks novas. Você repete implement e converge até ele dizer que convergiu. É o Spec Kit admitindo o que todo mundo aprendeu do jeito difícil: o agente diz que terminou antes de terminar.

Duas coisas mudaram desde a primeira onda de críticas. A branch por spec agora é opcional: a feature ativa fica em .specify/feature.json, e as branches numeradas por feature vêm de uma extensão de git que você adiciona se quiser. E o Spec Kit deixou de ser só SDD. Correção de bug (assess, fix, test) e avaliação de ideia (uma decisão de seguir ou matar antes de construir qualquer coisa) vêm como extensões.

Onde se encaixa: você quer um pipeline documentado que roda do mesmo jeito em toda feature, com uma constitution que toda feature respeita. Equipes gostam disso, porque toda mudança gera os mesmos artefatos nos mesmos lugares. Onde talvez não: a verbosidade é real. A reclamação mais comum não mudou: uma mudança em três arquivos enterrada sob centenas de linhas de prosa gerada que alguém precisa revisar. Dá para cortar isso com o preset lean, que vem embutido (specify preset add lean) e reduz cada fase a um arquivo enxuto, mas você precisa escolher usar. E a ordem é rígida, mas a aprovação não. A ferramenta confere que o plano existe. Não confere que um humano leu.

Escrevi um guia completo do Spec Kit se você quer cada comando em detalhe.

4. Superpowers: uma metodologia inteira, não uma ferramenta de spec

O Superpowers (Jesse Vincent e Prime Radiant, MIT, perto de 300k estrelas) é outro bicho. Não é um framework de spec. É uma metodologia completa de desenvolvimento de software, construída como uma biblioteca de skills componíveis que disparam automaticamente, mais as instruções para fazer o agente de fato usá-las.

O workflow cobre o ciclo inteiro: brainstorming (design socrático, apresentado em partes legíveis para aprovação), using-git-worktrees, writing-plans (tarefas de dois a cinco minutos cada, com caminhos de arquivo exatos e passos de verificação), subagent-driven-development (um subagent novo por tarefa, com review de aderência à spec e depois de qualidade de código) ou o mais barato executing-plans (na mesma sessão, com um review da branch inteira no fim), test-driven-development (RED-GREEN-REFACTOR de verdade: ele apaga código escrito antes de um teste), requesting-code-review e finishing-a-development-branch. Roda no Claude Code, onde está no marketplace oficial de plugins da Anthropic, e no Codex, Cursor, Gemini CLI, Copilot CLI, OpenCode e Pi, entre outros. As skills são workflows obrigatórios, não sugestões, e o agente consegue rodar sozinho por algumas horas sem sair do plano.

Então sim, o Superpowers tem uma etapa com cara de spec (o brainstorming produz um design que você aprova). Mas é só um passo dentro de um processo opinativo muito maior, cujo centro de gravidade é TDD e execução por subagents, não o artefato de spec. O design e o plano servem à feature em andamento. Nada os incorpora numa spec de longo prazo do sistema depois que o trabalho vai para produção.

Onde se encaixa: você quer um SDLC agêntico completo e opinativo, com disciplina test-first e subagents em paralelo já embutidos. Onde pode ser demais: se tudo o que você queria era fechar os requisitos antes de o agente codar, o Superpowers traz uma metodologia inteira de brinde.

5. pi-sdd-kit: estreito, opinativo, com gate

Agora o meu, e vou tratá-lo com a mesma honestidade. O pi-sdd-kit (pi install npm:@felipefontoura/pi-sdd-kit) faz uma coisa só: spec-driven development no Pi, como cinco skills que você invoca em ordem. sdd-prd, sdd-spec, sdd-tasks, sdd-exec, sdd-review. Sem biblioteca de brainstorming, sem motor de TDD, sem gerenciador de worktrees. Só o loop de SDD.

Duas coisas sustentam tudo. Primeiro, steering docs como memória durável: product.md, tech-stack.md, conventions.md e principles.md ficam separados de qualquer feature e carregam em toda sessão. O que compensa é a linha do motivo. “Usamos Postgres porque registros de pagamento precisam de ACID” impede o agente de ir atrás do SQLite três sessões depois. Segundo, o arquivo .status é o único gate. Um token por fase: requirements:approved, depois design:approved, depois tasks:approved. Um design.md com cara de pronto no disco não é aprovação. Só o token é. É isso que impede um agente afobado de levar um rascunho direto para o código. Os requisitos são escritos em EARS (WHEN / IF / WHILE / SHALL), então quase não sobra nada para interpretar.

Onde se encaixa: você quer especificamente spec, aprovação e só então build, com um gate humano rígido entre as fases, e está no Pi. Onde não: você não está no Pi, ou acha gates explícitos mais irritantes do que tranquilizadores. É estreito de propósito: disciplina de spec e um gate rígido, sem o volume de artefatos gerados do Spec Kit e sem a fraqueza puramente consultiva do AGENTS.md simples. Esse é o design inteiro.

Spec Kit vs. OpenSpec: mesma aposta, pesos diferentes

O Spec Kit e o OpenSpec concordam na parte que importa. A spec é a fonte da verdade, e o agente trabalha a partir dela. Eles discordam de quanta cerimônia é preciso para chegar lá.

~

OpenSpec

1. 01CLI em Node. openspec init e pronto. Mais de 30 assistentes.
2. 02Uma pasta por mudança: proposal, specs, design, tasks.
3. 03Atualize qualquer artefato a qualquer momento. Sem gates de fase, por design.
4. 04O archive incorpora cada mudança de volta às specs vivas.
5. 05Feito primeiro para bases de código existentes.

|

Spec Kit

1. 01CLI em Python via uv. specify init com uma integração por agente.
2. 02Uma constitution uma vez, depois specify, plan, tasks, implement.
3. 03As fases rodam em ordem, com clarify, analyze e checklist opcionais.
4. 04O converge repete até o código bater com os artefatos.
5. 05Mais Markdown por mudança, e alguém precisa ler.

A pista está nas palavras deles. O README do OpenSpec chama o Spec Kit de completo, mas pesado. O Spec Kit segue na direção contrária, com o converge e um catálogo de extensões: mais estrutura, não menos. Nenhum dos dois está errado. Foram feitos para mudanças de pesos diferentes.

Minha regra: conte as linhas que um revisor precisa ler numa mudança em três arquivos. Se os artefatos de spec forem mais longos que o diff, a ferramenta é pesada demais para aquela mudança. Mudanças pequenas e frequentes numa base existente ficam mais perto do peso do OpenSpec. Um produto novo, com uma equipe que precisa que toda feature responda aos mesmos princípios, é onde a constitution e a sequência fixa do Spec Kit pagam o Markdown extra.

OpenSpec vs. Superpowers: fazem trabalhos diferentes

É a pergunta que mais recebo, e ela está um pouco errada. OpenSpec e Superpowers não competem.

O OpenSpec cuida do quê e do porquê: uma proposta, os requisitos e uma spec que sobrevive à mudança. O Superpowers cuida do como: um plano cortado em tarefas de poucos minutos, testes primeiro, um subagent novo por tarefa, review antes do merge. O OpenSpec não tem opinião sobre escrever testes primeiro. O Superpowers não tem onde guardar o motivo de um requisito existir, seis meses depois de ele ir para produção.

Então escolha pela falha que se repete. Se o agente constrói a coisa errada, ou esquece uma decisão de três sessões atrás, você tem um problema de spec, e isso é OpenSpec. Se o agente constrói a coisa certa mal feita, pula os testes ou se perde do plano depois de uma hora, você tem um problema de execução, e isso é Superpowers. Se você tem os dois problemas, não está escolhendo. Está empilhando.

Usando OpenSpec e Superpowers juntos

Empilhar os dois é o setup mais comum que eu vejo, e funciona quando cada ferramenta fica na sua raia.

Uma mudança, duas ferramentas

Entrada

Uma mudança que vale mais de uma sessão

↓

1. OPENSPECExplorar e propor

   /opsx:explore para pensar, depois /opsx:propose para escrever a proposta, as specs delta, o design e as tasks. Esse é o registro que fica.

   ↓
2. VOCÊLer a proposta

   A etapa que nenhuma das duas impõe. Nada anda até um humano ler a spec e dizer sim.

   ↓
3. SUPERPOWERSPlanejar e construir

   O writing-plans transforma as tasks aprovadas em passos pequenos. Depois test-driven development, um subagent novo por tarefa e review entre as tarefas.

   ↓
4. OPENSPECArquivar

   /opsx:archive incorpora às specs o que de fato foi para produção, para a próxima sessão começar da verdade, e não do plano.

↓

Saída

O OpenSpec lembra o porquê. O Superpowers controla a qualidade. Você decide quando.

Duas regras evitam que elas briguem. Primeiro, uma etapa de design, não duas. O brainstorming do Superpowers e o explore/propose do OpenSpec cobrem o mesmo terreno. Rode os dois e você ganha dois designs que se afastam. Deixe o OpenSpec escrever o design e diga ao Superpowers para planejar a partir da pasta da mudança aprovada. Segundo, escreva o roteamento. Uma seção curta no AGENTS.md ou CLAUDE.md dizendo qual ferramenta é dona de qual fase é o que impede o agente de improvisar a passagem.

Você não precisa ligar isso na mão. O OpenSpec lista schemas da comunidade na documentação, e um deles, o superpowers-bridge, faz essa passagem na camada de prompt e adiciona um artefato de retrospectiva depois que o trabalho vai para produção. Confira a linha de compatibilidade antes de adotar. Em 30 de setembro, o README dele lista OpenSpec 1.4.1 e Superpowers v5.1.0 como base testada, enquanto as versões atuais são 1.14 e 6.4.2. Cola na camada de prompt aguenta diferença de versão melhor do que código. Mas a diferença continua lá.

Aqui está a parte que nenhuma combinação resolve por você. Nenhuma das duas ferramentas segura o agente entre uma proposta com cara de aprovada e o código. O OpenSpec é fluido por design. O Superpowers pede o seu ok na conversa, e um agente afobado, ou você cansado às 23h, deixa passar. Até o schema da comunidade do OpenSpec construído em torno de um review adversarial (anvil) diz isso com todas as letras no catálogo: o OpenSpec só confere se os artefatos existem, então imponha o gate com o seu próprio CI ou hook. Essa lacuna é a razão de o pi-sdd-kit existir. Em qualquer outra stack você fecha do mesmo jeito: um arquivo de status ou um hook que se recusa a rodar o apply até existir um token humano.

E o BMAD e o Kiro?

Os dois aparecem em toda thread, então rapidamente.

O BMAD (v6.12, cerca de 54k estrelas) se define como desenvolvimento ágil orientado por IA. Ele traz perspectivas especializadas de produto, arquitetura, UX, desenvolvimento e testes, e dimensiona o planejamento conforme a mudança: mudanças pequenas vão direto para o build, trabalho complexo ganha brief, especificação e arquitetura antes de qualquer código. É a opção mais carregada de papéis desta lista. Perto do Superpowers em escopo, mas organizado em torno de um time ágil em vez de TDD.

O Kiro é a IDE da AWS com o workflow de spec embutido: requisitos, design e tasks dentro do editor. Escolha se você quer SDD sem montar nada sozinho e não se importa de morar naquele editor.

Visão geral

Ferramentas de spec-driven, comparadas

Ordenado mais ou menos por quanto processo cada uma impõe, com a minha por último. Enforcement é o eixo que de fato decide a escolha.

Ferramenta	Escopo	Enforcement	Melhor para
Memória simples (AGENTS.md)	Só regras duráveis	Nenhum. Manual.	Bases pequenas, solo, disciplinadas
OpenSpec	Camada de spec + propostas de mudança	Fluido. Sem gates de fase, por design.	Spec como verdade em qualquer agente
Spec Kit	Constitution + pipeline em sequência	Fases em ordem, aprovação por convenção	Equipes que querem os mesmos artefatos sempre
Superpowers	Metodologia de SDLC completa	Skills obrigatórias com disparo automático	TDD + subagents, de ponta a ponta
BMAD	Papéis ágeis + planejamento dimensionado	Workflows guiados	Planejamento por papéis em trabalhos maiores
pi-sdd-kit	Só o workflow de SDD	Gate .status rígido por fase	Spec-depois-aprovação estrito no Pi

A bifurcação real: fluido ou com gate

Tire as listas de features e sobra uma decisão fazendo quase todo o trabalho. Quando o agente tem um plano que parece pronto, ele pode começar a codar, ou um humano precisa dar o sinal verde antes?

~

Fluido (OpenSpec, memória simples)

1. 01Atualize qualquer artefato a qualquer momento e siga em frente.
2. 02Pouca cerimônia, iteração rápida, ótimo para brownfield.
3. 03O agente pode agir sobre um plano que parece completo.
4. 04A disciplina mora em você, não na ferramenta.

|

Com gate (pi-sdd-kit, Superpowers)

1. 01Uma fase não avança sem um sinal explícito.
2. 02Mais atrito no começo, menos retrabalho na direção errada.
3. 03Um rascunho com cara de pronto não é permissão para codar.
4. 04A disciplina mora na ferramenta, então sobrevive a uma noite de cansaço.

O Spec Kit fica no meio: a ordem é imposta, a aprovação não. É por isso que “como se compara” não tem resposta única. O OpenSpec tira os gates de propósito porque cerimônia atrasa a iteração. O pi-sdd-kit adiciona um gate rígido de propósito porque eu estava entregando movimentação de dinheiro, e um rascunho errado mas confiante que chega ao código sai caro. Mesmo problema, apostas opostas. O seu contexto decide qual aposta está certa.

O veredito honesto

O eixo honesto não é uma linha única de menos processo para mais. É em torno do que a ferramenta foi construída. Spec-first (OpenSpec, Spec Kit, pi-sdd-kit) coloca a especificação no centro. Harness-first (Superpowers) coloca o processo de execução no centro e trata a spec como uma etapa. Role-first (BMAD) coloca um time ágil simulado no centro. IDE-native (Kiro) coloca o editor no centro. Steering docs (memória simples) ficam por baixo de todas. A questão não é fidelidade a marca. É saber qual problema você realmente tem e adicionar só o processo que esse problema pede.

Se você ainda está decidindo se precisa de disciplina de spec, o estudo de caso de 13 apps em 70 dias é o argumento mais forte que eu tenho. Se você quer o formato de uma boa spec independentemente da ferramenta, Como escrever uma spec é agnóstico de ferramenta de propósito.

FAQ

OpenSpec é melhor que Spec Kit?+

Nenhum é melhor em abstrato. Eles concordam que a spec é a fonte da verdade e discordam no peso. O OpenSpec é uma CLI leve em Node, com uma pasta por mudança, sem gates de fase e com encaixe forte em bases de código existentes. O Spec Kit é uma CLI em Python com uma constitution e uma sequência fixa (specify, plan, tasks, implement, converge) que gera mais artefatos por mudança.

Escolha o OpenSpec quando suas mudanças são pequenas e frequentes e você quer seguir em frente. Escolha o Spec Kit quando uma equipe precisa que toda feature passe pelo mesmo pipeline documentado e consegue bancar a revisão do Markdown extra.

Dá para usar OpenSpec e Superpowers juntos?+

Dá, e é a stack mais comum que eu vejo. O OpenSpec cuida da proposta, das specs e do archive. O Superpowers cuida do planejamento, da implementação com testes primeiro, dos subagents e do review. Use uma etapa de design, não as duas, e escreva no AGENTS.md ou CLAUDE.md qual ferramenta é dona de qual fase.

O schema superpowers-bridge, da comunidade do OpenSpec, faz a passagem por você. Confira antes as versões testadas: em setembro de 2026 ele lista OpenSpec 1.4.1 e Superpowers v5.1.0, bem atrás das versões atuais. E adicione o seu próprio gate de aprovação entre a proposta e o apply, porque nenhuma das duas ferramentas impõe um.

Qual ferramenta de spec-driven development funciona melhor com Claude Code?+

Todas aqui rodam no Claude Code, menos o pi-sdd-kit, que é nativo do Pi. O Superpowers instala pelo marketplace oficial de plugins da Anthropic, o OpenSpec e o Spec Kit instalam seus comandos ou skills no Claude Code no init, e o BMAD tem um plugin para Claude Code. O Claude Code não é a restrição. O seu problema é.

Se o agente esquece decisões, comece pelo OpenSpec. Se ele executa mal, comece pelo Superpowers. Se você quer rodar o loop no Claude Code sem framework nenhum, meu guia de spec-driven development com Claude Code mostra como, só com arquivos.

Qual a diferença entre pi-sdd-kit e OpenSpec?+

O OpenSpec é uma camada de spec leve e agnóstica de agente, fluida de propósito: você atualiza qualquer artefato a qualquer momento, sem gates rígidos entre fases. O pi-sdd-kit é a aposta oposta. É nativo do Pi e impõe um gate de aprovação rígido via .status entre as fases, então o agente não avança de requisitos para design e para código sem um token humano explícito.

Os dois mantêm markdown como fonte da verdade. A diferença real é o enforcement. Escolha o OpenSpec se quer velocidade e flexibilidade em qualquer agente. Escolha o pi-sdd-kit se quer que o gate impeça o agente de sair correndo na sua frente.

Como o pi-sdd-kit se compara ao Superpowers?+

Escopos diferentes, e o Superpowers é excelente. O Superpowers, do Jesse Vincent, é uma metodologia completa de desenvolvimento de software: brainstorming, planejamento, test-driven development, execução por subagents e code review, tudo como skills componíveis que disparam automaticamente em vários agentes, incluindo o Pi.

O pi-sdd-kit faz uma coisa estreita: o loop de spec-driven (prd, spec, tasks, exec, review) com um gate de aprovação rígido, no Pi. Se você quer um SDLC amplo e opinativo com TDD embutido, use o Superpowers. Se quer só a disciplina estrita de spec e depois aprovação, é o pi-sdd-kit. Dá até para rodar a disciplina de SDD dentro de um setup com Superpowers.

Preciso mesmo de uma ferramenta de spec, ou AGENTS.md basta?+

Numa base de código pequena, em que você trabalha sozinho e refatora sem dó, memória simples em AGENTS.md ou CLAUDE.md realmente basta. Mantenha os arquivos pequenos, atualize à mão e não adicione ferramenta.

Você supera a memória simples quando precisa de specs por feature, de um jeito de concordar sobre uma mudança antes de construí-la, ou de um gate imposto para o agente não codar a coisa errada. É aí que OpenSpec, Spec Kit, Superpowers ou pi-sdd-kit começam a se pagar.

Spec-driven development não é só waterfall com outro nome?+

É a objeção mais comum, e está meio certa. Escrever a intenção antes do código é uma ideia antiga. O que é novo é que a spec é contexto executável para um agente não determinístico, não um documento que alguém assina e engaveta. O waterfall escrevia uma spec grande no início e punia mudanças. O SDD escreve uma spec pequena por mudança, mantém como memória viva que o agente lê em toda sessão e espera que ela mude.

O valor nunca foi a cerimônia. É o raciocínio que você é obrigado a fazer antes de o agente codar, registrado num formato a partir do qual o agente consegue executar. Se sua spec é um doc que ninguém lê, você construiu a versão waterfall. Se é o arquivo a partir do qual o agente regenera, você construiu a útil.

As ferramentas não estão realmente disputando o mesmo trabalho. São quantidades diferentes de processo acopladas à mesma ideia: escreva a intenção antes de o agente rodar, porque o agente não tem memória dela. Escolha a quantidade de processo que combina com o custo de errar.