Alexandre Izefler

spec-driven development

A especificação virou o código-fonte: o que o Spec-Driven Development resolve (e o que não)

O Spec-Driven Development é a filosofia que dá forma prática ao paradigma 70/30. Investir o grosso do esforço na intenção de negócio e técnica, não na digitação. Olho o ecossistema de ferramentas que já existe e por que a disciplina importa mais que qualquer uma delas.

Alexandre Izefler
spec-driven developmentai-nativeengenharia de software70/30V-Bounce

Capa do artigo

Semana passada pedi pra um agente implementar uma mudança que eu considerava trivial. O código voltou bem formatado, compilou de primeira e estava errado. Não errado de sintaxe. Errado de intenção: ele resolveu um problema parecido com o que eu tinha na cabeça, não o que eu tinha na cabeça. Olhei aquilo e me veio uma frase que andei lendo: o modelo é ótimo em completar padrões, não em ler mente. É de Den Delimarsky, e resume bem o gargalo real de quem programa com IA hoje.

A barreira técnica caiu. Gerar código ficou barato. O que ficou caro foi dizer com precisão o que você quer, e validar que foi isso que veio.

O gargalo é de intenção, não de digitação

O relatório DORA de 2025 colocou número nessa intuição. Algo como 90% dos desenvolvedores já usam IA de alguma forma, e a conclusão mais importante do estudo não é sobre velocidade. É sobre amplificação: a IA não melhora a entrega de software automaticamente, ela multiplica as condições que já existem. Time com prática madura de engenharia converte o ganho em entrega melhor. Time com processo fragmentado acelera a dívida técnica e a instabilidade. A ferramenta é a mesma. O resultado depende do que estava embaixo dela.

Isso conversa direto com uma tese que defendo aqui faz tempo e que desenvolvi no artigo sobre o V-Bounce. Quando a execução comprime, o valor migra pra cima: pra intenção, a especificação e a validação. O Cory Hymel chama isso de V-Bounce, e o paradigma 70/30 vem daí. Você passa a investir cerca de 70% do esforço em descobrir e especificar o problema certo, porque a parte de "produzir" deixou de ser o limite.

Os 70% não são um número de planilha. São uma mudança de centro de gravidade. Quando eu sento para resolver um problema hoje, a pergunta não é "quanto tempo vou levar para programar isso". É "eu entendi o problema bem o bastante para que a máquina, e eu, acertemos de primeira?". E tem um detalhe cruel: quando o código era artesanal, a ambiguidade do requisito se resolvia no meio do caminho, o desenvolvedor "descobria" a regra enquanto programava. Com geração automática, ambiguidade na entrada vira ambiguidade na saída, só que mais rápido e em maior volume.

Só que reconhecer que o valor está na especificação é fácil. A pergunta prática é: como você trata uma especificação como artefato de engenharia de verdade, e não como um documento que ninguém lê? É aqui que entra o Spec-Driven Development. Não como ferramenta. Como filosofia.

A filosofia SDD: a ponte entre o 70/30 e o código

O Spec-Driven Development (SDD) é, na essência, a implementação prática do paradigma 70/30. Ele inverte a ordem. Em vez de partir pro código e usar a IA como autocomplete turbinado, você descreve o que quer, refina em etapas e deixa o agente implementar a partir daí. A especificação deixa de ser comentário e vira a fonte da verdade, para você e para a máquina.

É o elo que faltava: o 70/30 diz onde o valor está. O SDD diz como capturar esse valor na prática. Sem essa ponte, o paradigma fica bonito no diagrama e inútil na segunda-feira de manhã.

Três princípios sustentam a filosofia, independente da ferramenta que você usa.

1. A spec é o artefato primário. O código é derivado. Quando o resultado sai errado, você corrige a especificação primeiro, não o código. A Birgitta Böckeler, num estudo afiado publicado no site do Martin Fowler, separa três níveis de maturidade aqui: spec-first (escrevo a spec e depois o código), spec-anchored (mantenho a spec viva ao longo da evolução) e spec-as-source (a spec é o artefato primário, o código é derivado). A maturidade está nesse último degrau. E é nele que o 70/30 se manifesta de verdade, porque a spec é o trabalho, não um passo burocrático antes do trabalho "real".

2. A intenção de negócio vem antes da intenção técnica. E ambas vêm antes do código. Os 70% não são só sobre escrever prompts melhores. São sobre a conversa difícil que a maioria das equipes posterga: o que exatamente é sucesso? Quais são as restrições inegociáveis? Qual comportamento define "pronto"? O SDD força essas perguntas pra frente do processo, onde elas são baratas de responder, em vez de deixá-las pra revisão de código, onde são caras.

3. Governança que habilita, não que aprova. Em vez de espalhar padrões de qualidade, regras de design system e restrições de segurança por wikis que o agente nunca lê, você os coloca na especificação. O contrato atravessa todas as fases. É o que venho chamando de TI como curadora de capacidades: o guardrail existe antes do primeiro commit, não depois do último.

A paisagem de ferramentas: a filosofia já tem ecossistema

O SDD é uma filosofia. Mas filosofia sem ferramenta não escala. O que me chamou atenção nos últimos meses é que a ideia já saiu do paper e virou ecossistema, com abordagens diferentes competindo por formas de operacionalizar os mesmos princípios.

O GitHub Spec Kit é o toolkit open source que mais cresceu. Agnóstico de modelo, roda com mais de 30 agentes de IA e organiza o fluxo em fases claras: constitution (princípios do projeto), specify, plan, tasks, implement. A ideia da constitution, um arquivo onde ficam os princípios inegociáveis e que atravessa todas as fases, é a mais elegante do Spec Kit. É governança que habilita antes, em vez de aprovar depois.

O Kiro, da AWS, segue outra rota: é uma IDE completa com SDD embutido. Você escolhe entre "vibe coding" e "spec-driven" ao abrir um projeto. A experiência é integrada, mas o lock-in ao ecossistema AWS é real. Se você não está nesse mundo, perde boa parte do apelo.

O Claude Code, da Anthropic, ataca o problema de forma mais orgânica. Em vez de impor um framework externo, ele usa arquivos CLAUDE.md na raiz do projeto e skills (markdown reutilizáveis em .claude/skills/) como a especificação viva do contexto. Não há um comando /specify. A spec está embutida na configuração do ambiente de desenvolvimento. É SDD por osmose, menos cerimonioso e mais natural pra quem já trabalha com o agente no terminal.

O Cursor Plan Mode parte de uma separação simples: pensar e fazer são momentos distintos. No modo Plan, o agente analisa, planeja e documenta antes de tocar no código. Frameworks comunitários como o Memory Bank expandiram isso com memória persistente entre sessões. É a versão mais acessível do SDD. Menos estrutura, mais guardrail cognitivo.

O OpenSpec, da Fission AI, se apresenta como "fluido, não rígido; iterativo, não cascata". Cada mudança vira uma pasta com proposta, specs, design e tarefas. Funciona com mais de 25 ferramentas via slash commands. É a abordagem mais leve e modular do grupo.

O BMAD-METHOD (Breakthrough Method for Agile AI-Driven Development) leva a cerimônia ao outro extremo: oito agentes especializados (Analyst, Architect, Developer...) e mais de vinte workflows estruturados guiam o ciclo completo, do PRD ao deploy. Pra projetos grandes e equipes que precisam de rastreabilidade, a estrutura se justifica. Pra um side project, é overengineering.

O Tessl vai um passo além: é uma plataforma SaaS que recebe especificações em linguagem natural e gera código funcional com verificação automática. É a proposta mais ambiciosa e também a mais opaca. Por ser produto fechado, fica difícil julgar onde a spec realmente governa e onde o modelo está improvisando.

A diversidade é saudável. Mas o ponto que quero defender é outro: a ferramenta importa menos do que a disciplina. Cada uma dessas opções é uma implementação diferente da mesma filosofia. E a filosofia é o que sustenta os 70% do paradigma. Trocar de Spec Kit pra Kiro não resolve uma equipe que não sabe definir o que é sucesso. E uma equipe que sabe definir sucesso faz SDD funcionar até com um README.md bem escrito e um agente de linha de comando.

Por que isso não é mais um framework de documentação

Aqui entra a parte que me fez respeitar a abordagem em vez de só comprá-la. A própria Böckeler é honesta sobre o limite: mesmo com todos os arquivos, templates, prompts e checklists, ela viu o agente repetidamente não seguir todas as instruções. E levanta a hipótese mais incômoda de todas, que tanta cerimônia pode gerar uma falsa sensação de controle, quando comparada ao bom e velho ciclo iterativo de programar.

Acho essa ressalva certeira. SDD não é mágica, e janela de contexto maior não significa que o modelo vai captar tudo que está lá dentro. Especificação ruim não vira código bom porque você a chamou de "spec". O que muda não é a tecnologia. É a disciplina. Se você não sabia escrever um requisito claro antes da IA, vai escrever uma spec ruim agora e culpar o agente, com Spec Kit, Kiro ou qualquer outra ferramenta da lista.

O ganho real do SDD, pra mim, é menos sobre automação e mais sobre obrigar a conversa difícil pra frente do processo. Ele força você a decidir o que é sucesso antes de gerar mil linhas. Isso é o 70/30 em ação: investir o grosso do esforço na definição da intenção de negócio e técnica, não na produção mecânica do artefato.

O que muda pra quem arquiteta

Se a spec é o novo código-fonte, ela é também a nova superfície de design. É onde a arquitetura, as restrições de negócio e as regras de governança passam a viver de forma que a máquina consegue executar. O papel de quem arquiteta não encolhe com a IA. Ele se desloca pra um ponto mais alavancado: desenhar a intenção e os trilhos, não revisar cada commit.

E esse deslocamento é exatamente o que o V-Bounce prevê. Os braços do "V" (entender o problema, desenhar a solução, planejar a validação) continuam exigindo julgamento humano. A diferença é que agora eles pesam 70% do esforço, não 20%. E o SDD, nas suas várias encarnações, é o que torna esses 70% produtivos em vez de burocráticos.

Continua valendo o fundamento de sempre. A validação não some porque a spec ficou melhor. Ela fica mais importante, porque agora a IA produz volume numa velocidade que nenhum revisor humano acompanha linha a linha. O DORA já avisou: sem a base madura embaixo, o que a IA acelera é o caos.

A barreira técnica caiu. Hoje o que pesa é querência e vontade de resolver problemas difíceis com soluções simples. O Spec-Driven Development não é a solução simples. Ele é o lugar onde a gente finalmente é obrigado a dizer, com clareza, qual é o problema. E o paradigma 70/30 é a bússola que diz quanto do seu tempo deveria estar nesse "dizer com clareza".

Referências