Spec-Driven Development: o que vem depois do vibe coding
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