Planejamento é engenharia: a meta-skill de planos pra agentes de IA

Tem uma frase que o IndyDevDan repete até você cansar no vídeo dele: “grande planejamento é grande engenharia”. Eu assisti os 62 minutos inteiros dele reconstruindo do zero a meta-skill de planejamento — a Plan F3, “Plans for Fable 5 / Fable thoughts” — e saí com uma certeza desconfortável: a maioria de nós terceirizou a parte mais importante do trabalho pro agente. Você joga um /plan no Claude Code e reza. Ele defende o oposto, e eu concordo: o futuro é construído por quem planeja, não por quem faz vibe coding.

As duas restrições da engenharia agêntica: planejar e revisar

O argumento central é simples e cruel. Toda engenharia com agentes vive sob duas restrições: planejamento e revisão. Quanto mais investimento você coloca na frente, no plano, menos revisão você paga atrás. E o ponto que mais me pegou: conforme os modelos ficam melhores, isso fica mais verdadeiro, não menos. O plano detalhado vira o contexto mais valioso que seus agentes vão ler e escrever.

Esse raciocínio é a continuação direta do que ele já tinha falado sobre loop engineering e níveis de abstração. A diferença entre um engenheiro bom e um mediano não é a velocidade de digitação — é o quanto ele investe antes de a primeira linha sair. Largar o planejamento na mão do modelo “sem estrutura” obriga o agente a adivinhar o que você quer. E adivinhação não escala.

Property-based engineering: ele escreve à mão antes de chamar o agente

A parte que vai chocar muita gente: ele começa digitando. Abre um arquivo raw.md e escreve em texto puro o que quer fazer, por que, e quais são as prioridades — sem agente nenhum no loop ainda. Ele chama isso de property-based engineering: antes de pedir qualquer coisa pro modelo, ele lista as propriedades (as seções) que o sistema precisa ter. Só depois que a visão e a fundação estão de pé é que o agente entra pra acelerar.

Na minha visão esse é o detalhe mais subversivo do vídeo. Enquanto metade da indústria dispara 500 agentes em paralelo, ele defende sentar, pensar e escrever com a própria mão. O agente não some — ele entra depois, quando já existe uma fundação pra ele seguir. “Grande engenharia é pensar. O que você quer ver? Por quê? O que você está disposto a abrir mão pra entregar?”

Meta-skill e o trifecta: você, seu time e os agentes

Plan F3 não é um prompt comum — é uma meta-skill: uma skill que cria outras skills e documentos. O coração dela é o plan template, o formato que o agente preenche e replica centenas de vezes pra entregar resultados consistentes. Isso é o que ele chama de templar a sua engenharia: você ensina o agente a engenheirar do jeito que você engenheira. É o seu conhecimento de domínio codificado — e é isso que te tira da distribuição normal de resultados.

E pra quem esse plano é escrito? Pro trifecta: você, o seu time de engenharia e os agentes de IA. O erro comum é otimizar pra um só — só pro agente, ou só pra você. O plano bom serve aos três ao mesmo tempo. É por isso que várias decisões do formato (HTML, imagens, metadados legíveis) existem: elas não são só pro modelo, são pra um humano abrir e entender em dez segundos.

Plan F3: as propriedades de um plano feito pra modelos Mythos

Aqui está o miolo — e onde eu fui anotando ponto por ponto. As propriedades que ele cravou no novo plano:

(1) HTML first em vez de markdown — mais tokens “valiosos” pro agente e leitura mais rica pro trifecta. (2) Imagens embutidas, geradas pelo GPT-image-2, uma por fase, porque “uma imagem vale mil palavras” e os specs estão virando multimodais. (3) Checklist embutido por tarefa e por fase. (4) Quebra de trabalho por fase e por tarefa, cada fase autocontida e validável. (5) Metadados de cabeçalho atualizáveis: data de criação, lista de modificações, commits, nome do agente, session ID, e referências para frente e para trás — tudo em listas append-only.

(6) Seção de perguntas e respostas togglável (a variável “questionable”): por padrão ele empurra pra ZTE, zero touch engineering, mas deixa um botão pra entrar no loop quando o trabalho exigir. (7) Seções de validação e teste que impedem a conclusão até tudo passar — o clássico closed-loop. (8) Separação de arquivos novos vs. existentes. (9) Estilos de HTML e imagem sincronizados, mais purpose, problem, solution no topo e uma seção de notes onde o agente “corre livre”. A crítica óbvia — “você não está limitando o modelo?” — ele responde: 9 em 10 vezes, cravar o formato e abrir uma seção livre entrega mais valor do que soltar o agente no vazio.

Workflows: o plano vira um artefato vivo do código

O salto conceitual maior, pra mim, é tratar o plano como um artefato vivo que persiste por todo o ciclo de vida do código — não um documento que você joga fora depois. Pra isso ele empacota tudo numa skill única e autossuficiente, sem dependências cruzadas, com um diretório de workflows e uma tabela dizendo quando chamar cada um. São cinco: criar plano, atualizar plano, atualizar referências, build (o agente que executa o plano) e geração de imagens. É a mesma ideia de workflows dinâmicos com subagentes, mas concentrada num pacote só.

O workflow de build tem quatro estados de tarefa: vazio (idle), work in progress, X para concluído e F para falha — com uma regra de loop fechada: o plano não está completo até toda caixa estar marcada e todo comando passar. Se uma tarefa for genuinamente impossível, marca F e segue. Cada agente roda com contexto fresco, na tática de um agente, um prompt, um propósito.

O trade-off trifecta: gastar tokens pra vencer

Toda decisão aqui passa por um trade-off que ele martela: performance > velocidade ≥ custo. Esse plano troca velocidade e custo (tokens) por performance máxima de propósito. HTML gasta mais tokens? Gasta. Gerar uma imagem por fase custa? Custa. Mas é um custo decidido na frente, com prioridade clara: ele quer o melhor plano possível, não o mais barato. Ele cita inclusive um material da Anthropic sobre como dar tokens “valiosos” (HTML estruturado) dá uma vantagem marginal ao agente na hora de produzir o resultado certo.

No vídeo ele roda tudo no Opus 4.8 em high effort — que segundo ele entrega 80-90% do que um modelo Mythos classe Fable 5 faria — e mira o restante na próxima geração. A demo: pediu pra reimplementar a comunicação agente-a-agente dele usando o protocolo Iron no lugar de HTTP cru. O agente pesquisou ~6 minutos, gerou o plano HTML completo, disparou 8 imagens em paralelo (sem ele nem ter pedido paralelismo) e abriu no Chrome — com hero image, metadados rastreáveis, problema, solução, imagem por fase, prompts closed-loop e até uma matriz de paridade. É a prova viva de que o tempo gasto na meta-skill se paga.

Por que isso importa pra você, dev

Tirando o hype dos “modelos Mythos”, ficam três lições que valem pra qualquer stack hoje: (1) o seu prompt de planejamento é uma das ferramentas mais importantes que você tem — quanto mais você vai reusar uma skill, mais tempo merece investir nela. (2) Templar a sua engenharia é o que diferencia: resultado genérico vem de prompt genérico; o seu conhecimento de domínio, codificado no formato, te tira da média. (3) Não terceirize o seu pensamento. A atrofia de skill é real e natural — toda tecnologia dá e tira — mas pensar, planejar e decidir o que você quer ver continua sendo o trabalho. Vale revisitar também o harness como camada entre modelos e agentes pra ver onde esse plano se encaixa.

Conclusão

Eu entrei nesse vídeo esperando mais um “hack de produtividade com IA” e saí com a coisa oposta: um lembrete de que engenharia ainda é sentar, pensar e escrever com clareza antes de soltar os agentes. Planejamento bom não é burocracia — é a alavanca que fica mais forte a cada modelo novo. Se você só leva uma frase daqui, leve essa: grande planejamento é grande engenharia.

Vale assistir na íntegra — são 62 minutos densos de engenharia agêntica hands-on. O vídeo completo do IndyDevDan está disponível em Plan F3 — reconstruindo a meta-skill de planejamento (YouTube).