Vibe coding no modo de planejamento para economizar contexto do agente

A regra que Moretté segue antes de deixar o agente encostar no código é mudar para o modo de planejamento. Enquanto o agente só desenha o que vai ser feito e em que ordem, ele observa que o consumo cai bastante. Quando o plano volta pronto e ele aprova, o consumo sobe de novo.

Isso saiu na live "Just Coding, No Stress", num trecho em que ele estava com várias sessões abertas e falava sobre o limite de cada uma. O pedaço mais útil da explicação é justamente o que ele corrige no meio dela.

A frase em que ele corta o próprio exagero

"o certo é você, tipo assim, você quer planejar o que você vai fazer, a ordem de que você vai fazer, muda pro modo de planejamento. Ele não fica consumindo, entendeu? Muito, consum bem menos. Ele fica mais inteligente, não mais inteligente, mas ele fica melhor."

O miolo está em "não mais inteligente". Ele solta "mais inteligente", escuta o que acabou de dizer e volta atrás no mesmo fôlego para trocar por "melhor". A distância entre as duas palavras é a distância entre vender uma ferramenta e descrever uma. No modo de planejamento o agente não passa a ser capaz de mais coisa; ele trabalha em condição melhor, com uma tarefa menor e mais fechada na frente, e quem fala isso de improviso ao vivo acabou de se poupar de um argumento que não sustentaria. Isso aparece também em chatgpt ou claude.

Guarde também o que essa fala é: a teoria de trabalho de um builder, testada no uso dele e dita enquanto mexia em outra coisa. Ele mesmo põe a etiqueta, no fim da explicação:

"Um negócio meio doideira. Eu não sei muito bem ainda. Tô tô tô na fase de aprender, mano."

Quem levar essa regra para o próprio trabalho está levando a observação dele, com o mesmo grau de certeza que ele deu.

Por que sobrar contexto virou decisão de rotina

Antes de chegar no modo de planejamento, ele descreve o problema que o obriga a pensar nisso. A sessão tem limite. Quando bate nesse limite, ela precisa compactar: o agente guarda algumas coisas chave daquele contexto e o resto se perde. O histórico não some inteiro, ele encolhe até virar resumo, e você participa pouco da escolha do que ficou de fora. O mesmo problema apareceu em claude md.

Quem já atravessou uma compactação no meio de uma tarefa longa conhece a conta. O agente volta disposto e sem lembrar por que aquele arquivo estava daquele jeito, e você reexplica tudo. Todo token gasto cedo é um pedaço de explicação que você vai pagar de novo mais tarde. Tratar o ambiente que o agente enxerga — quais arquivos, quais ferramentas, quanto contexto — como a peça que você projeta antes da tarefa é o que anda sendo chamado de harness engineering. O mesmo problema apareceu em skill claude code.

Por isso a escolha do modo antes de começar deixa de ser detalhe de ferramenta e vira rotina de quem faz vibe coding com agente. O que já está decidido pode gastar. O que ainda está sendo decidido não precisa gastar junto. Vale ver como isso terminou em vibe coding para proteger logica sensivel no servidor.

A economia acaba no momento em que você aprova

O final da fala pesa tanto quanto o começo:

"Aí você definiu o plano, ele te mandou o plano, você aprovou, aí você deixa ele fazendo, tá ligado? Aí ele começa mais se gastar porque daí ele vai pensar, ele vai fazer os negócios"

O modo de planejamento, nessa descrição, não deixa o trabalho mais barato. Ele adia o gasto e enxuga a parte cara, porque o agente entra na execução já sabendo a ordem das coisas. A economia inteira mora no intervalo entre a sua primeira frase e o seu "pode fazer". Aprovar um plano ainda vago queima esse intervalo à toa: você pagou a conversa e vai pagar a execução vaga em seguida.

Isso muda o que você faz enquanto está no modo. O objetivo ali é sair com uma ordem de tarefas que você assinaria por escrito, e não ver o agente pensando bonito na tela. Quando esse plano vira documento e passa a ser o contrato que o agente executa, o hábito já tem nome: spec driven development. Foi o mesmo caminho de vibe coding para testar antes de lançar feature nova.

Onde a economia mora no vibe coding com agentes

Logo depois, ele fala de subir vários agentes para dividir tarefa, e derruba a intuição de que isso alivia o consumo:

"ele só divide o peso das tarefas, tá ligado? Consumir, ele vai consumir igual."

Paralelismo reparte o trabalho entre executores e o total continua o mesmo. A alavanca que sobra é o que você decide antes de mandar executar: quantas tarefas existem e com que escopo cada uma vai. O mesmo problema apareceu em vibe coding com várias sessões de IA ao mesmo tempo. Outro builder chegou perto disso por um caminho diferente, planejar antes de delegar, onde o argumento é segurar o paralelismo até o escopo fechar; aqui a preocupação é o contexto que o plano poupa antes disso acontecer.

O que fazer na próxima tarefa

Entre no modo de planejamento antes de pedir qualquer alteração e fique lá até o plano descrever a ordem das tarefas em frases que você entenderia se voltasse a elas dias depois. Só então aprove. Se na leitura do plano ainda sobrar uma pergunta sua, ela custa pouco naquele ponto e custa caro com o agente no meio da execução.

Vale assistir à live para ouvir o tom em que ele diz tudo isso, no meio de outro trabalho e sem pretensão de estar certo. Esse é o material que o vibe coding em público tem e nenhuma documentação de produto entrega: alguém testando uma regra no próprio trabalho, contando onde ela funciona e admitindo onde ela para de valer.