Spec-driven development vale a pena no seu time? Como avaliar a recomendação antes de adotar

Fala aí, beleza? Uma consultoria grande colocou spec-driven development no radar dela e, do nada, alguém do time chegou dizendo que agora é assim que a gente vai trabalhar

Aí começa a confusão

Porque recomendação de consultoria não é decreto, é entrada de investigação

Este post não é resumo do que foi publicado por lá, é sobre a DECISÃO: cabe no seu time, no seu tipo de projeto, com o seu custo de processo? E se liga que a leitura do anel muda tudo, o mesmo relatório que "recomenda" diz explicitamente que a coisa é pra explorar, não pra padronizar

O que a consultoria realmente recomendou (Assess não é Adopt):

Primeiro a definição, direto da fonte

A Thoughtworks descreve spec-driven development como fluxos de codificação assistida por IA que começam por uma especificação funcional estruturada e seguem quebrando aquilo em partes menores, soluções e tarefas

O fluxo típico é spec, plan, implement

E a especificação pode ser um documento único, um conjunto de documentos ou artefatos estruturados, não existe formato sagrado

Agora a parte que quase ninguém lê antes de sair anunciando na daily: a técnica está no anel Assess (Avaliar), na categoria Techniques

E o que é o anel Assess? É o anel que significa "vale explorar para entender como afeta sua empresa"

Não é Adopt

A diferença entre os dois é a diferença entre "testa com escopo controlado e me conta" e "isso é o padrão da casa"

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O contexto do volume que trouxe o assunto:

O volume 34 do Technology Radar saiu em 15 de abril de 2026, e o tema central dele é cognitive debt (dívida cognitiva) causada pela geração acelerada de código por IA

Um dos quatro temas do volume tem até nome de piada boa: "putting coding agents on a leash", colocar agentes de código na coleira

Sacou o clima? O assunto entrou na pauta como resposta a um problema (código saindo rápido demais e ninguém entendendo o que foi gerado), não como "a nova metodologia definitiva"

A ressalva já vinha do volume anterior:

O volume 33, de novembro de 2025, já registrava o alerta de superespecificação: a prática empurra você a predefinir tudo de antemão, gerando arquivos demais e difíceis de manter

Ou seja, a mesma casa que põe a técnica no radar aponta o jeito clássico de ela dar errado

E tem mais: ao falar do GitHub Spec Kit, a Thoughtworks relata dois campos entre os próprios times dela, quem confia na capacidade crescente dos agentes com estrutura mínima e quem prefere fluxos definidos com especificações detalhadas

Se a consultoria que recomendou não tem consenso interno, você adotar como política obrigatória é queimar largada

O método pra ler qualquer recomendação assim:

1. Ache o anel (Assess, Adopt, Trial, Hold) antes de ler a manchete, é ele que diz o que fazer
2. Ache a data e o volume, prática de IA envelhece em meses
3. Ache a ressalva, quase sempre ela está no mesmo parágrafo e é ela que descreve o seu risco
4. Ache se existe divergência interna relatada, isso te dá permissão pra discordar com educação

O erro comum aqui é ler o print do LinkedIn e não a página original

Três critérios para testar se SDD cabe no seu contexto:

Beleza, e como você decide sem depender do que a consultoria achou?

Três critérios, cada um com evidência pública por trás

Critério 1: que tipo de projeto você tem na mão?

Os experimentos dos times da Thoughtworks com o Spec Kit aconteceram majoritariamente em brownfield, sistemas que já existem

Isso importa MUITO

Em base existente, o gargalo do agente não é criatividade, é contexto: qual a estrutura do repo, qual versão de cada tecnologia, qual padrão de código a casa segue

Especificação estruturada resolve exatamente esse tipo de dor

No greenfield puro, com projeto pequeno, o mesmo processo pode virar burocracia sobre um problema que não existe ainda

Critério 2: quanto custa o processo em si?

Aqui entra o contraponto honesto

A consultoria Scott Logic publicou uma avaliação prática do Spec Kit com o título Putting Spec Kit Through Its Paces: Radical Idea or Reinvented Waterfall?, e o relato foi de "um mar de documentos markdown, longos tempos de execução do agente e atrito inesperado"

O autor estimou ser cerca de dez vezes mais rápido com prompting iterativo simples do que com o pipeline completo de especificação

Esse número não invalida a técnica, mas te dá a pergunta certa pro seu piloto: o que exatamente eu ganho que pague o tempo de escrever e manter esses documentos?

Se a resposta for "sei lá, mas parece mais organizado", tu ainda não tem critério, tem sensação

Critério 3: você tem sistema de controle ou só velocidade?

O relatório DORA 2025 (State of AI-assisted Software Development) mostra adoção quase universal: 90% dos respondentes usam IA no trabalho

A confiança, porém, é outra história: 30% relatam pouca ou nenhuma confiança no código gerado por IA, contra 24% que relatam muita confiança

E o dado que fecha o raciocínio: a adoção de IA passou a se correlacionar positivamente com throughput (uma reversão em relação a 2024), mas mantém relação NEGATIVA com a estabilidade da entrega

Sem testes automatizados fortes, controle de versão maduro e feedback rápido, o aumento de volume de mudanças gera instabilidade, e ponto

O DORA ainda publicou um relatório complementar sobre retorno financeiro de desenvolvimento assistido por IA (edição 2026.01), apontando que os ganhos vêm dos fundamentos de engenharia e do sistema organizacional, não da ferramenta em si

Traduzindo pro seu caso: se o time não tem teste nem pipeline confiável, adotar SDD não conserta isso, só organiza melhor o caminho até o problema

Spec Kit, OpenSpec e Kiro: qual peso de processo cada um cobra:

As três opções que aparecem no debate cobram preços diferentes de processo e de acoplamento

Se liga na comparação:

Spec Kit: o mais completo e o mais pesado:

O github/spec-kit é distribuído pelo pacote specify-cli no PyPI e a instalação recomendada usa o uv

O --integration aceita outros agentes além do Claude, tipo copilot e gemini, e os scripts vêm em sh, ps ou py via --script

O conceito central dele é a constitution, um conjunto de regras fundacionais do projeto

Segundo os times da Thoughtworks, uma constitution útil captura escopo do projeto, contexto de domínio, versões de tecnologia, padrões de código e estrutura do repositório (por exemplo arquitetura hexagonal ou módulos em camadas)

Os comandos rodam como slash commands do agente: /speckit.constitution, /speckit.specify, /speckit.clarify, /speckit.plan, /speckit.checklist, /speckit.tasks, /speckit.analyze e /speckit.implement

Depois do specify init, esses arquivos vão pro diretório de comandos do agente (no Claude Code, .claude/commands/)

Oito comandos é bastante processo, e é justamente daí que vem a crítica do "mar de markdown"

OpenSpec: o oposto, processo enxuto:

O Fission-AI/OpenSpec segue a linha contrária

Três passos (propose, apply, archive), foco em deltas de especificação em vez de especificar tudo de uma vez, e sem exigir IDE específica

Se a sua dor é a superespecificação apontada no volume 33, essa é a abordagem que responde direto à ressalva

Kiro: fluxo guiado, dentro da casa:

O Kiro, da Amazon, conduz o usuário por três estágios: requisitos, design e criação de tarefas

É a experiência mais mastigada das três, e também a que te prende mais ao ambiente dela

Se você quer entender esse fluxo em detalhe antes de comparar, dá uma olhada em como o Kiro organiza spec, plano e tarefas

A régua que ajuda a comparar tudo isso:

Birgitta Böckeler, Distinguished Engineer da Thoughtworks, publicou no martinfowler.com o artigo Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl, em 15 de outubro de 2025

Ela descreve três níveis de implementação: spec-first, spec-anchored e spec-as-source

Use isso como régua pra decidir quanto a especificação manda no seu projeto

Spec como ponto de partida é uma coisa, spec como fonte da verdade do sistema é outra bem diferente, e o custo de manutenção sobe junto

O que aconteceu quando testei o fluxo no meu projeto:

No vídeo abaixo eu monto o fluxo inteiro na mão, sem framework nenhum, pra mostrar que o método vale independente da ferramenta

Montei três documentos: requisitos, design e tarefas, pra um app de QR code

O documento de requisitos começa pela visão geral e vai detalhando cada funcionalidade (geração sem login, personalização, autenticação, dashboard)

E tem uma parte que eu insisto muito: escrever o que o projeto NÃO faz

Sem analytics, sem QR code dinâmico, sem logo no QR, sem API pública, sem plano pago

Isso existe justamente pra IA não inventar feature que ninguém pediu

O documento de design é onde entra o técnico de verdade, definir a stack e o que cada página faz

E ele engana pelo nome, viu? Parece que é só cor e estilo, mas o visual não é a parte mais importante dali

O de tarefas é a ordem de execução seguindo a lógica de uso: setup inicial (pastas e bibliotecas), depois autenticação por ser complexa e vital, depois a geração do QR code, salvar QR pra quem está logado, dashboard

E deixo sempre uma tarefa final de polimento pra aparar arestas, onde cabem verificações de segurança, performance e acessibilidade

Os números da minha rodada:

Usei o Claude Code por ser o agente que mais uso hoje, mas o método serve pra qualquer agente de programação

O agente implementou a autenticação em cerca de 2 minutos

Pra comparar: já peguei início de projeto sem SDD que passou de 10 minutos só pra sair do lugar

O projeto subiu na porta 3002 e eu testei na prática: gerei o QR em tempo real, baixei o PNG, escaneei, caiu no meu site, depois testei o login e ele autenticou direto

O que mais me chamou atenção foi o ritmo: a parte inicial demorou mais e as tarefas seguintes saíram rápido

Depois do planejamento, os prompts ficam mais simples, o custo grande fica lá na frente e a execução vira algo previsível e sequencial

A regra que eu uso pra decidir:

Se o projeto passa de três prompts, ou se eu já sei de cara que vai ter autenticação, pagamento, usuário admin e usuário comum, dashboard, provavelmente vale o SDD

Abaixo disso? Vibe coding normal resolve

Projeto pessoal que ninguém vai usar talvez nem precise, porque planejar gasta mais token e faz o modelo raciocinar mais

E olha, meu relato positivo e o relato de dez vezes mais lento da Scott Logic não se contradizem, eles convivem

Contexto diferente, escopo diferente, peso de processo diferente

É exatamente por isso que o critério tem que ser SEU

Veredito: adotar, avaliar ou ignorar por enquanto?

Veredito honesto, por perfil

Avalie de verdade (rode um piloto com escopo fechado) se você mexe em base existente e o projeto passa de alguns prompts

É o cenário mais próximo do que a Thoughtworks relatou nos experimentos dela, brownfield, onde o contexto do repositório é o gargalo real

Adie se o seu trabalho é curto e iterativo, tipo ajuste pontual, script, protótipo descartável

O overhead de documento come o ganho, e a avaliação da Scott Logic mostra que isso não é teoria

Não torne obrigatório pro time inteiro enquanto a técnica está em Assess e a própria consultoria relata dois campos internos divergindo

Política de time se escreve depois da evidência, não antes

O que medir no piloto pra decidir sozinho:

1. Tempo total até a primeira feature funcionando, contando o tempo de escrever a especificação (não vale medir só a execução, é aí que todo mundo se engana)
2. Quantidade de retrabalho: quantas vezes você teve que voltar e corrigir o rumo do agente em cada abordagem
3. Custo de manutenção dos documentos depois de duas ou três mudanças de requisito, esse é o teste da ressalva de superespecificação
4. Estabilidade: quebrou o que já funcionava? Esse é o ponto que o DORA levanta, e sem teste automatizado você nem consegue responder
5. Onboarding: alguém que não escreveu a spec consegue continuar o projeto lendo ela?

O erro comum deste passo é rodar o piloto sem baseline, ou seja, sem fazer nada do jeito atual pra comparar

Sem os dois lados, qualquer resultado vira opinião

E se o piloto der certo e você quiser repetir o fluxo sem recriar tudo do zero toda vez, dá pra empacotar isso numa skill de spec-driven development reusável

Conclusão:

Recomendação de consultoria é entrada de investigação, não decreto

A técnica está em Assess, o volume que a trouxe pro debate fala de dívida cognitiva e de colocar agente na coleira, o volume anterior já avisava do risco de superespecificar, e os times da própria casa que recomendou estão divididos

Isso tudo junto tem um nome: sinal pra testar, não pra padronizar

Seu próximo passo é bem concreto

Escolhe UM projeto real que passe da sua régua de tamanho, roda um único fluxo completo com uma das ferramentas (Spec Kit se você quer o processo cheio, OpenSpec se você quer o mínimo), compara com o seu jeito atual usando aquelas cinco medidas

Depois disso, sim, você escreve política de time

Com evidência do seu contexto, não com print de relatório alheio 😀

até o próximo post!