🏛️ Arquiteto: GPT-5.5 e o pensamento estruturado
GPT-5.5 e excelente em decompor problemas grandes em tarefas concretas, definir contratos de API antes do codigo, e identificar riscos que a maioria so percebe na execucao. Pular o arquiteto faz o executor reescrever 3x — sai mais caro do que ter pago um plano bem feito.
🎯 O que pedir ao arquiteto
- •Lista de arquivos a criar/modificar
- •Schemas e contratos (SQL, API, types)
- •Ordem de implementacao com dependencias
- •Riscos tecnicos e edge cases
- •Criterios de aceitacao (como saber que terminou)
🎨 Designer: Opus 4.7 e a sensibilidade
Opus tem nuance — escolhe palavras melhor, percebe quando uma interface esta confusa, sugere copy que converte. Em produto, 1% de melhoria de UX vale mais que 50% de melhoria de codigo. Opus paga o premium em decisoes de produto.
✨ Onde Opus brilha
- •Copy de landing: headline, subheadline, CTA
- •Microcopy: mensagens de erro, validacao, vazio
- •Hierarquia visual: o que destacar, o que esconder
- •Tom: ajustar entre formal/casual/confiante
- •Decisao entre 2 caminhos: quando intuicao importa mais que logica
⚡ Executor: DeepSeek V4 e a velocidade barata
Quando tem plano e contrato claros, DeepSeek implementa em segundos com qualidade equivalente a um dev pleno em 80% das tarefas. O segredo: plano antes do codigo e prompt fechado.
🚀 O sweet spot do executor
- •Implementar plano detalhado (sem questionar)
- •Gerar 12 componentes parecidos a partir de 1 template
- •Escrever testes a partir de specs
- •Refatorar mecanico (renomear, extrair funcao, mover arquivo)
- •Gerar docstrings e READMEs a partir do codigo
⚠️ Onde DeepSeek tropeca
Problemas com mais de 5 passos de raciocinio encadeado, onde uma decisao depende do entendimento da anterior. Ex: refatoracao envolvendo varios modulos com regras de negocio implicitas. Nesses casos: suba para GPT-5.5.
🔍 Revisor: GPT-5.5 ou Opus para auditar
Depois que DeepSeek codifica, um modelo caro le o diff e procura: bugs sutis, problemas de seguranca, divergencia do plano. A revisao evita 90% dos bugs que escapariam para producao — e o custo e baixo (le, nao gera muito).
📋 Checklist do revisor
- Codigo faz exatamente o que o plano pediu?
- Trata os edge cases mencionados no plano?
- Tem bugs evidentes (off-by-one, null, race)?
- Riscos de seguranca (XSS, SQL injection, auth)?
- Performance: queries N+1, loops ineficientes?
- Naming consistente com o resto do projeto?
- Tem testes? Cobrem o caminho infeliz?
- Documentacao minima (comentarios em logica nao-obvia)?
🤝 Por que 3 papeis (e nao 2 ou 5)
Com 2 papeis voce perde planejamento ou polimento. Com 5 papeis a coordenacao consome mais que economiza. 3 e o sweet spot empirico — cobre a maioria dos casos sem virar burocracia.
2 papeis
Sem arquiteto: codigo bom mas com escopo errado. Sem designer: produto sem polimento. Sem revisor: bugs em producao.
3 papeis ✓
Cobre planejamento, execucao, polimento e revisao com handoff simples. Escala de pequeno ate medio.
5+ papeis
Custo de coordenacao supera economia. Modelos esperando uns aos outros. Burocracia mata velocidade.
📋 Checklist: identificar qual papel a tarefa pede
5 perguntas que decidem em 10 segundos. Reduz a fadiga de decisao — voce nao para mais para pensar "qual modelo uso?".
🎯 As 5 perguntas
Sim → arquiteto (GPT-5.5)
Sim → designer (Opus)
Sim → executor (DeepSeek)
Sim → designer (Opus)
Sim → revisor (GPT-5.5)
📌 Resumo do Modulo
Proximo Modulo:
1.3 — ⚖️ A regra dos 70/20/10