O método que GitHub, Google e Amazon adotaram pra substituir vibe coding
O novo jeito de programar com IA (que até o Martin Fowler questiona)
Umas semanas atrás eu vi um post no Reddit de um dev descrevendo o que aconteceu depois de 3 meses de vibe coding num projeto real. Começou bem. Ele descrevia features em linguagem natural, a IA gerava o código, ele aceitava, seguia em frente. O ritmo era incrível.
Até que uma mudança pequena quebrou 4 features. Ele pediu pra IA consertar, e o conserto quebrou outras 3. O cara descreveu isso como “whack-a-mole com meu próprio código.”
Eu li aquilo e pensei: conheço esse filme.
Eu já passei por exatamente isso uns meses atrás. Fiz o sistema de pagamentos inteiro com IA, aceitando código sem questionar muito. Funcionou por semanas. Quando precisei mudar a lógica de créditos, foi um efeito dominó. Três dias pra desfazer o que a IA tinha criado em duas horas.
A diferença é que eu tinha 20 anos de base pra diagnosticar o problema. Se eu não tivesse, estaria até hoje tentando consertar.
E isso me levou a uma pergunta: se vibe coding claramente não escala, o que vem depois?
O que vem depois já tem nome
Nos últimos meses, aconteceu algo que pouca gente no Brasil percebeu: GitHub, Google e Anthropic convergiram pro mesmo padrão. Independentemente.
O GitHub lançou o Spec Kit, um toolkit open source com um workflow de 4 fases: Specify, Plan, Tasks, Implement. A ideia: antes de pedir pra IA codar qualquer coisa, você escreve uma spec clara do que precisa ser feito. Essa spec vira a “fonte de verdade” do projeto. O código é gerado a partir dela, não a partir de vibes.
O Addy Osmani (engenheiro do Google, autor de livros da O’Reilly) publicou um framework de 5 princípios pra escrever specs que agentes de IA conseguem executar. “Waterfall em 15 minutos”, ele chama. Planejamento estruturado rápido, não burocracia.
A Anthropic publicou o “Building Effective Agents”, dizendo que os sistemas mais bem-sucedidos usam padrões simples e composáveis, não frameworks complexos.
Até a Amazon lançou uma IDE com essa estrutura interna, o Kiro (que eu testei na época do lançamento e fiz review constante no instagram da Codar.me).
O nome que grudou: Spec-Driven Development (SDD).
Como funciona na prática
O workflow do Spec Kit tem 4 fases com checkpoints claros:
1. Specify - Você descreve user journeys, experiencias do usuário, e critérios de sucesso. Sem mencionar tecnologia. O foco é no “o que” e no “por que”.
2. Plan - Agora sim: stack, arquitetura, constraints técnicas. Isso vira um documento que o agente vai seguir.
3. Tasks - O plano é decomposto em unidades atômicas. Cada tarefa é independente, testavel, e inclui os arquivos exatos que precisa tocar.
4. Implement - A IA executa tarefa por tarefa. Cada uma é verificável antes de seguir pra próxima.
A sacada é que o checkpoint entre cada fase é um portão de qualidade. Você revisa a spec antes de planejar. Revisa o plano antes de decompor. Revisa as tarefas antes de implementar. A IA nunca sai correndo sem aprovação.
Isso resolve o problema central do vibe coding: você perdia o controle porque não existia controle. Não tinha spec, não tinha plano, não tinha checkpoint. Só vibes.
Por que specs funcionam (a ciência por trás)
Se você leu a edição anterior sobre por que a IA ignora metade do que você escreve, já sabe que modelos têm atenção em formato de U, prestam atenção no início e no fim do contexto, e tendem a ignorar o meio. E que existe um orçamento real de ~150-200 instruções que o modelo consegue seguir com consistência.
SDD é a resposta prática a esses dois problemas.
Quando você vibecoda, a cada prompt novo o contexto fica mais longo e mais confuso. Instruções antigas se perdem no meio. O modelo começa a “esquecer” o que deveria fazer. É exatamente o efeito “Lost in the Middle” que a pesquisa do MIT documentou.
Quando você trabalha com specs, cada tarefa tem um contexto limpo e focado. O agente recebe exatamente o que precisa pra executar aquela unidade de trabalho, nada mais, nada menos. Isso mantém o modelo dentro do seu orçamento de atenção.
A spec não é burocracia. A spec é gerenciamento de contexto.
O dado que me convenceu
O GitHub analisou 2.500 repositórios com arquivos de configuração de agentes de IA. O padrão mais eficaz que encontraram usa um sistema de 3 níveis de autonomia:
Sempre: ações que o agente faz sem pedir. “Sempre rode testes antes de commitar.”
Pergunte primeiro: ações de alto impacto. “Pergunte antes de alterar schemas do banco.”
Nunca: stops absolutos. “Nunca comite secrets ou API keys.”
É simples. E funciona porque elimina ambiguidade. O agente sabe exatamente onde tem autonomia e onde precisa parar.
Sabe qual foi a instrução de “Never” mais comum nos 2.500 repos? “Never commit secrets.” A coisa mais básica de segurança. E mesmo assim precisava ser escrita explicitamente pro agente não fazer.
Isso diz tudo sobre o nível de confiança que você pode ter em código gerado sem supervisão.
O que a equipe do Martin Fowler pensa (e por que importa)
Nem todo mundo é entusiasta. Birgitta Böckeler, Distinguished Engineer na Thoughtworks e colaboradora direta do Martin Fowler, testou o Spec Kit e o Kiro na prática e publicou uma análise honesta.
A critica central dela não é contra a ideia de spec-first. Ela mesma diz que frequentemente gasta tempo escrevendo uma spec cuidadosa antes de pedir algo pra IA. O que ela questiona é a cerimônia excessiva das ferramentas.
Quando usou o Spec Kit numa feature de tamanho médio, a quantidade de arquivos markdown gerados pra revisar era enorme. Repetitivos entre si, redundantes com código que já existia. Ela estimou que no mesmo tempo que gastou revisando specs, teria implementado a feature inteira com coding assistido por IA normal, sem todo o aparato formal.
O outro ponto forte: mesmo com todas as specs, templates, workflows e checklists, o agente frequentemente não seguiu todas as instruções. Em um caso, o agente ignorou notas sobre código existente e recriou classes duplicadas. Em outro, seguiu uma regra da “constitution” de forma tão entusiasmada que fez mais do que deveria.
Ela resume a preocupação com uma palavra alemã que não tem tradução: “Verschlimmbesserung”, quando você tenta melhorar algo e acaba piorando.
E ela tem razão. A ferramenta não é o conceito. Spec Kit pode ser overkill pra muita coisa. Kiro gerou 4 user stories e 16 critérios de aceite pra um bug simples.
Mas o princípio por trás do SDD, pensar antes de codar, documentar a intenção, dar contexto estruturado pro agente, isso ela mesma pratica. A questão não é “SDD sim ou não”. É “quanto de cerimônia faz sentido pra cada tamanho de problema?”
E essa é a pergunta certa.
O que eu mudei no meu workflow
Depois dessa pesquisa, mudei 3 coisas:
1. Spec antes de código. Qualquer feature nova começa com uma spec de 1 parágrafo: o que, por que, e critérios de aceite verificáveis. Se eu não consigo escrever uma spec clara, a feature não está pronta pra ser construída.
2. Boundaries explícitas. Cada projeto tem um arquivo com os 3 níveis: Always, Ask First, Never. O agente sabe o que pode fazer sozinho e onde precisa parar.
3. Tarefas atômicas. Em vez de pedir “implementa o sistema de pagamentos”, eu decomponho em tarefas de 1-3 arquivos com uma definição de “pronto” verificável. “Quando o endpoint /payment receber um request com créditos insuficientes, deve retornar 402 com a mensagem X.”
O resultado: menos surpresas, menos retrabalho, menos whack-a-mole.
Não é perfeito. A IA ainda erra. Mas quando ela erra, eu sei exatamente o que ela deveria ter feito, porque a spec existe. Isso cria um novo portão de qualidade automatizado. E isso muda tudo.
O ponto que ninguém fala
Vibe coding não vai morrer. Pra protótipos, MVPs, side projects, experimentação rapida, funciona. Eu uso até hoje quando quero testar uma ideia em 30 minutos.
Mas pra qualquer coisa que vai pra produção, que vai ter usuários reais, que vai precisar de manutenção, vibe coding é dívida técnica no cartão de crédito. Parece barato agora. Os juros chegam depois.
SDD é a alternativa: mantém a velocidade da IA, mas adiciona a estrutura que impede o código de virar um castelo de cartas.
A frase que resume: deixamos de tratar código como a fonte de verdade. A intenção é a fonte de verdade agora. O código é só o output.
Na próxima edição, vou falar sobre o Manus AI , o agente que faz ~50 tool calls por tarefa e descobriu que a forma como você estrutura o contexto importa mais do que o modelo que você usa. Os números que eles publicaram sobre overhead de tarefas mal escritas são surpreendentes.
--
Bruno Bertolini
P.S. Se você quiser testar SDD no seu próximo projeto, o Spec Kit do GitHub é open source e funciona com Claude Code, Copilot, Cursor e Gemini. Link: github.com/github/spec-kit
Tenho usado SDD a alguns meses, para projetos simples e no início funciona relativamente bem, agora estou usando em um projeto com uma complexidade muito grande e a experiência é frustrante. Quando você tem que passa horas descrevendo o que a IA deve fazer e ela ainda faz errado, ignora os padrões definidos para o projeto e boas práticas de código que estão definidas no projeto é muito mais eficiente fazer manualmente e assistido por IA
Vou estudar sobre o que falou. Acredito que todos os desenvolvedores deveriam saber a lidar melhor com a IA do que ir contra a elas.