Chamar todo mundo sempre é o jeito mais caro de entregar
Por William Pereira ·
Times que levam qualidade a sério caem num extremo: ou sempre disparam o ritual completo (product, arquitetura, security, todos os reviewers), ou nunca disparam e torcem. Os dois são caros — um em tempo de gente e de modelo, o outro em incidente.
A alternativa é separar filtro barato de julgamento caro. Um roteador (script, regras explícitas, sinais no pedido ou no diff) decide se o caminho é lean ou full. O floor de qualidade não muda; muda quem você acorda.
Sempre-full vs roteado
| Sempre o ritual completo | Roteador + floor | |
|---|---|---|
| Chore tipográfico | Mesma orquestração de uma feature de auth | Caminho curto, mesmos checks mínimos |
| Feature com dados sensíveis | Igual ao chore (ou improvisado) | Sobe perfil completo por gatilho de risco |
| Custo marginal | Alto em tudo | Alto só com evidência |
| Risco de atalho | Baixo no papel, alto por fadiga | Controlado se o floor for real |
Por que isso não é só otimismo de processo
Em operações e em produto, triagem existe há décadas: não se escala o especialista no primeiro sinal. Em software — sobretudo com assistência de modelos — o custo do “especialista” (humano sênior ou agente pesado) ficou visível demais para fingir que orquestração uniforme é neutra.
A literatura de custo de defeito tardio (Boehm; síntese de McConnell) justifica não economizar no que é ambíguo ou arriscado. O roteador justifica economizar no que já está bem especificado e sem gatilho de risco. São faces da mesma moeda: gastar julgamento onde o erro é caro.
O cuidado que separa engenharia de teatro: lean nunca significa pular teste ou pular o review mínimo. Significa não convocar papéis cujo domínio nem aparece no trabalho.
Prós
- Menos fadiga de processo em mudanças pequenas.
- Risco e ambiguidade continuam caros — de propósito.
- Funciona com ou sem agentes: o filtro pode ser checklist humano.
- Deixa explícito o que é política (floor) e o que é otimização (skip).
Contras
- Gatilhos mal escritos classificam errado (falso lean ou falso full).
- Sem floor explícito, “roteador” vira desculpa para atalho.
- Exige manutenção: lista de riscos e sinais precisa evoluir com o produto.
- No começo, o time discute a tabela de gatilhos — isso é trabalho, não overhead acidental.
Na prática
Escreva numa página compartilhada: (1) sinais de caminho lean — regras presentes, testes mínimos, ausência de auth, dados sensíveis ou migração de schema; (2) sinais de full — o inverso; (3) floor inegociável — lint do pedido, N cenários, pelo menos um revisor do domínio tocado.
Automatize o filtro quando a tabela estabilizar. Até lá, um humano aplica a mesma tabela em poucos minutos no início da sessão. Revise os falsos positivos na retro: lean demais que quebrou produção, ou full demais em chores, ambos ensinam.
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.