SDD, Spec-Driven Development, funciona quando a especificação responde 3 perguntas antes da primeira linha de código: o que e por quê, como e dentro de que restrições, e como saber que terminou.
Um agente de IA não deixa uma pergunta sem resposta. Se a especificação não diz o que fica fora do escopo, ele decide sozinho. Se não diz qual padrão de arquitetura seguir, ele escolhe um. Se não diz o que conta como pronto, ele para quando o resultado parece pronto. SDD existe para tirar essas decisões da cabeça do agente e colocar na especificação, antes de qualquer prompt de implementação. O hábito de pular direto para o prompt, deixando o agente preencher os detalhes por conta própria, ficou conhecido como vibe coding. SDD é a camada estrutural que substitui esse hábito por uma especificação revisável.
Por que ambiguidade na especificação é onde tudo desanda
Requisito pouco claro já era, antes de qualquer agente de IA existir, uma das principais causas de falha de projeto: segundo o PMI, quase metade (47%) dos projetos malsucedidos não atinge seus objetivos por gestão de requisitos inadequada. Um agente de IA acelera o efeito dessa ambiguidade: uma especificação pouco clara discutida entre pessoas gera uma reunião de alinhamento. A mesma ambiguidade entregue a um agente gera código funcional, revisável e completamente fora do que se precisava.
O que uma especificação de SDD realmente precisa ter
O PRD responde ao quê e por quê: qual problema está sendo resolvido, para quem, e o que fica de fora do escopo. Sem essa parte, o agente resolve o problema errado, ou resolve mais do que deveria.
O technical plan responde a como, dentro de que restrições: qual arquitetura seguir, quais dependências respeitar, o que não pode mudar no resto do sistema. Sem essa parte, o agente entrega uma solução tecnicamente válida, mas incompatível com tudo o que já existe.
Os critérios de aceite respondem a como saber que terminou: quais casos de teste o resultado precisa passar, como o sistema deve se comportar nas situações de borda, o que conta como “pronto”. Sem essa parte, o agente considera pronto qualquer resultado que pareça pronto à primeira vista.
Os três componentes têm papéis diferentes e nenhum substitui o outro. O PRD sem technical plan deixa a arquitetura a critério do agente. O technical plan sem critérios de aceite deixa a validação a critério de quem revisar por último. Faltando qualquer um dos três, alguma decisão que deveria estar na especificação acaba sendo tomada durante a implementação, sem registro e sem revisão prévia.
A diferença aparece na frase. Um critério de aceite como “o sistema deve validar o CPF do usuário” deixa o agente decidir sozinho o que fazer com um CPF inválido. Uma versão de SDD diz “o sistema deve rejeitar CPF com dígito verificador inválido, retornar o código de erro 422 com a mensagem X, e manter o restante do formulário preenchido”. Na segunda frase, não sobra espaço para interpretação, e é exatamente esse o objetivo.
O gap real: quase todo mundo usa IA, quase ninguém usa no ciclo inteiro
Entre os 11 mil desenvolvedores que responderam à pesquisa AI Pulse da JetBrains em janeiro de 2026, 90% já usam IA no trabalho, mas no máximo 13% usam IA ao longo de todo o ciclo de desenvolvimento, em etapas como revisão de código e pipeline de release (JetBrains, março de 2026). A maior parte do uso hoje é pontual: gerar um trecho de código, completar uma função, sugerir um teste. SDD é o que permite estender esse uso para o ciclo inteiro, porque dá ao agente uma especificação estável para trabalhar do início ao fim, em vez de um prompt novo a cada etapa. Na prática, isso significa que o mesmo PRD e o mesmo technical plan orientam o agente da primeira função escrita até o último critério de aceite validado, sem que o time precise reexplicar o contexto a cada nova tarefa.
Quanto rigor de especificação cada mudança precisa
Nem toda mudança exige os três componentes completos. Uma correção pequena, de baixo risco, pode se apoiar num PRD curto e critérios de aceite objetivos, sem um technical plan formal. Uma mudança estrutural, ou um sistema crítico, pede os três completos, com o technical plan revisado por uma pessoa antes de o agente começar a implementar. O critério é sempre o mesmo: quanto maior o custo de uma decisão errada, maior o rigor da especificação que a antecede.
Perguntas frequentes
SDD substitui o PRD tradicional de produto?
Não. SDD usa a mesma lógica de um PRD, só que escrito para que um agente de IA consiga executar a partir dele, com o technical plan e os critérios de aceite explícitos ao lado, não implícitos na cabeça de quem escreveu.
SDD é a mesma coisa que o Método BMAD?
Não, são camadas complementares. SDD define a especificação: o que construir e dentro de que restrições. O Método BMAD organiza o fluxo de papéis e etapas que transforma essa especificação em entrega. Depois que o código existe, é a vez do harness de testes provar que ele atende ao que a especificação pedia.
Preciso escrever a especificação sozinho, ou o agente pode ajudar?
O agente pode ajudar a estruturar e revisar, mas as decisões de escopo, restrição técnica e critério de aceite continuam sendo humanas. É exatamente a parte que não deveria ser delegada, porque é ela que define o que o agente vai fazer depois.
A decisão que fica antes do prompt
Escrever uma especificação de SDD leva mais tempo do que digitar um prompt solto. Também leva bem menos tempo do que refazer duas sprints de código que resolveu o problema errado. A pergunta que decide qual dos dois caminhos uma equipe vai seguir é de prioridade: vale mais chegar ao primeiro resultado rápido, ou chegar ao resultado certo na primeira vez.
Aqui na Maitha, tratamos a especificação como o ponto de partida para usar IA ao longo de todo o desenvolvimento, da definição do problema à entrega. Com PRD, technical plan e critérios de aceite definidos, o agente trabalha sobre um documento de referência comum, o time revisa as decisões antes da implementação, e cada etapa seguinte, da arquitetura aos testes, parte de uma base alinhada. Se o seu time está começando a usar agentes no desenvolvimento, essa é uma conversa que vale ter antes do próximo prompt.
