Plan mode morreu? O que muda no seu fluxo com agentes

Você aperta Shift+Tab, o agente entra em plan mode, cospe um plano de 14 passos, você lê tudo, aprova, e no passo 3 ele já descobre que o arquivo que ia editar nem existe mais. Essa cena é o ponto de partida de um texto que circulou bastante nas últimas semanas: Plan mode is dead, de Ayman Nadeem. O título é provocação, mas a pergunta é séria: o plan mode ainda vale o tempo que você gasta nele?

Eu uso agentes de código todo dia, em projetos React, React Native e backend com Bun. Então vou dar minha leitura, com o que funciona e o que não funciona no meu fluxo.

O que é plan mode, e por que ele surgiu

Plan mode é o modo em que o agente lê o código, pensa e propõe um plano, mas não altera nenhum arquivo. Claude Code, Cursor e companhia têm alguma versão disso. Você revisa, ajusta e só depois libera a execução.

Ele nasceu de um problema real. Em 2024 e começo de 2025, os modelos saíam editando dez arquivos com base numa suposição errada. Você só percebia o estrago no git diff. O plan mode era um freio: "antes de mexer, me conta o que vai fazer".

Fazia todo sentido quando:

• o modelo errava a arquitetura com frequência;
• desfazer mudança era chato e manual;
• cada execução era lenta e cara.

Esses três pontos mudaram bastante.

Por que dizem que o plan mode morreu

A tese, resumida na minha leitura: o plano escrito antes do código envelhece rápido demais. O agente planeja com base no que acha que vai encontrar. Quando começa a executar, encontra outra coisa. O plano vira um documento desatualizado que você aprovou com cuidado e que ninguém segue.

E os modelos atuais planejam enquanto executam. Eles leem um arquivo, rodam um teste, ajustam a rota. O ciclo "pensar, agir, observar" ficou curto o suficiente para que separar "pensar" em uma fase própria pareça burocracia.

Somando isso a checkpoints, rewind e Git barato, errar ficou barato também. Se o agente foi para o lado errado, você volta em dois segundos.

Plano bom é o que sobrevive ao primeiro contato com o código. A maioria não sobrevive.

Um exemplo meu, de semana passada. Pedi para um agente migrar um endpoint de Express para Hono num serviço em Bun. Em plan mode, ele propôs criar um adaptador de middleware, reescrever a validação e ajustar os testes. Aprovei. Na execução, descobriu que a validação já usava Zod e que o Hono tinha o validador pronto. Metade do plano virou lixo. Eu teria economizado uns 4 minutos de leitura só deixando ele começar.

Onde o plan mode ainda salva você

Aqui eu discordo do enterro. O plan mode perdeu valor como ritual padrão. Não perdeu valor como ferramenta.

Tem três situações em que eu continuo usando:

1. Mudança que mexe em dado. Migration de PostgreSQL, script que atualiza registro em produção, qualquer coisa sem rewind de verdade. O checkpoint do agente desfaz o arquivo. Não desfaz o UPDATE que já rodou no banco.

-- isso aqui não tem Ctrl+Z
ALTER TABLE orders DROP COLUMN legacy_status;

Antes de qualquer coisa assim, quero ver o plano. E quero ver de novo depois.

2. Quando eu não sei o que quero. Às vezes o plano não é para o agente, é para mim. Pedir um plano é um jeito rápido de ver as opções de arquitetura sem escrever código nenhum. Funciona como um rascunho de RFC.

3. Codebase que o agente não conhece e que é grande. Num monorepo com vários apps e libs compartilhadas, um plano curto evita que ele mude uma lib usada por cinco projetos achando que só um consome.

Fora disso, concordo: plan mode virou hábito, e hábito sem motivo é custo.

O que muda no fluxo de trabalho na prática

Se você vai abandonar o plan mode como padrão, precisa colocar alguma coisa no lugar. Sem isso, é só deixar o agente solto. O que tem funcionado para mim:

Tarefas menores. Em vez de "refatora o módulo de pagamentos", peço "extrai o cálculo de frete para uma função pura com teste". Tarefa pequena não precisa de plano. O diff já é o plano.

Teste como contrato. Escrevo ou peço o teste antes. O teste diz o que precisa ser verdade no final. O agente pode ir pelo caminho que quiser, desde que o teste passe.

import { expect, test } from 'bun:test'
import { calcShipping } from './shipping'

test('frete grátis acima de 200', () => {
  expect(calcShipping({ subtotal: 250, uf: 'SP' })).toBe(0)
})

Isso aqui comunica intenção melhor que qualquer plano em prosa de 14 passos.

Commits pequenos e frequentes. Cada passo que funciona vira commit. Se o agente se perde, git reset e pronto. O histórico vira o plano, só que escrito depois, quando já é verdade.

Regras no arquivo de instruções do projeto. O que eu revisava no plano (não mexer em tal pasta, usar tal padrão de componente, nunca rodar migration sozinho) agora fica no CLAUDE.md ou equivalente. Escrevo uma vez e vale para toda tarefa.

Repara que nada disso é novo. É boa prática de engenharia que já existia antes da IA. O agente só deixou mais caro ignorar.

Planejar ou não: um critério simples

Se você quer uma regra de bolso, uso esta pergunta: quanto custa desfazer?

• Desfazer custa um git checkout: deixa o agente executar direto.
• Desfazer custa mexer em banco, infra, contrato de API pública ou dinheiro de alguém: plan mode, e lê o plano com atenção.
• Você nem sabe ainda o que quer: plan mode como brainstorm, sem compromisso de seguir.

Na prática, uns 80% das minhas tarefas caem no primeiro caso. Ou seja, eu passava a maior parte do tempo revisando planos para mudanças que custavam zero para reverter. Olhando agora, foi muito tempo jogado fora.

Os riscos de matar o plan mode cedo demais

Vale a objeção honesta. Pular o plano tem dois riscos reais.

O primeiro é revisão preguiçosa. Se você não leu o plano, vai ter que ler o diff. E diff grande gerado por agente é cansativo de revisar. A tentação de dar merge sem olhar direito é enorme. Tarefa pequena resolve isso em boa parte, mas exige disciplina.

O segundo é o custo. Agente que executa, erra e refaz gasta token. Em plano pago por uso, três tentativas erradas podem custar mais que um plano bem feito. Não é um argumento decisivo, mas entra na conta se você paga a fatura.

E tem um terceiro, mais sutil: o plan mode também era um momento para você pensar. Sem ele, fica fácil terceirizar o raciocínio inteiro. Já vi gente (eu incluso, admito) aceitar uma solução só porque o teste passou, sem entender por que funcionou. Aí o 3h da manhã cobra.

Minha opinião

Plan mode não morreu. O que morreu foi o plan mode como passo obrigatório antes de qualquer tarefa. Ele vira uma ferramenta de exceção: para quando errar custa caro, ou quando você ainda está decidindo o que fazer.

Para todo o resto, o melhor plano é tarefa pequena, teste antes e commit frequente. Parece menos sofisticado. Na prática, funciona melhor, porque o plano passa a ser algo que você verifica rodando, e não uma promessa que você leu e aprovou.

Se quiser ver como esse fluxo aparece em projeto de verdade, dá uma olhada nos projetos que tenho tocado.

Revisei planos de 14 passos por meses. 80% deles eram para mudanças que um git checkout desfazia.

O plan mode não morreu, mas deixou de ser passo obrigatório. O plano escrito antes do código envelhece no primeiro arquivo que o agente abre.

Hoje a pergunta que eu faço é uma só: quanto custa desfazer?

Se é migration, banco ou dinheiro de alguém, quero ver o plano. E leio duas vezes.

Para o resto, uso tarefa pequena, teste antes e commit frequente. O teste comunica a intenção melhor que qualquer plano em prosa.

Escrevi no blog como esse fluxo funciona no meu dia a dia. Você ainda aprova plano antes de tudo?

#ClaudeCode #AgentesDeIA #EngenhariaDeSoftware #DevProdutivo #Bun