Módulo 1.4 — De Pair Programmer a Engineering Manager

🤝 O contrato antigo (4.6)

No 4.6, você era pair programmer. Falava "olha isso", ele respondia, você dizia "agora faz aquilo", e assim ia. Turnos curtos, conversa iterativa, guia linha a linha funcionava.

🚨 Sintomas do contrato antigo

✗Seu fluxo típico tem 6–10 turnos por tarefa simples
✗Você manda arquivos "conforme Claude pede"
✗Intenção só aparece no turno 3 ou 4

📋 O contrato novo (4.7)

Agora você é engineering manager. Escreve um bom ticket (briefing completo) e deixa o engenheiro sênior entregar. A autonomia é real — o 4.7 foi treinado para isso.

🎯 A fala oficial

"Trate o Claude mais como um engenheiro capaz para quem você está delegando do que como um pair programmer que você guia linha por linha."

— Best Practices Opus 4.7, Anthropic, abril/2026

🔁 Drip-feed vs. briefing

✗ Drip-feed (4.6 mode)

T1: olha esse código
T2: pode refatorar?
T3: ah, tem que manter compat
T4: e escreve testes
T5: o arquivo é x.ts

✓ Briefing (4.7 mode)

Refatore api/orders.ts para extrair
cálculo de frete em lib/shipping.ts.
Restrições: manter calculateOrderTotal,
não quebrar tests/orders.test.ts.
Critério: todos testes passam +
3 testes novos para o módulo.

❌ Top 6 hábitos que penalizam

1."Olha isso" sem intent
2."Double-check before returning"
3."CRITICAL: You MUST use..."
4."After every N tool calls, summarize"
5."Be conservative / don't nitpick" (review)
6.budget_tokens no código

✅ Top 6 hábitos que compensam

1.ICCA completo no turno 1 (Trilha 2)
2.Effort calibrado por tarefa
3.Frases-gatilho de thinking quando precisa
4.Rewind + handoff em vez de "não, tenta X"
5.Subagente explícito para fan-out
6.Safety prompt para ações irreversíveis

🎭 Exercício: reescreva seu último prompt

Abra seu histórico e pegue o último prompt real que enviou ao Claude. Diagnostique: era drip-feed ou briefing?

1. Copie o prompt original
2. Liste o que estava faltando (intent? restrição? critério? arquivo?)
3. Reescreva completo em 1 turno
4. Execute ambos e compare tokens e turnos

💡 Quando voltar a ser pair

A regra não é absoluta. Existem casos legítimos para voltar ao modo iterativo:

•
Exploração aberta — você não sabe o que quer ainda
•
Aprendizado de domínio novo — o Claude como professor
•
Decisão de arquitetura ainda em aberto — debate vale a pena

📋 Resumo

✓

Mudança de contrato — pair programmer → engineering manager

✓

Drip-feed morreu — briefing único é o caminho

✓

6 hábitos ruins + 6 hábitos bons — mapeados e acionáveis

Próximo Módulo:

1.5 — Primeiro Contato Prático

← Módulo Anterior Próximo Módulo →