FLUXO DE TRABALHO ORIENTADO POR ESPECIFICAÇÃO CLAUDE
O fluxo de trabalho exato de três etapas que executo em toda construção assistida por Claude. Do brainstorm à especificação à implementação, com os gates que detectam falhas cedo.
Por que especificação orientada importa
A geração de código com Claude é rápida o suficiente para que o gargalo não seja mais digitar. O gargalo é saber exatamente o que você quer antes de Claude escrever. O fluxo de trabalho orientado por especificação coloca o pensamento na frente para que a fase de implementação se torne execução em vez de exploração.
Os times que entregam bem com Claude são os que construíram disciplina de especificação antes das ferramentas de IA existirem. Os times que têm dificuldades são os que tentam pular a especificação pedindo para Claude descobrir.
Etapa 1: brainstorm estruturado
Descrevo o problema para Claude em três ou quatro frases. Depois peço para Claude expor cinco questões cujas respostas mudariam o design. Respondo a elas. Depois peço para Claude resumir a especificação de produto resultante em 200 palavras.
Essa etapa leva de 30 a 60 minutos e produz um documento de especificação do qual flui todo o trabalho restante. As cinco perguntas são geralmente aquelas que eu teria pulado se fosse direto para o código; surfá-las via etapa de brainstorm é todo o valor.
Etapa 2: decisões técnicas
Com a especificação em mãos, peço ao Claude que identifique as escolhas de arquitetura com maior alavancagem downstream. Formato do banco de dados, superfície da API, estratégia de renderização, modelo de deployment. Para cada uma, Claude propõe duas ou três opções com trade-offs.
Eu escolho. As decisões vão no mesmo documento para que a fase de build tenha uma única fonte de verdade. Decisões tomadas nessa etapa são 10x mais baratas de revisar do que decisões descobertas durante a implementação.
Etapa 3: implementação orientada por spec
Geração de código é a última etapa e é a mais rápida porque a spec já está completa. Claude escreve o schema, as queries, os componentes, as rotas, os testes, nessa ordem aproximadamente. Eu reviso cada commit.
A maioria das revisões surfam um pequeno refactor ou um edge case faltando; reescritas completas são raras quando a spec foi clara. O ritmo é de duas a cinco vezes mais rápido do que engenharia sem ajuda em trabalho greenfield.
Os gates que capturam falhas
Três gates de revisão entre brainstorm e código shipped:
Gate de spec: antes de qualquer código ser escrito, a spec de 200 palavras é lida de cima a baixo. Qualquer coisa ambígua é clarificada. Qualquer coisa aspiracional é cortada.
Porta de arquitetura: antes de qualquer migração de banco de dados ser executada, as decisões arquiteturais são revisadas contra a especificação. Qualquer coisa que não atenda à especificação é reconsiderada.
Porta de commit: todo commit criado por Claude passa por revisão humana antes de ser mesclado. A revisão é mais rápida do que escrever o código você mesmo, mas é obrigatória. Claude não aprova seus próprios pull requests.
Quando spec-driven não funciona
Trabalho exploratório ou em forma de pesquisa, onde o objetivo é aprender o que é possível em vez de construir algo conhecido. Para estes, a fase de especificação produz specs vagas que restringem Claude de forma contraproducente. Chat iterativo com artefatos concretos é o padrão correto.
Correções de bugs onde a causa é desconhecida. A fase de especificação assume que você conhece o destino; debugging é descobrir onde você está. Para debugging, vá direto ao padrão de debugging sistemático (reproduzir, isolar, diagnosticar, corrigir) e pule a especificação.
Polimento de UI onde cada iteração é pequena e o feedback visual é o sinal. Para estes, Claude em Cursor com hot reload e diff lado a lado é a ferramenta certa, não uma especificação escrita.