Spec-Driven Development na prática

Durante muito tempo, "especificação" soava como algo pesado, de processos waterfall antigos. Hoje enxergo diferente: uma spec curta e bem escrita é o jeito mais barato de evitar retrabalho — principalmente quando parte do código passa a ser gerado com apoio de IA.

O problema que a spec resolve

Sem especificação, toda ambiguidade vira suposição silenciosa — do engenheiro ou do agente que está ajudando. E suposição silenciosa é a forma mais cara de bug: só aparece quando o código já está pronto (ou em produção).

Como estruturo uma spec

Objetivo — o que estamos construindo e por quê, em termos de resultado observável.
Critérios de sucesso — condições testáveis, não adjetivos ("mais rápido" vira "LCP < 2.5s").
Limites — o que sempre fazer, o que perguntar antes, o que nunca fazer.
Perguntas em aberto — assunções explícitas, para o time confirmar ou corrigir antes do código.

O ciclo que uso

Specify → Plan → Tasks → Implement, com validação humana entre cada fase. A spec não é descartada depois — ela é atualizada junto com o código, como documento vivo, e serve de referência para revisões futuras.

O ganho real

O tempo "perdido" escrevendo a spec quase sempre é menor que o tempo que se gastaria depurando uma decisão errada tomada cedo demais. Isso vale ainda mais quando parte da implementação é feita por um agente: a spec é o contrato que impede o time (humano ou IA) de resolver o problema errado com excelência.