MÓDULO 1.4

🎯 Execução Orientada a Meta

Transforme instruções imperativas em critérios verificáveis. Critérios fortes deixam o LLM iterar sozinho até bater a meta. Critérios fracos exigem clarificação a cada passo.

6
Tópicos
30
Minutos
Médio
Nível
Prática
Tipo
1

🔀 Imperativo vs declarativo

A diferença sutil entre "faça X" e "X deve passar". Imperativo manda fazer. Declarativo dá um critério de parada.

🎯 Karpathy disse

"LLMs são excepcionalmente bons em looping até bater uma meta específica... Não diga o que fazer, dê critérios de sucesso e assista."

✗ Imperativo (frágil)

"Adiciona validação no formulário"

O LLM não sabe quando parou. Adicionou alguma validação ≠ resolveu o problema.

✓ Declarativo (sólido)

"Esses 4 testes devem passar:
- email vazio → erro
- email inválido → erro
- senha <8 → erro
- válido → submit"

Critério binário. Passou = pronto.

📋 Transformações comuns

✗ "Corrige o bug" → ✓ "Esse teste reproduz o bug, faça passar"
✗ "Refatora X" → ✓ "X menor que 50 linhas, testes passando antes e depois"
✗ "Otimiza" → ✓ "Tempo de execução abaixo de 200ms para esse input"
✗ "Adiciona logs" → ✓ "Esses eventos aparecem no log: X, Y, Z em nível info"
2

🧪 Testes-primeiro como critério

A forma mais barata de garantir que o entregue resolve o que foi pedido: pedir os testes antes. O LLM escreve teste, vê falhar, implementa até passar.

R

Red — escreve o teste que falha

"Escreva o teste para o comportamento desejado. Rode. Confirme que falha (porque ainda não está implementado)."

G

Green — implementa até passar

"Implemente o mínimo necessário para o teste passar. Não mais, não menos."

R

Refactor — limpa mantendo verde

"Agora simplifique a implementação. Os testes continuam passando? Pronto."

💡 Por que funciona com LLM

O teste é uma spec executável. O LLM não precisa interpretar texto vago — ele tem um sinal claro: passou ou falhou. Loop fechado.

3

🔁 O loop autônomo

Com critério verificável, o LLM pode rodar testes, ajustar, rodar de novo — sem intervenção a cada iteração. É a superpotência dos agentes modernos.

🎯 Anatomia do loop

while not criterio_atendido: implementa_proximo_pedaço() roda_testes() if falhou: analisa_erro() ajusta() else: avança_pra_próximo_step()

✓ Condições pro loop funcionar

  • ✓Teste rápido (segundos, não minutos)
  • ✓Mensagem de erro clara
  • ✓Critério binário (passa/falha)
  • ✓Limite de iterações (5-10 max)

✗ Quando o loop trava

  • ✗Teste flaky (passa/falha aleatório)
  • ✗Erro vago: "something went wrong"
  • ✗Sem limite — pode loop infinito
  • ✗Critério subjetivo: "ficou bom"

📊 Custo do loop

Cada iteração consome tokens. Vale a pena se a tarefa exige iteração genuína. Não vale para coisa trivial — vira overkill.

4

📊 Critérios fortes vs fracos

"Faz funcionar" não é critério. É vibes. Critério bom é mensurável, binário, e descreve um fim claro.

✗ Critérios fracos

  • • "Funciona bem"
  • • "Está limpo"
  • • "Performance ok"
  • • "Cobertura razoável"
  • • "Que pareça profissional"

Todos subjetivos. LLM não consegue verificar.

✓ Critérios fortes

  • • "npm test passa, 0 failing"
  • • "Função abaixo de 30 linhas"
  • • "Latency < 200ms para input N=1000"
  • • "Coverage ≥ 80% nesse módulo"
  • • "lint passa sem warnings"

Todos mensuráveis. LLM consegue rodar e verificar.

💡 Teste SMART para critérios

Antes de mandar pro LLM, seu critério é:

  • Specífico — não "funciona", mas "comando X retorna Y"?
  • Mensurável — dá pra rodar e ver passa/falha?
  • Atingível — está no escopo da tarefa?
  • Relevante — resolve o problema real?
  • Time-bound — tem ETA / limite de iterações?
5

🗺️ Planos com verificação por passo

Para tarefas com múltiplos passos, cada passo deve ter um critério de "passou" antes de seguir. Sem checkpoints, erros se acumulam até o fim.

🔧 Formato de plano com checkpoints

1. Criar tabela `users` com schema X → verify: `db.tables.list()` inclui `users` 2. Adicionar endpoint POST /users → verify: `curl -X POST /users -d '{...}'` retorna 201 3. Adicionar validação de email → verify: teste `invalid-email → 400` passa 4. Adicionar testes de integração → verify: `npm test` 0 failing Reporte status após cada passo antes de seguir.
✓

Fail-fast

Se o passo 1 falha, para. Não esconde no passo 2. Erro cedo é barato; erro tarde é caro.

✓

Granularidade

Passos de ~30-60 min cada. Maiores que isso ficam difíceis de verificar.

✓

Reporte

Cada passo termina com "passo X concluído, verify: [resultado]". Status visível.

6

🐛 Bug fix = reproduzir + passar

A receita universal para corrigir bugs com LLM: primeiro um teste que reproduz, depois implementação que passa. Garante que o bug não volta.

1

Reproduzir isoladamente

"Escreva um teste mínimo que dispara o bug. Rode. Confirme que falha exatamente como o bug descrito."

2

Diagnosticar

"Por que esse teste falha? Mostre a causa raiz, não o sintoma."

3

Corrigir

"Implemente a correção. Roda o teste. Confirma que passa. Roda os outros. Confirma que nenhum quebrou."

4

Commit do teste

"O teste fica no repo. Daqui pra frente, se alguém reintroduzir o bug, CI pega na hora."

🎯 Por que isso é poderoso

  • • Prova de que foi corrigido: teste passa.
  • • Prevenção de regressão: CI roda sempre.
  • • Documentação viva: próximo dev vê o teste e entende o caso.
  • • Loop fechado para o LLM: critério binário, sem ambiguidade.

💡 Prompt-padrão para bug fix

"Bug: [descrição] Faça nessa ordem: 1. Teste que reproduz o bug (deve falhar) 2. Diagnóstico curto da causa raiz 3. Correção mínima 4. Confirma que o teste passa + suíte inteira Não me peça pra confirmar nos passos intermediários. Só reporte ao fim."

📝Resumo do Módulo

✓
Declarativo > imperativo — critério de parada é mais poderoso que comando.
✓
Testes-primeiro — spec executável, loop fechado pro LLM.
✓
Loop autônomo — com critério bom, LLM itera sozinho até bater meta.
✓
Critérios SMART — específico, mensurável, binário. Não "funciona", mas "X retorna Y".
✓
Planos com checkpoints — cada passo verifica antes de seguir.
✓
Bug fix universal — reproduz, diagnostica, corrige, mantém o teste.

🎓 Você concluiu a trilha!

Agora aplique no seu projeto: copie o CLAUDE.md do repo, adapte ao seu contexto e veja os diffs ficarem cirúrgicos.

← Módulo Anterior Voltar para Trilha