🤐 O problema das suposições silenciosas
Toda instrução tem zonas de ambiguidade. O LLM, treinado para ser prestativo, escolhe uma interpretação em silêncio e segue. Você descobre qual interpretação só quando o código chega — geralmente errado.
🎯 O conceito central
Karpathy diz: "Os modelos fazem suposições erradas em seu nome e simplesmente seguem em frente sem checar."
A solução não é o LLM "adivinhar melhor" — é forçar a suposição a virar texto, antes do código.
✗ Comportamento típico (ruim)
LLM: [escolhe Redis, TTL 5min, chaves por user]
[escreve 300 linhas]
Você queria um simples lru_cache in-memory. Refactor inteiro.
✓ Comportamento corrigido
LLM: "Antes de implementar:
1. Escopo: 1 função ou app todo?
2. Local: in-memory ou Redis?
3. TTL: existe?"
30 segundos do user, evita 30 min de retrabalho.
📊 Os 3 sintomas da suposição silenciosa
- Sintoma 1: O LLM começa direto pelo código, sem nenhuma pergunta.
- Sintoma 2: A primeira linha de explicação assume detalhes que você não deu.
- Sintoma 3: Aparecem dependências, libs ou paths que não foram mencionados no pedido.
Custo escondido
Retrabalho médio: 3x o tempo de implementação original.
Sinal vermelho
"Já implementei!" sem nenhuma pergunta = quase certeza de suposição cega.
Quem perde
O reviewer humano que precisa caçar o que mudou e por quê.
📝 Declarar suposições explicitamente
Antes de qualquer código, liste as suposições adotadas. O usuário deve poder corrigi-las antes de ver um diff.
💡 Template "Antes de codar"
🔧 Como instruir no CLAUDE.md
Listar antes de fazer
"Vou assumir X, Y, Z" antes de qualquer linha de código.
Aguardar feedback
Em tarefa não-trivial, pausar e esperar "ok" antes de codar.
Atualizar se mudar
Se durante a implementação a suposição se mostrar errada, parar e avisar.
Custo
30 segundos
Economia
~30 minutos / retrabalho
Reversibilidade
Total — nada foi escrito ainda
Quando pular
Mudança trivial / typo
🔀 Apresentar interpretações múltiplas
Quando o pedido é genuinamente ambíguo, em vez de escolher uma rota silenciosamente, apresente 2-3 caminhos e deixe o usuário escolher de forma consciente.
📋 Exemplo prático
Pedido: "Adiciona suporte a múltiplos idiomas"
✓ Quando usar interpretações
- ✓Termos vagos: "melhorar", "otimizar", "limpar"
- ✓Escopo indefinido: "no projeto inteiro" ou "neste arquivo"?
- ✓Múltiplas implementações canônicas existem
- ✓Custo das opções varia significativamente
✗ Quando NÃO usar
- ✗Pedido já tem uma resposta óbvia única
- ✗Inventar ambiguidade onde não existe
- ✗Mais de 4 opções (vira paralisia de decisão)
- ✗Listar opções e recomendar a errada como "primeira"
💡 Dica de ouro
Sempre marque sua recomendação. Listar 3 opções sem indicar qual você acha melhor empurra a decisão de volta pro usuário sem ajudar. "Recomendo A pelo escopo enxuto, mas se você quer X, vai de B."
⚖️ Discordar quando faz sentido
O LLM não é um yes-man. Se você pede algo subótimo e existe um caminho mais simples, mais seguro ou mais barato — ele deve apontar antes de obedecer.
🎯 Pushback construtivo
Discordar não é negar a tarefa. É um aviso curto antes de continuar:
Discordar de performance
"Você pediu otimização aqui, mas o gargalo real está em X — o ganho deste loop é negligível."
Discordar de escolha técnica
"Você pediu Redux para esse estado, mas é estado local — useState resolve com 1/10 do código."
Discordar de segurança
"O endpoint que você pediu expõe dados privados sem auth. Posso adicionar middleware antes de seguir?"
⚠️ Atenção ao discordar
Pushback ≠ teimosia. Regras:
- • Aponte uma vez, não cinco.
- • Se o usuário confirma, execute sem reclamar mais.
- • Nunca discorde sem ter uma alternativa concreta em mãos.
Tom
Coautor sênior, não obstrutor
Frequência
Só quando há ganho real
Encerramento
"Sigo com X?" — devolve decisão
🛑 Parar quando estiver confuso
Quando algo não fecha, o LLM deve nomear o que não está claro e perguntar. Preencher os buracos com palpite gera bugs invisíveis.
✗ Confusão escondida
(LLM nunca viu getUser, está chutando que existe)
Resultado: import quebrado, bug que aparece em runtime.
✓ Confusão nomeada
Você pode confirmar o nome dela ou o path?"
Resultado: 1 pergunta, 0 bugs.
📊 Os 4 tipos de confusão a nomear
- 1. Existência: "Não achei o arquivo/função X — onde está?"
- 2. Comportamento: "Quando input é vazio, deve retornar [] ou null?"
- 3. Escopo: "A mudança vale para esse arquivo só ou para todos os similares?"
- 4. Prioridade: "Você quer performance ou simplicidade aqui?"
💡 Regra dos 2 minutos
Se a confusão é resolvível por busca/leitura em até 2 min, o LLM tenta sozinho primeiro. Acima disso, pergunta. Não deixar isso difuso vira a maior fonte de erro.
🗺️ Mapear tradeoffs antes da escolha
Toda decisão técnica tem um custo. Listar prós e contras antes de implementar transforma escolha em decisão consciente, e a torna reversível mais tarde.
📋 Template de tradeoff
✓ Tradeoffs úteis
- ✓Tem impacto a longo prazo
- ✓Decisão custosa de reverter depois
- ✓O usuário tem contexto que o LLM não tem
✗ Tradeoffs inúteis
- ✗Sobre detalhes irrelevantes (nome de variável)
- ✗Quando uma opção é obviamente melhor
- ✗Sem recomendação — paralisia pra o usuário
🎯 Reversibilidade barata
Tradeoff documentado = decisão reversível. Daqui 6 meses, alguém vai ler "fomos com A porque B custava muito setup" e saber se ainda é verdade ou se já mudou.
📝Resumo do Módulo
Próximo Módulo:
1.2 — ✂️ Simplicidade Primeiro