Lembra quando a gente pedia pro Cursor ou Claude Code “planeja primeiro, não mexe em nada”? Eu lembro. Fazia isso religiosamente. Abria o agente, digitava o prompt com aquele disclaimer sagrado: “Só planeje, não execute.” O modelo cuspia um documento de 200 linhas explicando cada passo. Eu lia metade, aprovava, e rezava pro resultado ser decente.

O plan mode nasceu de uma necessidade real: agentes de IA estavam gerando milhares de linhas de código antes que o dev entendesse o que estava sendo construído. Era como contratar um pedreiro que começa a derrubar parede antes de você terminar a frase. O plan mode era o “calma aí, me mostra a planta primeiro”.

Só que uma coisa mudou. Os modelos ficaram bons. Bons de verdade.

O plan mode era um band-aid, não uma feature

A Ayman Nadeem, engenheira que construiu a Nuanced (uma ferramenta inteira de planejamento para agentes de IA), publicou um post no blog dela que explodiu no Hacker News com mais de 500 pontos. O título? “Plan Mode Is Dead”. E olha que ela não é uma crítica qualquer: ela é alguém que investiu meses construindo exatamente a coisa que agora diz estar obsoleta.

O argumento central dela é simples: plan mode era necessário quando os modelos eram burros. Quando o GPT-3.5 ou os primeiros Claude precisavam de contexto explícito pra cada decisão, fazia sentido criar um documento detalhado antes de qualquer ação. O modelo não entendia o codebase. Não sabia navegar. Precisava de um mapa.

Em 2026, os modelos leem repositórios inteiros, entendem dependências entre arquivos, inferem padrões de arquitetura e tomam decisões razoáveis sem pedir permissão. O Claude Code, por exemplo, navega pelo seu projeto, lê os testes, entende o estilo do código e começa a trabalhar. O mapa virou inútil porque o agente agora tem GPS.

Por que devs continuam usando plan mode (mesmo sem precisar)

Se o plan mode já não funciona, por que tanta gente ainda usa? Por medo. E por hábito.

Tem dev que abre o Claude Code e o primeiro prompt é: “Analise todo o projeto e me dê um plano detalhado do que fazer.” O modelo responde com um textão de 3 mil tokens. O dev lê os primeiros parágrafos, rola até o final, digita “ok, pode fazer” e torce pro melhor.

Eu já vi isso dar errado de formas criativas. O plano dizia “vou criar um middleware de autenticação”. O dev aprovou. O agente criou o middleware, mas também refatorou o sistema de rotas inteiro porque “achou que fazia sentido”. O plano estava certo. A execução, nem tanto.

O problema fundamental é que planos de IA têm um defeito estrutural: eles parecem ótimos na leitura mas não capturam a realidade da execução. Um plano diz “vou modificar o arquivo X para adicionar a feature Y”. Parece razoável. Mas na hora de executar, o agente descobre que o arquivo X importa o módulo Z que tem um bug antigo, e aí a cascata começa.

O modelo waterfall de volta (disfarçado de IA)

A Ayman faz uma comparação que dói: o plan mode é waterfall disfarçado de processo moderno.

Pensa no fluxo: você conversa com o agente, ele gera uma especificação, você revisa, aprova, ele implementa. Isso é exatamente chat, spec, review, approve, implement. O mesmo ciclo que a indústria de software levou 20 anos pra abandonar em favor do agile.

A separação artificial entre “modo de planejar” e “modo de construir” adiciona carga cognitiva desnecessária. Você precisa decidir: estou planejando ou executando? Essa decisão interrompe o fluxo natural de trabalho.

Qualquer dev experiente sabe que as melhores decisões de arquitetura acontecem durante a implementação, não antes. Você começa a codar, percebe que a abstração está errada, ajusta, segue em frente. Planejar tudo antecipadamente funciona em pontes e cirurgias, não em software.

O que funciona de verdade: ciclos curtos

Se plan mode está morto, o que veio no lugar? Ciclos curtos de feedback. O novo padrão que está emergindo entre devs que usam agentes pesadamente é:

Entender, agir, inspecionar, ajustar, agir de novo.

Não é “planeje 100% e execute 100%”. É “faça 10%, me mostra o que fez, eu corrijo, você faz mais 10%”. Iteração rápida.

Na prática, isso se traduz em prompts menores e mais direcionados. Em vez de “planeje toda a feature de autenticação”, o prompt vira “adicione o endpoint de login com JWT no arquivo routes/auth.ts”. O escopo é pequeno. O risco é baixo. Se der errado, você perdeu 30 segundos, não 30 minutos.

O Claude Code já funciona naturalmente nesse modelo. Ele lê o arquivo, faz a mudança, roda os testes, vê que falhou, corrige, roda de novo. Tudo sem você intervir. O “plano” existe, mas é implícito. O modelo decide o que fazer a cada passo com base no feedback do passo anterior.

Os dados que ninguém quer ouvir

A Nuanced, a ferramenta que a Ayman construiu especificamente para resolver o problema de planejamento, revelou algo inconveniente durante os testes: os usuários não se importavam com os documentos de especificação.

A equipe tentou melhorar a legibilidade. Criaram uma feature chamada “Spec Tour” que guiava o dev pelo plano em etapas. Adicionaram formatação visual. Reduziram a densidade de informação. Nada funcionou. Os devs aprovavam o plano sem ler.

Isso não é preguiça. É uma reação racional. Ler 200 linhas de especificação gerada por IA é cansativo porque o texto é correto mas genérico. Não tem as nuances que um humano colocaria. Não tem as justificativas contextuais. É como ler um manual de instruções: tecnicamente preciso, praticamente inútil.

O resultado? Equipes que dependiam de plan approval como camada de segurança descobriram que planos aprovados ainda geravam código com bugs sutis, dependências alucinadas e vulnerabilidades de segurança. O plano era um teatro de segurança.

Mas e os agentes que fazem besteira?

Aqui vem o contra-argumento legítimo: se eu não planejo, como evito que o agente destrua meu código?

A resposta não é planejar mais. É conter o escopo.

Nenhuma dessas estratégias envolve pedir pro agente “planeje primeiro”. Todas envolvem conter o impacto de decisões ruins, que é exatamente o que a engenharia de software já faz há décadas.

O problema que ninguém resolveu ainda

A Ayman termina o artigo com uma pergunta que ainda não tem resposta: como o dev mantém entendimento do sistema quando centenas de agentes estão modificando coisas em paralelo?

Isso é real. Com ferramentas como o Cursor Background Agents, o Claude Code com sub-agentes e o Codex da OpenAI rodando na nuvem, é possível ter 10 agentes modificando 10 partes diferentes do codebase ao mesmo tempo. Cada um faz mudanças razoáveis isoladamente. Mas juntas, as mudanças podem conflitar, criar redundâncias ou introduzir bugs de integração.

O plan mode não resolve isso. Um plano individual por agente não garante coerência global. É como 10 pedreiros com 10 plantas diferentes reformando a mesma casa: cada um segue sua planta perfeitamente, mas a casa fica inabitável.

A solução provavelmente não é mais planejamento. É melhor tooling. Melhores diffs visuais. Melhores formas de ver “o que mudou no sistema inteiro nos últimos 5 minutos”. Dashboards de estado do codebase em tempo real. Coisas que a indústria ainda está inventando.

AGENTS.md: o sucessor silencioso do plan mode

Uma tendência que está ganhando tração é o AGENTS.md: um arquivo no repositório que define regras, restrições e padrões que qualquer agente de IA deve seguir ao trabalhar no projeto.

A Anthropic lançou suporte oficial a AGENTS.md no Claude Code em setembro de 2026, e a feature funciona em múltiplas ferramentas: Cursor, Copilot CLI, Gemini CLI. A ideia é dar contexto persistente pro agente sem precisar de um plano por tarefa.

Em vez de planejar cada operação, você define as regras do jogo uma vez:

# AGENTS.md

## Regras
- Nunca modifique arquivos em /core sem aprovação
- Sempre rode `npm test` depois de qualquer mudança
- Use o padrão repository pattern para acesso a dados
- Commits devem seguir conventional commits
- Nunca adicione dependências sem justificativa no PR

Isso é radicalmente diferente do plan mode. O plan mode é “me diga o que vai fazer antes de fazer”. O AGENTS.md é “aqui estão as regras, agora faça”. Confiança com guardrails, não micromanagement.

O que devs produtivos estão fazendo agora

Conversei com devs que usam agentes de IA mais de 6 horas por dia. O padrão que mais aparece é:

1. CLAUDE.md/AGENTS.md bem escritos com regras claras do projeto
2. Prompts cirúrgicos: uma tarefa por prompt, escopo fechado
3. Branch por agente: cada tarefa do agente vive numa branch, review via PR
4. Testes como contrato: se os testes passam, o agente pode mergear
5. Zero plan mode: ninguém pede plano antes de executar

O dev mais produtivo que entrevistei disse algo que ficou na minha cabeça: “Eu não peço plano pro agente pelo mesmo motivo que não peço plano pra um compilador. Ele sabe o que fazer. Meu trabalho é definir o que eu quero, não como ele deve fazer.”

A analogia do GPS

Quando o GPS de carro surgiu, muita gente imprimia o mapa da rota antes de sair. “Vai que o GPS falha.” Hoje ninguém imprime mapa. A confiança no sistema aumentou porque o sistema ficou confiável.

Plan mode é o mapa impresso do GPS. Era necessário quando os agentes de IA eram ruins. Agora que eles navegam pelo código com fluência, o mapa virou peso morto.

Isso não significa confiança cega. Você ainda verifica se o GPS está te levando pro lugar certo. Olha a tela de vez em quando. Mas não planeja cada curva antecipadamente.

Quando plan mode ainda faz sentido

Preciso ser honesto: existem cenários onde planejar antes de agir ainda é a melhor abordagem.

Migrações de banco de dados em produção. Refatorações que afetam mais de 50 arquivos. Mudanças em infraestrutura crítica. Nesses casos, o custo de um erro é alto demais pra iterar livremente.

Mas esses são 5% dos casos. Os outros 95%, aqueles do dia a dia (adicionar feature, corrigir bug, escrever teste, refatorar função) funcionam melhor com execução direta e feedback rápido.

O erro é tratar plan mode como padrão universal quando ele deveria ser exceção.

Terry Tao e os matemáticos que a IA precisa

Por coincidência, no mesmo dia que o post da Ayman viralizou, Terry Tao (sim, o Terry Tao) publicou um texto dizendo que “vamos precisar de muito mais matemáticos” por causa da IA. A relação pode parecer distante, mas o ponto converge: a IA está mudando o que significa ser produtivo.

No caso dos devs, ser produtivo em 2026 não é escrever mais código. É saber direcionar agentes. E direcionar bem significa parar de planejar demais e começar a iterar mais rápido.

Os melhores devs que conheço tratam agentes de IA como junior devs muito rápidos. Você não pede pro junior escrever um documento de 10 páginas antes de codar. Você dá uma tarefa pequena, revisa, dá feedback, repete. Por que tratar o Claude ou o Cursor diferente?

O que vem depois do plan mode

O plan mode morreu, mas a necessidade que ele resolvia não morreu. Devs ainda precisam de visibilidade, controle e confiança ao trabalhar com agentes.

A próxima geração de ferramentas provavelmente vai trazer: diffs em tempo real mostrando o que o agente está fazendo; rollback automático se testes falharem; dashboards de “saúde” do codebase com mudanças recentes; e alertas inteligentes quando o agente se desvia do padrão esperado.

O futuro não é planejar mais. É observar melhor.

—

Fonte de inspiração: Plan mode is dead