Parar de escrever o software duas vezes: desenvolvimento guiado por especificação e o fim das reescritas

Por que o software sempre foi escrito duas vezes (uma em especificações e outra em código) e por que essa segunda escrita finalmente está desaparecendo.

No desenvolvimento de software, quando é bem feito, precisamos escrever o software duas vezes: primeiro, em especificações detalhadas que explicam exatamente o que o software deve fazer, e depois de novo como código que dá vida a essas especificações. Mas aqui vai uma verdade incômoda: raramente é bem feito na primeira vez.

O processo costuma se quebrar porque criar especificações exaustivas consome tempo, e os times quase nunca capturam todos os detalhes necessários de antemão. Isso leva a lacunas, suposições e retrabalho caro. Como resultado, os projetos de software estouram o orçamento, perdem prazos e deixam todo mundo frustrado.

Os custos ocultos de escrever o software duas vezes

Para entender por que escrever o software duas vezes é necessário mas raramente bem feito, vamos destrinchar as duas fases:

1. A primeira escrita: especificações em linguagem natural

A primeira vez que o software é escrito não estamos escrevendo código nenhum. Estamos criando requisitos, histórias de usuário e documentos de design, redigidos em linguagem natural. É aqui que os times descrevem como o software deveria funcionar, o que os usuários podem fazer e como deveria ser a experiência.

Mas aqui está o problema: nenhum time tem o luxo de escrever todos os detalhes. Quem cuida de produto muitas vezes precisa correr para cumprir prazos agressivos, e alguns projetos nem contam com perfis profissionais de produto. Eles esboçam as linhas gerais, mas recursos e interações importantes ficam de fora. Como disse Steve Jobs em uma frase célebre, “grandes produtos são feitos de 5.000 pequenas decisões”, mas na maioria dos projetos não tomamos essas decisões de antemão. Elas são deixadas para alguém de desenvolvimento interpretar depois, o que leva à segunda etapa.

2. A segunda escrita: traduzir especificações em código

Uma vez entregues as especificações, quem desenvolve é responsável por transformar essas descrições em código funcional. Mas quando a primeira “escrita” está incompleta, é preciso usar a imaginação para preencher as lacunas. Suposições são feitas e, mesmo dominando a tecnologia, essas pessoas podem não ter a imagem completa da visão do produto.

É aqui que os problemas afloram:

• Detalhes que faltam geram atrito: quando os times de produto não especificam um recurso ou caso de uso importante, desenvolvimento precisa adivinhar ou improvisar. Isso costuma resultar em funcionalidade que não atende às expectativas.
• Suposições geram retrabalho: ao preencher as lacunas, recursos podem ser construídos de formas que não se alinham à visão do produto, causando retrabalho massivo mais adiante.
• Apontar dedos se torna inevitável: à medida que os prazos escorrem e os orçamentos estouram, os times se culpam. Produto acusa engenharia de “não entender”, enquanto engenharia aponta para produto por especificações pouco claras.

O resultado é uma cascata de problemas que levam a prazos perdidos, orçamentos estourados e resultados insatisfatórios. A pesquisa CHAOS do Standish Group documenta há anos que a maioria dos projetos de software estoura o orçamento e perde as datas de entrega. Um estudo da McKinsey com a Universidade de Oxford encontrou que grandes projetos de tecnologia estouram em média 45% do orçamento e 7% do tempo, entregando 56% menos valor do que o previsto, e que 17% dos grandes projetos de tecnologia vão tão mal que ameaçam a própria existência da empresa.

Claramente, algo nesse processo está quebrado.

A prática já tem nome

A indústria se decidiu por um termo para isso enquanto a maioria discutia sobre prompts: desenvolvimento guiado por especificação. Escreva primeiro os requisitos, as restrições e os critérios de sucesso. Trate essa especificação como a fonte da verdade. Deixe o agente construir contra ela.

O GitHub publicou o Spec Kit. A AWS publicou o Kiro. BMAD-METHOD, OpenSpec e Tessl todos tentaram. Martin Fowler documentou. A convergência não é coincidência: é o que acontece quando uma categoria inteira descobre o mesmo modo de falha ao mesmo tempo.

E o modo de falha é o descrito acima. As ferramentas que começam pelo prompt pulam a primeira escrita completamente. Vão direto para a segunda, adivinhando cada decisão que a especificação nunca tomou. O que está bem para uma demonstração e é ruinoso para um produto.

O desenvolvimento guiado por especificação não elimina a primeira escrita. Faz da primeira escrita a única que exige julgamento humano.

A nova primeira escrita: especificações que você consegue terminar de verdade

Isto é o que muda. A razão pela qual ninguém escrevia especificações completas nunca foi falta de vontade: era que o trabalho era lento demais para se justificar. Semanas de descoberta para produzir um documento que ficava obsoleto no contato com o primeiro sprint. Então os times escreviam as linhas gerais e deixavam as 5.000 pequenas decisões para serem descobertas depois, uma interpretação por vez.

Quando redigir uma especificação leva horas em vez de meses, a aritmética se inverte. Você pode se permitir ser exaustivo. Requisitos funcionais, design visual, modelo de dados, casos de borda: capturados antes de alguém abrir um editor, e baratos o suficiente para revisar quando você aprende algo.

Essa última parte importa. Uma especificação que não pode ser revisada de forma barata se torna uma mentira no momento em que a realidade chega. Esse é o mesmo instinto por trás de construir API-first: acerte as decisões que sustentam o peso antes de alguém escrever uma tela, e o resto decorre.

A nova segunda escrita: geração de código, não tradução

Uma vez completa a especificação, a segunda escrita deixa de ser um problema de tradução. Torna-se um problema de geração. Linguagens padrão: JavaScript, TypeScript, Python. Frameworks padrão: React, Next.js. Código real, nas formas que já se conhecem, derivado de um documento que já tomou todas as decisões.

A diferença não é que quem desenvolve trabalha mais rápido. É que deixa de fazer a parte que nunca foi engenharia: a reformulação mecânica de decisões que outra pessoa já havia tomado.

O que muda rio abaixo

Três coisas mudam ao mesmo tempo:

1. A primeira escrita é concluída: quando o trabalho de especificação custa horas em vez de meses, os times podem se permitir tomar as pequenas decisões de antemão em vez de descobri-las na revisão.
2. Ninguém preenche lacunas: código gerado a partir de uma especificação completa não exige que alguém adivinhe o que o time de produto quis dizer. Adivinhar sempre foi de onde vinham os defeitos.
3. O retrabalho para de se acumular: a intenção e a implementação começam alinhadas. O que antes era uma reescrita se torna uma edição da especificação.

O futuro de escrever software: linguagem natural

Desde que existe software, o trabalho exigia escrevê-lo duas vezes: uma em linguagem natural e outra em código. Essa segunda escrita nunca foi a parte valiosa. Era o pedágio que pagávamos porque não havia outro caminho.

Esse é o movimento em torno do qual a próxima geração de construtores de aplicações com IA se organiza: clareza antes do código. Descreva a aplicação como um blueprint, acerte a arquitetura, deixe o código ser gerado contra ela. Não é um atalho que evita o trabalho de definição, é uma razão para finalmente fazê-lo como se deve.

Agora existe outro caminho. O software sempre deveria ter sido escrito uma única vez.

Leituras relacionadas

O guia completo da prática: desenvolvimento guiado por especificação. Por que a geração que começava pelo prompt pulou essa etapa está em o vibe coding quebrou sua promessa, e o que a substitui em o que vem depois do vibe coding.

Perguntas frequentes

O que é desenvolvimento guiado por especificação? Desenvolvimento guiado por especificação é escrever os requisitos, as restrições e os critérios de sucesso antes de gerar qualquer código, e tratar essa especificação como a fonte da verdade contra a qual o agente de IA constrói. Surgiu em 2025 como resposta direta aos fluxos de trabalho que começam pelo prompt e pulam a etapa de definição completamente.

Em que se diferencia de um documento de requisitos tradicional? O documento é a mesma ideia; a economia não. Especificações tradicionais eram caras o suficiente para que os times escrevessem as linhas gerais e descobrissem o resto na revisão de código. Quando uma especificação leva horas em vez de meses e pode ser revisada de forma barata, vale a pena terminá-la e vale a pena mantê-la atualizada.

Quais ferramentas suportam o desenvolvimento guiado por especificação? GitHub Spec Kit, AWS Kiro, BMAD-METHOD, OpenSpec e Tessl são as implementações com nome, e o Cursor suporta uma versão mais leve através de arquivos de regras. Diferem sobretudo em quão forte é a ligação entre a especificação e o código: se dirige a geração uma vez, se evolui junto com o código, ou se é o único artefato que você edita.

O desenvolvimento guiado por especificação freia os times? Ele move o trabalho, não o adiciona. As decisões capturadas em uma especificação são decisões que alguém toma de qualquer forma: ou deliberadamente no início, ou de forma implícita quando alguém de desenvolvimento ou um modelo adivinha depois. O segundo caminho é de onde vem o retrabalho.

O que acontece com quem desenvolve se o código é gerado a partir de especificações? Desaparece a reformulação mecânica das decisões de outra pessoa. O julgamento sobre arquitetura, compromissos, correção e o que não construir não desaparece. Essas sempre foram as partes que exigiam engenharia.