Spec-Driven Development: o que vem depois do vibe coding · zilvodev

Semana passada eu escrevi sobre como o vibe coding "morreu" segundo o próprio Karpathy. O novo nome é "agentic engineering", e a ideia é que a IA não é mais só um assistente, é um agente que executa tarefas completas.

Beleza. Mas na prática, o que muda pra quem tá construindo um app com Cursor ou Lovable?

A resposta tá num conceito que ganhou força essa semana: Spec-Driven Development.

O problema do "prompt and pray"

Se você já tentou criar algo além de um protótipo simples com IA, provavelmente bateu nesse muro:

Nas primeiras horas, tudo funciona. A IA gera telas, lógica, até banco de dados.
Na segunda semana, começa a ficar estranho. Você pede uma mudança e outra coisa quebra.
No terceiro mês, o projeto tá num ponto onde a IA não consegue mais acompanhar. O código cresceu demais, ninguém sabe por que certas decisões foram tomadas, e cada ajuste gera dois bugs novos.

Isso tem um nome agora: a parede dos 3 meses.

Um desenvolvedor descreveu assim: "A IA ainda é burra. Ela conserta uma coisa e destrói outras 10."

O problema não é a IA. É a falta de especificação. Quando você só descreve o que quer por vibes, sem documentar regras, limites e decisões, o código vira uma caixa preta. Nem você nem a IA sabem por que algo funciona daquele jeito.

O que é Spec-Driven Development

A ideia é simples: antes de pedir pra IA escrever código, escreva o que você quer que aconteça.

Não é programar. É documentar. Em linguagem normal.

Em vez de digitar "cria uma página de login", você escreve algo como:

Spec: Login

Campos: email e senha

Validação: email válido, senha mínimo 8 caracteres

Erro: mostrar mensagem vermelha abaixo do campo

Sucesso: redirecionar para /dashboard

Segurança: bloquear conta após 5 tentativas erradas

A diferença parece sutil, mas é enorme. Quando a IA tem uma especificação clara, ela gera código consistente. Quando você muda algo, a spec é o ponto de referência. Quando algo quebra, você sabe exatamente o que deveria estar funcionando.

Por que isso importa pra quem não programa

Se você é empreendedor usando Cursor ou Lovable pra criar seu produto, spec-driven development resolve o maior problema que você vai enfrentar: manutenção.

Criar é a parte fácil. Manter funcionando ao longo do tempo é onde 80% dos projetos morrem.

Com specs:

Você tem um mapa. Quando a IA gera algo errado, você sabe comparar com o que deveria ser.
Outras pessoas conseguem ajudar. Se você precisar contratar um dev depois, ele entende o que foi feito sem ler 10 mil linhas de código.
A IA fica mais inteligente. Modelos como o Claude e GPT geram código muito melhor quando recebem specs claras em vez de prompts vagos.

Ferramentas que já existem

O mercado já respondeu:

GitHub Spec Kit: toolkit open-source pra criar specs, planos e tasks dentro do seu repositório
Amazon Kiro: IDE da Amazon focada em spec-driven (anunciada fev/2026)
BMAD Method / GSD: frameworks prontos que você pode usar hoje com qualquer ferramenta

O Cursor, por exemplo, já tem suporte a arquivos de contexto (.cursorrules, docs de projeto). Usar specs é uma extensão natural disso.

O caminho do meio

Não precisa abandonar vibe coding completamente. A melhor abordagem é híbrida:

Vibe coding pra explorar ideias rápido, testar conceitos, prototipar
Specs pra qualquer coisa que vai pra produção, que precisa de manutenção, que envolve segurança ou dados sensíveis

É como construir uma casa: você pode improvisar uma maquete. Mas quando vai construir de verdade, precisa de planta.

O que fazer agora

Se você tá usando Cursor ou Lovable pra construir algo sério:

Pare 30 minutos antes do próximo prompt e escreva o que você quer que o sistema faça
Documente as regras (o que pode e não pode acontecer)
Salve as specs junto com o código (no mesmo repositório)
Use as specs como prompt em vez de descrever tudo de cabeça toda vez

Não precisa ser perfeito. Uma spec simples já é infinitamente melhor que nenhuma.

A IA tá ficando mais inteligente todo dia. Mas inteligência sem direção é desperdício. Spec-driven development é a direção.

Fontes: Red Hat Developer (17/02), The New Stack (19/02), Built In, GitHub Spec Kit

Cara, eu pensava dessa forma. Mas depois descobri que não é waterfall, porque as specs são criadas de forma iterativa e incremental. Quem na verdade está escrevendo as specs é o agente de IA. Tu vai fornecendo as informações e descrições do produto via prompt (vibe engineering) e o agente é que vai preenchendo as specs. Às vezes uma descrição ou uma frase dita no prompt pode desencadear alteração em 2 ou mais arquivos .md de specs.

A qualquer momento você pode acionar o comando /implement e ter o produto gerado. Pode fazer isso várias vezes por dia, para validar e testar. Se não estiver ok, ajusta as specs; mas tudo via prompt. O workflow que eu tenho usado é bem semelhante ao ciclo de PDCA; praticamente igual.