⚡ IA constrói rápido demais
A IA escreve mil linhas de código no tempo em que você lê três. Parece um superpoder, mas cria uma ilusão perigosa de progresso: confunde velocidade de digitação com profundidade de pensamento. O plano por trás daquele código nem sequer foi questionado.
🎯 O conceito central
Quando você pede "adicione expiração a links curtos" e a IA cospe 200 linhas em 15 segundos, é tentador aceitar. Mas o que ela acabou de fazer foi:
- •Escolher um esquema de armazenamento sem perguntar nada
- •Decidir o formato da data de expiração sem checar o resto do sistema
- •Ignorar como links já expirados se comportam em cache
- •Não pensar em rollback nem em métricas
📊 Exemplo prático: o teste dos 15 segundos
Cronometre. Peça à IA o seguinte numa conversa nova:
# Pedido típico
"Crie um sistema de notificações por email para nossa app."
Em geral, a IA entrega rápido. Mas observe o que ela não perguntou:
- • Qual provedor SMTP? (SendGrid, SES, Postmark, próprio?)
- • O que fazer se o envio falhar? (Retry? DLQ? Silenciar?)
- • Templates editáveis ou hardcoded?
- • Como respeitar opt-out de usuários?
- • Limite de taxa por usuário?
A IA deu uma resposta — mas não a resposta para o seu sistema.
💡 Dica prática
Se a IA respondeu com código antes de fazer pelo menos 3 perguntas sobre o seu contexto, o plano por trás é fraco. Não é falha da IA — é falha do processo. O Claudex existe pra forçar essas perguntas antes do código.
💸 O custo do retrabalho
Toda decisão fraca no plano vira correção dispendiosa na implementação. E quanto mais tarde você descobre, mais caro fica consertar — porque já tem código, testes, integrações e às vezes dados em produção amarrados àquela decisão.
📈 A curva clássica do custo de defeito
Pesquisa do IBM Systems Sciences Institute (clássica em engenharia de software):
- • Defeito encontrado no desenho/plano: 1× o custo
- • Defeito encontrado durante o desenvolvimento: 6.5× o custo
- • Defeito encontrado em QA/teste: 15× o custo
- • Defeito encontrado em produção: 100× o custo
Cada hora investida no plano economiza dezenas de horas depois.
📚 Exemplo real: a feature de expiração
Imagine que o time aceitou o plano superficial: "adicionar campo expires_at
na tabela de links". Implementa em 2 horas. Tudo lindo.
Semana 1: Cliente reclama que link continua funcionando depois de expirar. Investiga. Cache CDN não respeita expiração. +1 dia.
Semana 2: Outro cliente: "preciso renovar a expiração sem trocar a URL". Plano não previu. Migration nova. +2 dias.
Semana 3: Suporte recebe tickets de "link sumiu". Não há job de soft-delete; links expirados continuam ocupando índice. +3 dias.
Mês 2: Compliance pergunta sobre LGPD: links expirados precisam ser purgados em N dias? Não há política. +1 semana.
Total: ~2 semanas de retrabalho que um plano com 30 minutos a mais teria capturado.
🪤 Decisões frágeis e premissas quebradas
Toda decisão técnica carrega premissas implícitas: coisas que o autor do plano assumiu como verdade sem perceber. Quando uma dessas premissas é falsa, o plano não falha em um lugar — desaba inteiro, em cascata.
✗ Premissa quebrada
"Vamos chamar a API do parceiro de forma síncrona durante o checkout."
Premissa implícita: a API do parceiro responde rápido. Quando ela cai ou demora 30s, o checkout inteiro trava — e a perda de receita é proporcional.
✓ Premissa nomeada
"Assumimos disponibilidade de 99% da API parceira. Se cair: fila assíncrona com retry."
A premissa virou contrato visível. Se ela falhar, o plano tem uma resposta. O Codex força esse tipo de explicitação.
🔍 Como identificar premissas implícitas
Leia o plano e pergunte para cada decisão técnica:
- 1."O que precisa ser verdade pra isso funcionar?" — É uma premissa.
- 2."O que acontece se essa coisa não for verdade?" — É o risco.
- 3."Como saberíamos se ela parou de ser verdade?" — É a observabilidade.
Se as 3 não estão escritas no plano, ele tem premissas frágeis.
⚠️ Riscos ignorados
Plano fraco trata risco como categoria opcional. "A gente vê isso depois." Mas riscos não vistos não somem — eles aparecem em produção, no horário em que ninguém quer trabalhar, no cliente que não tolera erro.
🚨 Os 4 riscos que sempre ficam de fora
- 1. Concorrência: dois usuários fazendo a mesma operação ao mesmo tempo. Plano fraco assume serial.
- 2. Migração de dados: o que acontece com dados antigos quando o esquema muda? Backfill? Read fallback?
- 3. Rollback: se a feature precisar ser desligada às 3h da manhã, é uma flag, um deploy reverso, ou perdemos dados?
- 4. Observabilidade: sem métricas e logs específicos, o problema só aparece quando o cliente reclama.
📋 Exemplo: PLAN.md sem riscos
Veja o que um plano fraco escreve sobre uma feature de "notificações por email":
# PLAN.md (versão fraca) ## Etapas 1. Criar tabela notifications 2. Adicionar serviço EmailService 3. Disparar email no evento X 4. Testar manualmente
Quatro linhas. Zero riscos. Zero rollback. Zero métricas. Esse plano vai falhar.
🏃 O hábito de pular planejamento
Existe uma força gravitacional que empurra todo time a pular o plano e ir pro código. Não é preguiça — é viés cognitivo combinado com pressão de prazo. Reconhecer o padrão é o primeiro passo para quebrá-lo.
Viés de ação
Tendência psicológica
Cérebros humanos preferem fazer algo a parar pensar. Fazer dá sensação de progresso; pensar dá sensação de paralisia. O plano vira o "depois".
Pressão de prazo
Pressão organizacional
Stakeholder pergunta "tá pronto?" — e responder "ainda estou planejando" parece pior do que mostrar código quebrado. Mas é o oposto.
IA como acelerador do viés
Novo agravante
Se a IA já cospe código em 15 segundos, o "plano" parece desnecessário. O Claudex existe pra restaurar o passo de pensar — sem perder a velocidade.
🩺 Sintomas de plano fraco
Você não precisa ler o plano inteiro pra saber se ele é fraco. Existe uma checklist de sintomas visíveis que aparecem em praticamente todo plano que vai falhar. Aprender a reconhecer essa checklist é o radar prático do Claudex.
✗ Sintomas de plano fraco
- ✗Verbos vagos: "melhorar", "otimizar", "ajustar"
- ✗Sem critério de aceite mensurável
- ✗Sem seção de rollback
- ✗Sem métricas para validar sucesso
- ✗Não menciona dependências externas
- ✗Estimativas redondas demais (1 dia, 1 semana)
✓ Sinais de plano forte
- ✓Verbos específicos: "adicionar coluna X", "criar endpoint Y"
- ✓Critério de aceite com número ou comportamento exato
- ✓Plano de rollback explícito
- ✓Métricas e dashboards listados
- ✓Dependências e versões nomeadas
- ✓Riscos explícitos com mitigação
🧪 Teste rápido: 30 segundos pra avaliar um plano
Pegue qualquer PLAN.md e responda em 30 segundos:
- O plano define como saberemos que deu certo? (métrica/comportamento)
- O plano define como reverter se der errado?
- O plano lista pelo menos um risco com mitigação?
3 sins → plano forte. 2 ou menos → rode /claudex review.
💡 Dica prática
Imprima a checklist acima. Cole ao lado da tela. Toda vez que receber um plano da IA, passe os 6 itens. Se algum estiver faltando, você acabou de evitar uma semana de retrabalho com 30 segundos de inspeção.
📌 Resumo do Módulo
Próximo Módulo:
1.2 — 🤖 O que é o Claudex