LLM Wiki — Synaptic Lattice

plan-first-com-agentes-de-ia

Properties1
tagsvibe-coding, orchestration, founder, pm

Leitura de 4 min

Plan-First com Agentes de IA

Definition

Plan-first é a prática de exigir que o agente de IA leia a issue, explore o código e proponha um plano — quais arquivos vai tocar, qual abordagem, quais riscos — antes de escrever qualquer código, e só avançar para a execução depois de aprovação humana explícita. O argumento central da fonte é econômico: corrigir um plano custa minutos; corrigir código já implementado na direção errada custa muito mais. Plan-first não é tratado como opcional para tarefas não-triviais — só bugs simples (trocar uma URL, ajustar uma cor) podem pular direto para a execução.

Key Points

  • A primeira mensagem do agente define o tom da sessão. Recuperar de uma sessão que começou codando na direção errada custa mais do que ter planejado primeiro.
  • Dois modos, não quatro ou mais: Planner (lê, pensa, propõe) e Executor (implementa, testa, entrega). A fonte cita um estudo de Stanford segundo o qual múltiplos agentes colaborando entre si perdem performance — mais agentes não é mais produtividade, é mais complexidade (afirmação de estudo citada sem link, confidence: medium).
  • Use os modos nativos do harness (Codex, Claude Code, OpenCode já têm modo leitura/planejamento e modo execução) em vez de inventar personas especializadas (“agente de frontend”, “agente de backend”) no AGENTS.md — a complexidade de configuração raramente compensa.
  • Prompt padrão para tarefa ambígua: “Não implemente ainda. Primeiro, proponha um plano mínimo. Liste os riscos. Diga quais arquivos vai tocar. Depois aguarde minha aprovação.”
  • Pesquisar antes de codar quando há dependência externa. O corte de conhecimento do modelo significa que ele pode implementar contra uma API de lib que já mudou. Instrução recomendada: pesquisar issues/documentação recente de qualquer lib externa antes de gerar código contra ela.
  • Divisão de responsabilidade: o founder/PM define o problema e o appetite (tempo); o agente/dev decide a implementação. Invadir a decisão de implementação (“usa React Query pra isso”) tira do executor a responsabilidade pela solução, mas mantém nele a responsabilidade pelo resultado — combinação ruim segundo a fonte.
  • Cadeia formal intent → spec → plan (Anthropic, 2026-09): o playbook AI-native SDLC publicado pela equipe do Claude Code institucionaliza o plan-first como cadeia de três artefatos — intent.md (o porquê, capturado por entrevista), spec.md (o quê técnico) e plan.md (tarefas ordenadas com prova de conclusão) — com o intent podendo viver em tickets (Jira/Linear) em vez de arquivo no repo. Detalhes em ai-native-sdlc (Related Concepts).

Implications

Plan-first funciona como um checkpoint de baixo custo entre a especificação (ver especificacao-de-issues-para-agentes) e a execução (ver ciclo-issue-branch-pr-merge) — é o ponto em que erros de interpretação da issue são pegos antes de virarem código. A qualidade do plano que o agente propõe depende diretamente da qualidade das instruções persistentes descritas em agents-md-como-instrucao-operacional e da issue em si: um plano só é tão bom quanto o contrato que o originou.

Open Questions

  • A fonte não detalha como o “estudo de Stanford” sobre múltiplos agentes foi conduzido nem link para verificação — vale tratar como heurística de senso comum (menos agentes = menos coordenação) até achar a fonte primária.
  • Não fica claro qual o critério exato de “tarefa não-trivial” além dos exemplos dados (bug simples vs. lógica/fluxo/múltiplos arquivos) — zona cinzenta não coberta.

Sources

Visão de gráfico

Backlinks