PulseFlow Tecnologia
← Insights
·6 min de leitura·brief-executivo·spec-driven-development·vibe-coding·spec-kit
PulseFlow Tecnologia

Spec-driven development: a resposta madura ao vibe coding

Duas empresas que competem diretamente por desenvolvedores - GitHub e Microsoft - chegaram à mesma conclusão sobre o problema mais caro do "vibe coding": descrever um objetivo, receber um bloco de código, e descobrir só depois que o resultado não considerou como o sistema deveria interagir com o que já existia. A resposta que ambas documentam é spec-driven development, e o GitHub Spec Kit virou a implementação de referência.

O diagnóstico: código é vinculante, spec não é

A Microsoft resume o argumento central de forma direta: "código é um artefato vinculante" - difícil de desacoplar depois de implementado —, enquanto especificações permitem experimentação flexível antes de qualquer coisa travar. A empresa descreve spec-driven development não como documentação exaustiva ou planejamento em cascata, mas como "version control for your thinking" - tornar decisões técnicas "explícitas, revisáveis e evolutivas", da mesma forma que se versiona código.

O cenário que ilustra o custo de não ter isso

A Microsoft cita um cenário concreto: um sistema de notificações em que membros diferentes do time fizeram suposições conflitantes sobre como o sistema deveria funcionar - divergências que uma spec bem-feita teria capturado antes de qualquer linha de código ser escrita, não depois, em produção. É o mesmo argumento por trás do contraste que o GitHub traça entre vibe coding e spec-driven development: vibe coding aceita o resultado do primeiro prompt; spec-driven development força "clareza sobre como deve interagir com sistemas existentes" antes de aceitar qualquer implementação.

Três comandos, um fluxo sequencial

O GitHub Spec Kit - hoje com mais de 118 mil estrelas - organiza isso em torno de comandos sequenciais: /specify define requisitos funcionais (o "quê" e o "porquê"), /plan define decisões técnicas (o "como"), /tasks quebra a especificação em unidades implementáveis. A ferramenta em si, Specify CLI, é agnóstica quanto ao agente de IA usado - funciona com mais de 30 agentes diferentes, de GitHub Copilot a Claude Code a Gemini.

O que a spec permite que o vibe coding não permite

Um detalhe que a Microsoft destaca e que raramente aparece em discussões sobre IA generativa em código: com a especificação como artefato central, é possível explorar múltiplas implementações a partir da mesma spec - por exemplo, comparar um componente escrito em Rust contra um escrito em Go, sem reescrever o requisito do zero para cada tentativa. Isso é estruturalmente impossível em vibe coding, onde a especificação vive apenas dentro do prompt de uma única tentativa.

Por que isso é a resposta madura, não só outra ferramenta

O GitHub e a Microsoft não estão inventando specs - arquitetura decision records (ADRs) e requisitos formais já existiam antes da IA generativa. O que muda é a integração sistemática entre spec e fluxo de agente: a especificação deixa de ser documento arquivado e passa a ser o artefato que o próprio agente usa para gerar, e que o time usa para revisar, com rastreabilidade entre o requisito original e o código final.

Fontes