Spec-driven development virou mercado. Em pouco tempo, "fazer SDD" deixou de ser prática de nicho e virou etiqueta disputada por ferramentas que resolvem problemas bem diferentes: um IDE que verifica requisito antes de existir código, um toolkit enxuto com constituição de projeto, um framework que orquestra doze agentes, uma linha brownfield que rastreia cada delta sobre o legado. O risco novo não é ignorar SDD — é escolher a ferramenta antes de saber que tipo de maturidade a sua engenharia precisa.
Adotar "SDD" sem escolher a família certa é decisão adiada, não tomada. O ponto de partida do movimento já foi tratado aqui antes — a IA não programa melhor porque recebeu um prompt maior, e sim quando recebe especificação estruturada como fonte de verdade. Este post assume esse consenso e vai para a pergunta seguinte, que é estratégica antes de ser técnica: qual família encaixa na base que você tem, na governança que você exige e na maturidade que a sua equipe realmente opera hoje. O mecanismo de cada uma importa — mas como consequência dessa pergunta, não no lugar dela.
Principais pontos
- SDD virou mercado, e o risco mudou de lugar — não é mais ignorar spec-driven, é escolher a ferramenta antes de saber que maturidade a engenharia precisa.
- O eixo greenfield vs brownfield decide cedo, porque framework otimizado pra projeto novo trava numa base legada enquanto a linha brownfield nasce pra rastrear mudança sobre o que já existe.
- Mais automação e mais agentes custam mais coordenação, então um framework com doze agentes gera trilha de auditoria rica, mas cada handoff é um ponto de falha e um custo de token.
- Notação estruturada reduz ambiguidade e não substitui julgamento, porque escrever requisito como enunciado testável caça contradição antes de codar, mas a especificação continua escrita por gente que pode especificar a coisa errada com precisão.
- A ferramenta não instala a disciplina, já que um framework que exige processo não conjura processo onde ele não existe — ele multiplica o que já está lá, bom ou ruim.
Pra quem vai contratar ou sustentar desenvolvimento assistido por IA, a pergunta operacional não é "qual framework tem mais estrelas no GitHub". É "esse modelo de trabalho se sustenta na minha base de código, com a minha equipe, no meu apetite de governança?". É exatamente esse tipo de avaliação — encaixar o método ao contexto, não o contexto ao método — que parceiros como a Vertis Tech trazem pra mesa quando um cliente quer adotar desenvolvimento spec-driven sem virar refém de uma ferramenta.
As quatro famílias, e o mecanismo de cada uma
Não existe uma taxonomia oficial, mas as abordagens de referência hoje se organizam bem em quatro perfis. Vale conhecer cada um pelo que ele faz por dentro — a mecânica da especificação, o artefato que produz e onde entra o humano — porque é esse desenho, e não a lista de features, que determina se encaixa.
O IDE agêntico com verificação estruturada (Kiro)
Kiro é um ambiente de desenvolvimento completo, construído sobre a base de código aberto do VS Code, que embute o fluxo spec-driven no editor. A documentação da ferramenta descreve o mesmo padrão: para feature complexa, você formaliza a intenção em três artefatos versionados — requirements.md, design.md e tasks.md — antes de o agente saltar pro código; para exploração rápida, existe um modo mais solto. A separação já é uma tese: nem todo trabalho merece o peso da spec, e reconhecer isso é parte do método.
O que dá caráter à abordagem é a notação EARS (Easy Approach to Requirements Syntax, nascida na engenharia da Rolls-Royce). Em vez de prosa livre, cada requisito tende a caber num de poucos templates fixos: o ubíquo ("O SISTEMA DEVE..."), o dirigido a evento ("QUANDO [gatilho] O SISTEMA DEVE..."), o dirigido a estado ("ENQUANTO [condição] O SISTEMA DEVE...") e o de comportamento indesejado ("SE [condição] ENTÃO O SISTEMA DEVE..."). A restrição sintática é o recurso, não o incômodo: um requisito que não cabe em nenhum template costuma ser um requisito ambíguo disfarçado de frase bonita.
Requisito escrito como enunciado estruturado é mais fácil de transformar em critério de aceite e de teste — e essa é a direção que o SDD com notação formal aponta. Convém a honestidade, porém: reduzir ambiguidade no requisito não é o mesmo que garantir correção do sistema. Notação estruturada fecha a porta pra uma classe de erro — a contradição e o vão na especificação; não fecha a porta pra você ter especificado, com todo o rigor, a funcionalidade errada.
Encaixa quando: o projeto tolera adotar um IDE inteiro, a equipe valoriza requisitos testáveis e o domínio tem regras que compensam formalizar. Cobra em troca: curva de adoção de ambiente novo e disciplina de escrever EARS de verdade.
O toolkit enxuto com constituição de projeto (GitHub Spec Kit)
Spec Kit é o oposto em peso: não é IDE, é um conjunto de comandos de barra que guia um único assistente de IA através de fases explícitas — /specify, /plan, /tasks, /implement — com revisão humana obrigatória entre elas. O próprio projeto se descreve como toolkit open source pra sair do "vibe coding" e tratar a especificação como artefato central, com fases e tarefas executadas de forma ordenada. Cada comando consome o artefato do anterior e produz o próximo, sempre em markdown versionável, e é agnóstico de assistente.
O conceito que o distingue é a constituição do projeto (constitution.md): um documento de princípios inegociáveis que não é regenerado a cada feature e se aplica como restrição a toda mudança — o equivalente a um conjunto de invariantes de arquitetura no formato "não faça X porque Y, faça Z". Enquanto a spec de uma feature é efêmera, a constituição é o estado persistente que impede o agente de driftar de decisão fundamental a cada nova sessão.
O gate de aprovação humana por fase é a espinha de governança aqui: cada comando para e espera revisão antes de seguir, o que mantém o julgamento no ponto de transição em vez de só no fim. É leve e rápido pra iterar feature, mas assume maturidade — trata a spec como artefato de mudança, não como documentação viva do sistema. É otimizado pra projeto novo; numa base legada, exige engenharia reversa do comportamento existente antes de qualquer comando fazer sentido.
Encaixa quando: equipe madura, projeto novo, apetite por controle humano fase a fase sem carregar peso de framework. Cobra em troca: pressupõe boas práticas já instaladas — ele não as cria.
O framework que simula um time inteiro (BMAD)
BMAD (Breakthrough Method of Agile AI-Driven Development) leva a orquestração ao extremo: coordena mais de doze agentes especializados que cobrem papéis distintos do ciclo — analista, gestão de produto, arquitetura, UX, scrum master, desenvolvimento, QA. É software livre sob licença MIT e um dos frameworks multiagente de maior tração da categoria.
O desenho técnico que o diferencia são duas fases encadeadas. Na primeira, agêntica de planejamento, agentes de análise, produto e arquitetura produzem um PRD e um documento de arquitetura completos. Na segunda, um agente scrum master "fatia" (sharding) esses documentos em arquivos de história que carregam contexto embutido — cada história leva consigo o pedaço de arquitetura e de requisito que o agente de desenvolvimento precisa. Isso ataca o problema clássico de janela de contexto: o dev não perde o fio porque o contexto viaja junto com a tarefa, em vez de ficar preso na conversa anterior. Cada handoff entre agentes é um artefato versionado; a trilha de auditoria vem de fábrica.
O trade-off é direto e a própria comunidade o nomeia: BMAD é um multiplicador de processo, não um criador de processo. Doze personas sequenciais significam mais pontos de falha entre handoffs, mais custo de coordenação e mais consumo de token — "o pipeline é tão bom quanto o handoff mais fraco". Onde há estrutura e papéis definidos, ele brilha e produz entregável pronto pra auditoria. Onde a equipe não tem processo, ele não conjura um — só expõe a ausência com mais cerimônia.
Encaixa quando: múltiplas frentes, necessidade real de trilha de auditoria por papel, organização que já opera com papéis definidos. Cobra em troca: coordenação, custo de token e a exigência de que o processo exista antes.
A linha brownfield com deltas auditáveis (OpenSpec)
OpenSpec parte da premissa que os outros três tratam como caso secundário: e a base que já existe? Ele é brownfield-first, desenhado pra times onde a gestão de mudança exige documentação explícita e auditável antes de qualquer implementação. A estrutura separa dois planos: as specs, que descrevem o comportamento atual do sistema, e as propostas de mudança, que descrevem o que se pretende alterar antes de codar.
O mecanismo central são os marcadores de delta: dentro de uma proposta, cada requisito é categorizado como ADICIONADO, MODIFICADO ou REMOVIDO em relação à spec vigente. Isso impede o agente de "alucinar" requisito novo sobre funcionalidade que já roda — o modelo é forçado a declarar o que muda relativo ao estado existente, não a reescrever o mundo do zero. Depois da implementação e da revisão, a proposta é arquivada e a spec base é atualizada, de modo que a documentação de nível de sistema compõe com o tempo em vez de virar artefato descartável por feature.
O preço é uma disciplina específica: fluxo de agente único, com reconciliação manual pós-implementação quando o código diverge da spec. Nenhuma das quatro famílias, aliás, automatiza totalmente essa reconciliação de drift — a revisão humana continua obrigatória em todas.
Encaixa quando: sistema legado em produção, necessidade de rastrear cada mudança contra o que já existe, cultura de mudança auditável. Cobra em troca: disciplina de reconciliar deriva à mão.
Os eixos de decisão que valem mais que a marca
Depois de conhecer o mecanismo dos quatro perfis, a escolha fica melhor se você parar de comparar produtos e passar a posicionar o seu projeto em cinco eixos. A família certa é consequência de onde você cai neles.
Greenfield vs brownfield
É o primeiro filtro porque descarta opções cedo. Framework otimizado pra projeto novo trata a base existente como território a ser reconstruído; ferramenta brownfield-first nasce pra rastrear delta sobre o que já roda. Se a maior parte do seu trabalho é evoluir sistema em produção, começar por uma ferramenta greenfield vira remendo desde o primeiro dia — você paga o custo de reconstruir contexto que já existe só pra caber no modelo mental da ferramenta.
IDE vs toolkit vs framework
É uma decisão de superfície de adoção. Um IDE pede que a equipe migre de ambiente inteiro. Um toolkit se encaixa no fluxo que já existe e guia um assistente. Um framework de orquestração reorganiza como o trabalho é dividido entre papéis. Quanto mais a ferramenta pede que você mude, mais retorno ela precisa entregar pra justificar a mudança — e mais gente precisa comprar a ideia junto.
Automação vs controle humano
Mais agentes automatizando mais etapas parece progresso, mas cada ponto automatizado é um ponto que alguém precisa conseguir auditar depois. O gate de aprovação humana por fase existe justamente pra manter o julgamento no laço onde ele importa. A pergunta não é "quanto dá pra automatizar", é "quais decisões você não quer que uma cadeia de agentes tome sem revisão" — e onde, na cadeia, você consegue de fato parar e inspecionar o artefato.
Peso de artefato vs velocidade
Artefato versionado por handoff é ouro numa auditoria e areia num sprint apertado. Time que precisa de rastreabilidade por papel aceita a cerimônia; time que precisa iterar rápido em feature sente o peso de gerar e revisar documento a cada passo. Não existe resposta universal — existe o seu ponto de operação, e ele muda conforme o risco do que você está construindo.
Verificação estruturada vs prosa
Notação como EARS transforma requisito em enunciado testável e caça contradição antes do código, ao custo de uma sintaxe que a equipe precisa aprender e sustentar. Prosa estruturada é mais leve de escrever e mais fácil de todo mundo ler, mas deixa ambiguidade que só aparece na execução — o bug que nasce de duas pessoas lendo a mesma frase de formas diferentes. Domínio com regra crítica compensa o rigor; domínio que muda rápido às vezes prefere a legibilidade.
O alerta que nenhuma ferramenta imprime na caixa
O risco silencioso de todo esse mercado é acreditar que adotar a ferramenta instala a disciplina. Não instala. BMAD é explícito ao se chamar multiplicador, não criador, de processo — e a lógica vale pra todos. Spec Kit assume práticas maduras; Kiro exige que alguém escreva EARS de verdade; OpenSpec depende de disciplina de reconciliação. A especificação continua sendo escrita por pessoas, e uma spec ruim escrita com rigor formal ainda é uma spec ruim — só que agora com aparência de autoridade.
É por isso que a escolha da família importa menos do que a maturidade de quem a opera. A ferramenta certa no time errado produz cerimônia cara. A ferramenta mais simples no time disciplinado produz software mantível. O padrão que atravessa todos os frameworks sérios é o mesmo: especificação como fonte de verdade, aprovação humana em pontos críticos e trilha de auditoria do que foi decidido — e esses três não vêm no instalador, vêm da operação.
O que vem depois do SDD: engenharia de contexto
Escolher a família de SDD resolve o que deve ser construído. A camada que está amadurecendo por baixo dela resolve outra pergunta: o que cada agente precisa saber, em que momento, com quais ferramentas e sob quais limites. A Anthropic tem chamado isso de engenharia de contexto — a evolução natural da engenharia de prompt. Não se trata mais de escrever o prompt perfeito, e sim de decidir qual contexto, quais dados, qual memória, qual histórico e quais ferramentas entram no estado do agente em cada etapa.
O encaixe com SDD é direto: as quatro famílias organizam a especificação; a engenharia de contexto organiza a execução assistida por IA em torno dela. As perguntas operacionais sobem de nível:
- Qual contexto entra e qual fica de fora de cada etapa — porque contexto demais dilui e contexto de menos alucina.
- Qual subagente recebe qual parte do trabalho, com contexto próprio isolado, pra que uma tarefa lateral não contamine o fio principal.
- Que ferramenta cada agente pode usar e com qual permissão — o mesmo princípio de menor privilégio que vale pra pessoa vale pra agente.
- Onde fica o gate humano e como auditar, depois, o que foi decidido e executado.
Subagentes especializados — cada um com contexto e permissões próprios, capazes de isolar tarefas laterais sem perder o fio principal — são a materialização dessa ideia. Em projeto simples, isso parece detalhe. Em projeto com legado, requisito de segurança e múltiplos agentes, é a diferença entre automação útil e cerimônia cara. É aí que o SDD deixa de ser "ter spec" e vira desenho de contexto e permissão por tipo de trabalho.
Como a Vertis Tech ajuda em spec-driven development
A Vertis Tech desenvolve software sob medida com foco em CRM, automação e IA aplicada, e opera desenvolvimento assistido por IA na prática — não como teoria de blog. Cada projeto é dimensionado conforme o tipo de base (nova ou legada), o apetite de governança do cliente, a criticidade do domínio e a maturidade de processo da equipe. A depender do escopo, a condução pode contemplar:
- Diagnóstico de qual família de SDD encaixa no contexto, pesando greenfield vs brownfield e peso de artefato vs velocidade antes de comprometer a equipe com uma ferramenta.
- Especificação como fonte de verdade com aprovação humana em pontos críticos, modelo que já roda internamente com Claude Agent SDK e MCP tools nos próprios sistemas da casa.
- Engenharia de contexto e permissão por tipo de trabalho, definindo o que cada agente sabe, qual ferramenta pode usar e onde entra o gate humano.
- Auditoria append-only do que os agentes decidem e executam, pra que cada ação assistida por IA fique rastreável — a mesma disciplina de trilha que os frameworks sérios prometem.
- Sustentação no Dia 2, porque método spec-first sem quem revise, reconcilie deriva e cuide da operação vira cerimônia abandonada em três meses.
Perguntas frequentes
Preciso escolher uma única ferramenta de SDD pra sempre?
Não. As famílias resolvem problemas diferentes e não é raro um brownfield legado conviver com um fluxo mais leve em projetos novos paralelos. O que não muda entre elas é o princípio: especificação estruturada, aprovação humana onde importa, trilha auditável. A ferramenta é substituível; o padrão de disciplina, não.
Verificação estruturada como a do EARS elimina bug?
Ela ataca uma classe específica de problema — ambiguidade e contradição no requisito — ao forçar cada regra a caber num template testável, o que torna o requisito mais fácil de virar critério de aceite. Mas reduzir ambiguidade no requisito não é garantir correção do sistema, e não protege contra especificar a funcionalidade errada com precisão. É uma camada forte de defesa, não um selo de garantia.
O que o "sharding" do BMAD resolve na prática?
Ele ataca o problema de janela de contexto. Em vez de deixar toda a arquitetura e todos os requisitos num chat que o agente vai perdendo, o scrum master fatia o plano em arquivos de história que carregam o contexto embutido — cada tarefa chega ao agente de desenvolvimento já com o pedaço de spec que ela precisa. O custo é a cerimônia de gerar e versionar esses artefatos a cada handoff.
Onde entra "engenharia de contexto" nessa história?
O SDD organiza a especificação; a engenharia de contexto organiza o que cada agente sabe, quando, com quais ferramentas e sob quais limites. É a camada que decide qual contexto entra em cada etapa, qual subagente recebe qual parte e onde fica o gate humano. Em projeto com legado, segurança e múltiplos agentes, é o que separa automação útil de cerimônia cara.
Adotar a ferramenta resolve a bagunça do meu desenvolvimento com IA?
A ferramenta ajuda, mas não substitui a disciplina. Um framework spec-driven multiplica o processo que já existe — bom ou ruim. Sem especificação bem escrita, revisão humana e reconciliação de deriva, o resultado é cerimônia cara em vez de software mantível. A disciplina vem da operação, não do instalador.
Escolher entre as famílias de spec-driven development é menos sobre qual tem a demo mais impressionante e mais sobre qual encaixa no seu tipo de base, no seu apetite de governança e na maturidade da sua equipe. A boa notícia é que o princípio comum a todas — spec como fonte de verdade, humano no laço, auditoria do que foi decidido — vale mesmo antes de você fechar a ferramenta, e vale ainda mais quando você sobe da spec pra engenharia de contexto que a executa. A má notícia é que nenhuma delas instala esse princípio por você.
