Spec-driven development: IA sem especificação sai caro

Paulo Castilho — Sun, 18 Oct 2026 17:16:00 -0300

O que é spec-driven development e por que, com IA, começar a desenvolver sem a especificação completa deixa de ser atalho e vira retrabalho em escala.

Spec-driven development, ou desenvolvimento guiado por especificação, é escrever e acordar o que o software precisa fazer antes de escrever o código, e usar esse documento como fonte de verdade para as pessoas e para os agentes de IA que vão programar. A ideia ganhou nome e ferramentas em 2025, mas resolve um problema antigo: times que começam a desenvolver sem saber direito o que estão construindo.

Com IA, esse problema muda de escala. Escrever código ficou barato e rápido; decidir o que construir continua caro e lento. Quem pula a especificação não economiza esse custo, só o empurra para depois, quando ele aparece como retrabalho, defeito em produção e funcionalidade que ninguém pediu do jeito que foi entregue.

O que é spec-driven development#

A engenheira Birgitta Böckeler, da Thoughtworks, resume a prática como escrever uma especificação antes de pedir à IA que escreva o código, de modo que o documento passe a ser a fonte de verdade para humanos e agentes (Böckeler, 2025). Ela descreve três níveis de adoção:

Spec-first: a especificação é escrita antes e orienta a tarefa em andamento.
Spec-anchored: a especificação é mantida depois da entrega e guia a evolução e a manutenção da funcionalidade.
Spec-as-source: a especificação é o artefato principal; o código é gerado a partir dela e ninguém o edita diretamente.

As ferramentas apareceram em sequência. A Amazon lançou o Kiro, um ambiente de desenvolvimento que conduz o trabalho por requisitos, desenho técnico e tarefas. Em setembro de 2025, o GitHub publicou o Spec Kit, um kit de código aberto que organiza o trabalho em quatro etapas com revisão humana entre elas: especificar, planejar, quebrar em tarefas e implementar. O Tessl aposta no nível mais radical, em que só a especificação é mantida.

A prática ainda está amadurecendo. A Thoughtworks colocou o spec-driven development na faixa “Avaliar” do seu Technology Radar de novembro de 2025: vale experimentar, mas os fluxos ainda são elaborados, variam com o tamanho da tarefa e às vezes geram documentos longos demais para revisar.

O vício antigo: a especificação que nunca ficou pronta#

Fred Brooks escreveu em 1986, no ensaio “No Silver Bullet”, que a parte mais difícil de construir um sistema é decidir com precisão o que construir. Nenhuma outra parte do trabalho prejudica tanto o resultado quando feita errado, e nenhuma é tão difícil de corrigir depois.

Quarenta anos depois, muitas empresas ainda tratam essa parte como opcional. O padrão é conhecido:

A área de negócio descreve o que quer em uma reunião ou em um parágrafo de chamado.
O time de desenvolvimento começa a construir com o que tem, porque o prazo já está correndo.
As regras que ninguém discutiu aparecem durante a homologação, ou depois da entrada em produção.
O que falta vira “evolução” no backlog.

O problema não está em evoluir o software. Está em chamar de evolução o que é especificação atrasada. Uma evolução de verdade responde a algo que mudou: o mercado, a regulação, o comportamento do cliente. A falsa evolução corrige algo que já era conhecido, ou que deveria ter sido descoberto, antes da primeira linha de código: uma regra de negócio que duas áreas entendiam de jeitos diferentes, um caso de exceção que ninguém mapeou, uma negociação entre áreas que foi adiada porque era desconfortável.

Esse arranjo costuma se apoiar numa leitura enviesada do Manifesto Ágil. O manifesto valoriza “software em funcionamento mais que documentação abrangente”, mas fecha dizendo que há valor nos itens da direita. Ele nunca defendeu começar sem saber o que se quer. Defendeu não gastar meses em documentos que ninguém lê.

O custo desse vício aparece nas pesquisas. Em estudo de 2014 com profissionais de gestão de projetos, o PMI concluiu que 47% dos projetos malsucedidos não atingem seus objetivos por falhas no gerenciamento de requisitos (PMI, Pulse of the Profession). E corrigir tarde custa mais: Barry Boehm e Victor Basili registraram que encontrar e corrigir um problema depois da entrega costuma custar até 100 vezes mais do que na fase de requisitos e desenho, com a ressalva dos próprios autores de que, em sistemas pequenos e não críticos, a proporção fica mais perto de 5 para 1 (Boehm e Basili, IEEE Computer, 2001). Seja 5 ou 100, a direção é a mesma.

O que muda quando a IA escreve o código#

Até pouco tempo, a lentidão de escrever código funcionava como freio. Enquanto o desenvolvedor implementava, havia tempo para perguntar, perceber a lacuna e voltar à área de negócio. Com agentes de IA, a implementação de uma funcionalidade inteira pode sair em minutos. O freio sumiu.

Um agente de IA não para quando a especificação tem um buraco. Ele preenche o buraco com a suposição mais provável e entrega código que compila, passa nos testes que ele mesmo escreveu e parece correto. A regra de negócio que ninguém definiu passa a existir, decidida por um modelo estatístico, sem que ninguém tenha decidido. Multiplicado por dezenas de funcionalidades, o resultado é um sistema que cresce mais rápido do que a empresa consegue validar.

As pesquisas sobre IA no desenvolvimento apontam nessa direção:

Mais mudança, menos estabilidade. O relatório DORA de 2024, do Google, estimou que cada aumento de 25% na adoção de IA veio acompanhado de queda de 1,5% na vazão de entregas e de 7,2% na estabilidade. O relatório atribui o efeito ao abandono de fundamentos como lotes pequenos de mudança e testes robustos (Google Cloud, 2024).
A IA amplifica o que já existe. Em 2025, com quase 5 mil respondentes, o DORA passou a observar relação positiva entre adoção de IA e vazão de entregas, mas a relação com a estabilidade continuou negativa. A conclusão central do relatório é que a IA não conserta um time: fortalece os times que já funcionam bem e intensifica os problemas dos que não funcionam. O mesmo estudo afirma que a IA rende mais quando está apontada para um problema claro (Google Cloud, 2025).
A sensação de velocidade engana. Num experimento controlado do METR, no início de 2025, desenvolvedores experientes levaram 19% mais tempo para concluir tarefas com IA, embora acreditassem ter sido 20% mais rápidos. Os pesquisadores citaram como um dos fatores os projetos com muitos requisitos implícitos (METR, 2025). Com as ferramentas do fim de 2025, o próprio METR passou a medir ganhos pequenos, de 4% a 20%, e reformulou o estudo (METR, 2026).

O ponto comum é que a IA acelera a execução, e execução acelerada só gera economia quando a direção está certa. Com a direção errada, a empresa paga duas vezes: pelo código gerado e pela correção do que foi gerado, agora em maior volume.

O que uma especificação útil contém#

Especificar não significa produzir um documento de trezentas páginas. Uma boa especificação de funcionalidade cabe em poucas páginas e responde, sem ambiguidade, ao que um desenvolvedor ou um agente precisaria perguntar:

Problema e objetivo: que resultado de negócio a funcionalidade precisa gerar e como saber se gerou.
Quem usa e em que situação: os perfis de usuário e os momentos em que a funcionalidade entra em cena.
Regras de negócio com exemplos: cada regra acompanhada de casos concretos, com valores. “Desconto progressivo” é ambíguo; “acima de 10 unidades, 5% sobre o total” não é.
Critérios de aceite verificáveis: condições que permitem dizer sim ou não, sem interpretação.
Casos de exceção e erro: o que acontece quando o dado falta, quando a integração cai, quando o usuário faz o que não se esperava.
Fora do escopo: o que deliberadamente não será feito agora. É a parte que mais evita discussão depois.
Restrições: exigências legais, como a LGPD, desempenho, segurança e sistemas com os quais é preciso integrar.
Decisões em aberto: o que ainda não foi definido, com responsável e prazo. Uma decisão pendente registrada é muito melhor do que uma decisão escondida.

Ferramentas como o Spec Kit separam a especificação funcional, que diz o que e por quê, do plano técnico, que diz como. A separação ajuda a manter cada conversa com quem pode respondê-la: a área de negócio responde pela primeira, o time técnico pela segunda.

Especificar não é voltar ao modelo cascata#

A objeção mais comum ao spec-driven development é que ele traria de volta o desenvolvimento em cascata, com meses de documentação antes de qualquer entrega. Não precisa ser assim. A especificação pode ser feita por funcionalidade ou por incremento, no mesmo ritmo das entregas. O que muda é a regra de entrada: nada vai para o desenvolvimento, humano ou automatizado, sem estar especificado e acordado entre as áreas envolvidas.

Mudar de ideia continua permitido. A diferença é que a mudança passa a ser explícita: altera-se a especificação, registra-se o motivo e o código é refeito a partir dela. A conversa deixa de ser “o sistema não faz o que eu pedi” e passa a ser “decidimos mudar a regra por este motivo”.

Também é preciso proporção. Böckeler relata que, ao usar essas ferramentas para corrigir um defeito pequeno, recebeu quatro histórias de usuário e dezesseis critérios de aceite, um excesso para o tamanho do problema. Especificação detalhada se justifica onde há regra de negócio, integração ou risco. Para um ajuste de texto em uma tela, basta uma linha.

Por onde começar#

A adoção não exige trocar de ferramenta nem reorganizar a área. Alguns passos já mudam o resultado:

Escolha uma funcionalidade piloto com regras de negócio reais e mais de uma área envolvida. É onde a diferença aparece.
Faça a área de negócio e o time técnico revisarem a especificação juntos, antes de qualquer código. As divergências entre áreas aparecem nessa revisão, e não na homologação.
Guarde a especificação junto com o código, no mesmo repositório e com o mesmo controle de versões. Uma especificação desatualizada é quase tão ruim quanto nenhuma.
Adote uma regra simples de entrada: sem critério de aceite, a tarefa não entra no ciclo de desenvolvimento.
Meça o antes e o depois: quantidade de “evoluções” que corrigem algo já conhecido, retrabalho depois da homologação e taxa de falhas em produção, um dos indicadores acompanhados pelo DORA.

A IA reduziu o custo de transformar uma decisão em código. Não reduziu o custo de tomar a decisão, nem o de corrigir uma decisão errada já espalhada pelo sistema. Empresas que usam a IA para acelerar a parte que já era rápida, sem resolver a parte que sempre foi difícil, ganham velocidade justamente onde ela mais custa.

Inteligência artificial — Blog AreaCli