Pare de gastar a sprint no escuro: o contrato que vem antes do código
Por William Pereira ·
O pedido chega incompleto: “faz o export”. Alguém implementa. Na demo surgem as perguntas que deveriam ter vindo antes — limites, permissões, falhas. O código não estava errado demais; o contrato é que nunca existiu.
Discovery fail-closed é a ideia simples: uma mudança só entra em “pronta para construir” quando regras, critérios e cenários de teste passam num gate mecânico. Se o gate falha, refina-se o pedido — não se promove “para andarmos”.
Isso vale com ou sem IA. Com IA, o custo de gerar código caiu; o custo de gerar a coisa errada continua alto. Sem contrato, você só acelera o retrabalho.
Com contrato vs sem contrato
| Sem contrato explícito | Com discovery fail-closed | |
|---|---|---|
| Entrada | Frase no chat do time | Regras + aceites + cenários testáveis |
| Definição de pronto | Demo subjetiva | Cenários falsificáveis |
| Quando o retrabalho aparece | No meio da implementação | No lint do pedido |
| Handoff | “Olha o histórico” | Registro canônico que o time lê igual |
| Spikes | Misturados com entrega | Explícitos: fora do gate ou convertidos depois |
O que a literatura ajuda a justificar
A curva clássica de custo de mudança, popularizada por Barry Boehm, aponta na mesma direção: defeitos de requisito descobertos tarde tendem a custar bem mais do que os corrigidos perto da origem. Steve McConnell resume a intuição industrial — prevenção cedo — e discute faixas altas reportadas na indústria para requisitos que escapam até o campo, sempre com a ressalva de que o multiplicador depende do contexto.
Boehm e Victor Basili, ao revisitarem o tema, acrescentaram nuance: em sistemas pequenos e não críticos a razão pode ficar bem menor do que o mito do “sempre cem vezes”. A direção, porém, permanece: errar cedo é mais barato que errar na demo. Leituras úteis: An Ounce of Prevention (McConnell) e o artigo de Boehm e Basili sobre redução de defeitos (“Software defect reduction top 10 list”).
Isso não exige waterfall nem documento de cento e páginas. Exige um artefato mínimo falsificável antes de gastar a sprint — o oposto de especificação eterna e o oposto de “código é a especificação”.
Prós
- PO, TL e dev discutem o mesmo texto.
- Retrabalho de ambiguidade sobe para o início, onde é mais barato.
- Bugs e chores podem usar trilhas mais leves; features ambíguas pagam o gate completo.
- O gate mecânico tira da conversa o “está quase ready”.
Contras
- Escrever regras boas custa tempo upfront.
- Gate fraco (campos cosméticos) vira teatro.
- Urgências políticas vão odiar o “não passou” — precisa patrocínio de liderança.
- Times que nunca praticaram aceite vão achar o lint “burocrático” no começo.
Na prática
Defina um template curto: tipo, severidade, regras de negócio, aceites e uma lista de testes no formato “dado → resultado”. Um script ou checklist humano falha se faltar campo ou se a severidade média não tiver o mínimo de cenários. Só então abre-se branch.
Exemplo mental: “filtro por data na listagem” sem contrato deixa timezone e inclusividade do intervalo para a demo. Com contrato, isso está escrito e tem pelo menos um cenário de erro. Spikes de meio dia podem ficar de fora do gate — desde que o time admita, em voz alta, que ainda não há contrato.
Se quiser ver uma implementação open source desses padrões — que mantenho e uso no dia a dia — o repositório está em github.com/pereirawe/codex-flow.