Durante o nosso último off-site aqui nos Estados Unidos, aconteceu uma cena que, há poucos anos, eu chamaria de ficção científica: em poucas horas, com meia dúzia de comandos e alguns ajustes finos, construímos uma feature complexa em cima da nossa plataforma e um produto novo do zero — tudo com código gerado por IA, guiado por um negócio chamado Spec-Driven Development.
Não foi “milagre de hackathon”. Foi mudança de mentalidade.
Do vibe coding ao “opa, isso aqui precisa crescer”
Você provavelmente já praticou vibe coding – mesmo sem usar esse nome.
É quando você abre seu copiloto favorito, solta um: “Cria um CRUD em Node com autenticação JWT e integra com esse banco aqui”. Recebe um bloco de código aceitável, mexe um pouco e põe pra rodar.
- Leia também: Home office: 114 vagas para trabalho remoto [26/10]
Esse estilo funciona muito bem para scripts, MVPs e experimentos rápidos. Mas o mercado já começou a perceber que, na escala de produto sério, ele vira dívida técnica expressa: código que compila, mas não conversa bem com o resto do sistema, não documenta intenção e não sobrevive a troca de time.
É aí que entra o tal do Spec-Driven Development (SDD), que vem aparecendo em textos de gente como o Martin Fowler e em discussões pesadas sobre o futuro do desenvolvimento com IA.
O que é Spec-Driven Development (sem buzzwordês demais)
A ideia central do SDD é simples: em vez de começar pelo prompt “faz esse módulo pra mim”, você começa por uma especificação — uma espécie de roteiro detalhado — que vira a fonte da verdade tanto para o humano quanto para a IA.
Documentação primeiro, código depois. Ou, mais precisamente: intenção primeiro, implementação depois.
Ferramentas e artigos mais recentes falam de três estágios dessa história: spec-first, spec-anchored e spec-as-source — esse último sendo o “modo sonho”, em que o dev praticamente só edita o spec, e a base de código é sempre regenerada a partir dele.
Mas o que me interessa aqui não é tanto a teoria, e sim como isso muda o nosso dia a dia quando a gente combina SDD com vibe coding de forma inteligente.
Como a gente está usando isso na prática
No nosso fundo, o tech partner compartilhou um material bem sólido sobre SDD. Resolvi aplicar na marra durante o off-site:
1. Tudo começa na conversa com o cliente
A gente grava as reuniões de discovery, como sempre. A diferença é o que vem depois: em vez de deixar a transcrição mofando numa pasta, usamos IA para extrair requisitos de negócio, dores, fluxos de uso e transformar isso em rascunhos de tela, fluxos HTML, pequenos protótipos navegáveis.
2. Do protótipo para o spec
Com o feedback direto do cliente em cima desses artefatos, pedimos para a própria IA gerar um documento de especificação no formato de Spec-Driven Development:
- O que o recurso precisa fazer,
- Quais são os inputs e outputs,
- Restrições técnicas,
- Casos de erro,
- Critérios de sucesso.
E aqui veio um aprendizado importante: quanto menor e mais quebrado o spec, melhor a resposta da IA.
Um spec grande e monolítico vira confusão; specs menores, por processo ou por feature, tendem a gerar código muito mais alinhado.
3. Spec entra, código sai (com CLIs no meio)
Esses specs vão para o nosso ambiente de coding com IA via CLI. Em vez de abrir uma janelinha de chat e “pedir um favor” pra IA, tratamos o spec como entrada oficial do sistema.
O resultado foi um salto de nível: menos idas e vindas, menos refatoração desesperada e mais tempo discutindo produto, arquitetura e edge cases — não sintaxe.
No fim de algumas horas, a sensação foi muito clara:
eu tinha trabalhado mais como roteirista e diretor do que como digitador de código.
Vibe coding não morre — ele muda de lugar
Então acabou o vibe coding? Não. O que está mudando é onde ele entra no processo.
- Para testar ideias, validar uma hipótese técnica rápida, montar um experimento… vibe coding continua maravilhoso;
- Para features críticas, integrações mais sensíveis, coisas que precisam escalar e ser mantidas por anos, o SDD vira quase obrigatório.
Pensa no SDD como a evolução natural de coisas que já conhecemos há décadas: specification by example, test-driven development, PRD bem escrito. Só que agora, em vez de a documentação virar PDF esquecido, ela é consumida ativamente pela IA para gerar e regenerar o sistema.
Para onde isso aponta: o futuro do vibe coding
Se eu tivesse que apostar num futuro próximo, ele se parece com isso:
- Pequenas equipes com impacto gigante, porque uma boa especificação vira multiplicador de esforço quando conectada a agentes de código;
- Codebase menos “frankenstein”, porque a IA deixa de responder a um histórico caótico de chat e passa a obedecer a um spec estável, versionado;
- Dev mais estrategista do que digitador, navegando entre discovery com o cliente, desenho de specs e curadoria de código gerado.
Vibe coding continua sendo aquela jam session de banda em estúdio: suja, criativa, rápida. Spec-Driven Development é quando você entra no estúdio para gravar o álbum que vai para o streaming.
E você, em que fase está?
Na nossa experiência, usar Spec-Driven Development em vez de puro vibe coding não foi só ganho de velocidade — foi principalmente ganho de clareza.
A pergunta que eu deixo pra fechar essa coluna é simples:
Você ainda está pedindo código “no vibe” — ou já começou a tratar a IA como uma engenheira que precisa de um bom roteiro antes de sair construindo?
Se a resposta ainda for a primeira, talvez esteja na hora de experimentar escrever o seu próximo recurso como spec e ver o que acontece.
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
)
