Plan mode morreu? O que muda no fluxo com agentes de IA

Você ativa o plan mode, o agente lê 40 arquivos e devolve um plano de duas telas. Você aprova sem ler direito. Ele executa e faz algo um pouco diferente do que estava escrito. Se essa cena é familiar, o texto Plan mode is dead, de Ayman Nadeem, vai fazer sentido para você. A provocação é simples: o plan mode, aquele modo em que o agente só planeja e não mexe em nada, pode ter virado mais ritual do que ferramenta.

Eu concordo com boa parte. Discordo do atestado de óbito. Vou explicar por quê.

O que é plan mode e por que ele existia

Quase toda ferramenta de código com IA tem alguma versão disso. No Claude Code, no Cursor, no Copilot, no Codex. O agente fica em modo somente leitura: ele explora o repositório, faz perguntas e propõe um passo a passo. Só depois que você aprova ele começa a editar arquivos.

A lógica era boa. Os primeiros agentes eram caros, lentos e meio destrambelhados. Uma execução errada podia custar 10 minutos e um monte de tokens, e ainda deixava o repositório num estado que você tinha que desfazer na mão. Planejar antes era um cinto de segurança. Mais barato errar no texto do que errar no código.

O problema é que essa conta mudou.

Por que dizem que o plan mode morreu

Resumindo a tese do meu jeito: hoje executar ficou mais barato do que planejar. E quando executar é barato, o plano escrito perde valor.

Pensa no que mudou em pouco tempo:

• Os modelos ficaram bem mais rápidos e mais certeiros em tarefas de escopo médio.
• As ferramentas ganharam checkpoint e rewind. Deu errado, você volta.
• Git worktree virou padrão para rodar agente isolado sem sujar sua branch.
• Sandbox na nuvem deixou de ser luxo.

Com isso, o fluxo "planeja, aprova, executa" começa a parecer burocracia. Um plano em markdown é uma promessa. O agente diz "vou alterar o useAuth, criar um middleware e ajustar três testes". Você lê, acha razoável, aprova. Mas você não tem como saber se o plano está certo até ver o código rodando. O plano não compila.

Um plano é uma hipótese. Um diff é um experimento.

E tem um efeito colateral que pouca gente admite: plano longo gera aprovação preguiçosa. Ninguém lê com atenção o quinto bullet de um plano de 30 linhas. Você aprova por cansaço. Na prática o plan mode virou um botão de "ok, pode ir" com etapas a mais.

O que muda no fluxo de trabalho na prática

Se você tirar o plan mode do centro, o que entra no lugar? No meu dia a dia, três coisas: isolamento, critério de aceite e descarte sem dó.

Primeiro, isolamento. Em vez de pedir um plano, eu dou o objetivo e deixo o agente rodar num lugar onde errar não custa nada.

git worktree add ../app-tentativa-1 -b agent/refresh-token
cd ../app-tentativa-1
# roda o agente aqui, com liberdade para editar

Se ficar ruim, apago a pasta e pronto. Se ficar bom, abro PR. Duas tentativas em paralelo custam menos que meia hora discutindo um plano.

Segundo, critério de aceite. O plano que realmente importa é o que diz quando a tarefa está pronta. E isso cabe num teste. Antes de pedir a feature, eu escrevo (ou peço para escrever) o contrato:

import { test, expect } from 'bun:test'
import { refreshSession } from './session'

test('renova o token quando faltam menos de 5 minutos', async () => {
  const session = { expiresAt: Date.now() + 4 * 60_000, refreshToken: 'abc' }
  const next = await refreshSession(session)
  expect(next.expiresAt).toBeGreaterThan(session.expiresAt)
})

test('não renova token ainda válido', async () => {
  const session = { expiresAt: Date.now() + 30 * 60_000, refreshToken: 'abc' }
  const next = await refreshSession(session)
  expect(next).toBe(session)
})

Esse teste é um plano melhor do que qualquer lista em markdown. Ele é verificável. O agente pode iterar até passar, e eu não preciso confiar na palavra dele.

Terceiro, descarte sem dó. Esse é o mais difícil para quem vem do fluxo antigo. Quando o agente erra feio, a vontade é corrigir na conversa: "não, volta, faz assim". Muitas vezes é mais rápido jogar fora e recomeçar com um prompt melhor. O contexto contaminado de uma tentativa ruim atrapalha a próxima.

Juntando tudo, o fluxo fica mais ou menos assim:

1. Escreva o objetivo em duas ou três frases.
2. Defina o critério de aceite, de preferência em teste.
3. Rode o agente isolado, em worktree ou sandbox.
4. Revise o diff, não o plano.
5. Se não prestou, descarte e ajuste o prompt.

Repara que a revisão humana não sumiu. Ela só mudou de lugar. Você deixa de revisar intenção e passa a revisar resultado.

Onde o plan mode ainda salva você

Aqui eu discordo do título. Tem situação em que planejar antes continua sendo a escolha certa, e ignorar isso é pedir para ter dor de cabeça.

Operação irreversível. Migração de banco é o exemplo clássico. Se o agente vai mexer em schema de PostgreSQL com dados de produção, eu quero ver o plano antes. Um DROP COLUMN não tem Ctrl+Z. Worktree não protege seu banco.

-- isso aqui eu quero ler antes, não depois
ALTER TABLE orders DROP COLUMN legacy_status;

Codebase que você não conhece. Quando entro num projeto novo, o plan mode funciona mais como ferramenta de leitura do que de planejamento. Pedir para o agente explorar e explicar como o fluxo de autenticação funciona, sem tocar em nada, é ótimo para entender o terreno.

Mudança que atravessa muita coisa. Trocar o gerenciador de estado de um app React Native inteiro, migrar de Express para Hono, renomear um conceito central do domínio. Aqui o plano serve para alinhar com o time, não com o agente. É um documento de decisão.

Custo alto por execução. Se cada rodada do agente leva 20 minutos porque tem build nativo ou suíte de testes pesada, errar fica caro de novo. A conta do começo do texto volta a valer.

Então, para mim, o plan mode não morreu. Ele foi rebaixado. Deixou de ser o padrão para toda tarefa e virou ferramenta para casos específicos. Igual ao debugger: você não abre ele para todo bug, mas quando precisa, precisa mesmo.

Vale a pena mudar seu jeito de usar agentes?

Vale testar por uma semana. Experimento simples: pegue as tarefas pequenas e médias (bug, endpoint novo, componente, refatoração local) e pule o plan mode. Vá direto para execução isolada com critério de aceite claro. Anote quanto tempo cada uma levou e quantas vezes você teve que descartar.

Minha aposta é que você vai perceber duas coisas. A primeira: muitas das suas aprovações de plano eram automáticas. A segunda: o tempo que você gastava lendo plano rende mais lendo diff.

E se o agente fizer besteira? Ótimo, foi numa pasta descartável. Melhor do que ele fazer besteira depois de você ter aprovado um plano bonito. Pelo menos agora a culpa não é sua por ter dado ok.

Minha opinião

O ponto mais forte do texto não é sobre um modo específico de uma ferramenta. É sobre onde está o controle. Por muito tempo a gente achou que controlar o agente era controlar o que ele pretende fazer. Na prática, controle de verdade é ter testes que dizem se ficou certo e um ambiente onde errar é barato.

Se o seu projeto não tem isso, nenhum plan mode vai te salvar. Se tem, você quase não precisa dele.

É assim que tenho trabalhado nos meus projetos ultimamente, e dá para ver um pouco desse resultado nos projetos que publiquei por aqui.

Você aprova planos de 30 linhas sem ler o quinto bullet? Eu também aprovava.

Li o "Plan mode is dead", de Ayman Nadeem, e concordo com boa parte. Executar ficou mais barato que planejar.

Um plano é uma hipótese. Um diff é um experimento. Hoje eu rodo o agente numa worktree isolada, defino o critério de aceite em teste e reviso o resultado, não a intenção.

Mas não assino o atestado de óbito. Migração de banco, codebase desconhecida e mudança que atravessa o time inteiro ainda pedem plano antes. Um DROP COLUMN não tem Ctrl+Z.

O plan mode não morreu, foi rebaixado. Controle de verdade é ter testes que dizem se ficou certo e um ambiente onde errar sai barato.

Escrevi como isso mudou meu fluxo no blog. Como você tem usado o plan mode no dia a dia?

#IA #AgentesDeIA #DesenvolvimentoDeSoftware #ClaudeCode #Produtividade