Desenvolvedor Troca Especificações por Propostas para Sessões de Código Paralelas do Claude

O Problema com a Abordagem de Especificações Primeiro

O desenvolvedor encontrou problemas em que escrever especificações detalhadas antecipadamente levava a código gerado por IA que era tecnicamente correto, mas contextualmente errado. A especificação diria "adicionar limitação de taxa aos endpoints de autenticação", mas não incluiria contexto sobre abordagens previamente rejeitadas (como baldes de token) ou decisões de implementação (como escolher Redis em vez do Cloudflare para staging). Isso criava situações em que a IA fazia escolhas razoáveis que reabriam decisões já fechadas.

Atualizar especificações tornou-se seu próprio mini-projeto, e quando as especificações atualizadas eram revisadas, a base de código já havia divergido. A especificação capturava o "o quê", mas perdia o "porquê"—todo o raciocínio, alternativas rejeitadas e o momento das decisões estavam faltando.

A Alternativa de Propostas Primeiro

Em vez de escrever especificações antecipadamente e codificar para corresponder a elas, o desenvolvedor escreve propostas—documentos curtos que capturam por que uma mudança está acontecendo, o que foi considerado e rejeitado, e o que está dentro ou fora do escopo. A especificação é atualizada após o código ser implementado para refletir o que realmente foi construído.

Exemplo de comparação:

• Uma especificação diz: "O sistema deve suportar limitação de taxa."
• Uma proposta diz: "Ataques de força bruta detectados em produção. Adicionando limitação de taxa via janela deslizante + Redis (Cloudflare não disponível em staging). Rejeitado balde de token devido a problemas de tráfego em rajada. Escopo: apenas login + redefinição de senha."

A proposta dá à IA (e aos futuros desenvolvedores) o quadro completo.

Fluxo de Trabalho de Propostas Paralelas

O desenvolvedor executa várias sessões do Claude Code simultaneamente, cada uma trabalhando em uma proposta diferente. Às vezes, ele cria propostas concorrentes resolvendo o mesmo problema de ângulos diferentes.

Fluxo de trabalho típico:

• Trabalhando em 2-3 funcionalidades/bugs/problemas ao mesmo tempo
• Criando 1 ou 2 propostas para abordagens diferentes por problema
• Iniciando sessões do Claude Code para cada proposta para executar em paralelo
• Cada sessão produz um PR no GitHub
• PRs do GitHub servem como plataforma de revisão de propostas
• Revisando abordagem e código juntos
• Se duas propostas abordam o mesmo problema de forma diferente, escolhendo a melhor e fechando a outra
• Uma vez que os PRs aprovados são implementados, instruindo o Claude a implementar as propostas
• Atualizando a especificação para refletir as mudanças de código para referência rápida em propostas futuras

A especificação se torna um documento vivo que sempre corresponde à realidade, em vez de um documento aspiracional que diverge desde o primeiro dia.

Ciclo PACE

O desenvolvedor chama esse ciclo de PACE (para lembrar os passos):

• Propor: Escrever uma proposta curta com contexto e raciocínio
• Aprovar: Revisar no PR do GitHub, abordagem (aprovar, revisar, rejeitar)
• Codificar: A IA implementa exatamente o que foi proposto, nada mais
• Evoluir: Atualizar a especificação para refletir a nova realidade