Testei o Ultra Plan do Claude Code — Aqui esta a verdade
Eu estava no meio de uma migracao de dependencias — trocando tRPC v10 por v11 num monorepo com 47 definicoes de rotas — quando um amigo deixou uma mensagem no nosso Discord: "Ja experimentaste o /ultraplan?"
A minha primeira reacao honesta? Ceticismo. Eu usava o modo de planeamento local do Claude Code religiosamente ha meses. Shift+Tab, rever o plano, mudar para o modo de edicao, executar. O ritmo ja era uma segunda natureza. Por que delegaria esse processo a uma sessao de planeamento na nuvem quando o meu fluxo de trabalho no terminal ja era rapido?
Entao executei /ultraplan migrate all tRPC v10 routes to v11 with backward-compatible type exports e vi algo que nao esperava. Em segundos, o meu terminal deu-me um URL. Abri-o no browser. E la estava um plano de implementacao estruturado que nao apenas listava os ficheiros que precisavam de alteracao — mapeava as cadeias de dependencias entre rotas, assinalava tres assinaturas de tipo incompativeis que eu nao tinha considerado, e gerava um diagrama Mermaid mostrando a ordem de migracao que minimizaria as falhas nos testes ao longo do caminho.
O meu modo de planeamento local nunca tinha feito isso. Nem uma unica vez.
Isso foi ha duas semanas. Desde entao, executei o Ultra Plan em dez prompts diferentes — trocas simples de modelos, refactorizacoes complexas, scaffolding greenfield, auditorias de seguranca — testando-o contra o modo de planeamento local em cada um. O que descobri foi mais matizado do que "o Ultra Plan e melhor." A verdade envolve tres modos de planeamento ocultos, um sistema de AB testing que a maioria dos utilizadores nao sabe que existe, e um conjunto muito especifico de cenarios onde o Ultra Plan e genuinamente transformador versus onde e apenas uma interface mais elegante para o mesmo resultado.
Aqui esta tudo o que aprendi.
O que o Ultra Plan realmente e (e por que existe)
Antes de entrar nos resultados dos testes, precisas do modelo mental correto. Porque o Ultra Plan nao e simplesmente "modo de planeamento mas na nuvem." A arquitetura e fundamentalmente diferente, e compreender essa diferenca muda a forma como o usas.
Quando executas o modo de planeamento local com Shift+Tab no Claude Code, o planeamento acontece dentro da tua sessao de terminal. Mesma janela de contexto. Mesma instancia do modelo. Mesmas restricoes. A IA le o teu codebase, pensa nas alteracoes e apresenta um plano — tudo dentro dos limites da tua conversa atual.
O Ultra Plan quebra esse modelo por completo. Quando escreves /ultraplan seguido do teu prompt, o Claude Code inicia uma sessao de planeamento dedicada no Cloud Container Runtime da Anthropic — o que eles chamam de CCR. Essa sessao remota recebe o Opus 4.6, ate 30 minutos de tempo de computacao dedicado e acesso ao teu repositorio atraves de um snapshot sincronizado na nuvem. O planeamento acontece fora da tua maquina, num ambiente construido especificamente para analise profunda.
A diferenca pratica? O teu terminal fica livre. Enquanto o Ultra Plan processa a tua estrategia de migracao na nuvem, podes continuar a programar, executar testes ou iniciar outra sessao de Ultra Plan para uma tarefa completamente diferente. Tive tres sessoes de Ultra Plan a correr simultaneamente enquanto eu depurava um problema de CSS localmente. Tenta fazer isso com o modo de planeamento local.
Assim que o plano esta pronto, recebes um URL de sessao que abre no teu browser. E aqui e onde a experiencia diverge significativamente de qualquer coisa no terminal.
A interface web que muda a forma como revês os planos
Vou ser direto: a interface web e a maior melhoria na qualidade de vida que o Ultra Plan traz. E digo isto como alguem que vive no terminal.
Quando um plano aparece no teu browser, estas a olhar para um documento rico — nao uma parede de markdown a desfilar pelo teu terminal. Cabecalhos. Secoes recolhiveis. Blocos de codigo inline com destaque de sintaxe. E crucialmente, duas funcionalidades que fazem o planeamento colaborativo realmente funcionar: comentarios inline em partes especificas do plano e reacoes com emoji para sinalizacao rapida.
Isso parece trivial. Nao e.
Eis o motivo. Quando revejo um plano no terminal, o meu ciclo de feedback e assim: ler o plano, deslocar para cima ate a parte com que discordo, escrever "na verdade, para o passo 3, preferia usar o padrao repository em vez de consultas diretas," esperar que a IA regenere todo o plano, reler tudo de novo. Com a interface web, clico no passo 3, escrevo o meu comentario inline e peco uma revisao direcionada. A IA atualiza essa secao sem tocar no resto. A velocidade de iteracao e dramaticamente mais rapida.
Os diagramas Mermaid sao inconsistentes — as vezes aparecem, as vezes nao (mais sobre o motivo ja ja). Mas quando aparecem, sao genuinamente uteis. Para a migracao de tRPC, o Ultra Plan gerou um fluxograma de dependencias mostrando quais rotas dependiam de definicoes de tipo partilhadas, o que significava que eu podia ver imediatamente que migrar o userRouter antes do authRouter quebraria tres consumidores a jusante. Essa visualizacao ter-me-ia custado vinte minutos a mapear manualmente.
Depois de aprovares um plano — com ou sem revisoes — recebes tres opcoes:
- Executar na nuvem — o plano corre remotamente e pode abrir um PR diretamente
- Implementar aqui — teletransportar o plano de volta para a tua sessao de terminal atual
- Iniciar nova sessao — limpar a tua conversa atual e comecar de novo com o plano como contexto
Uso a opcao 2 em cerca de 80% das vezes. O plano chega ao meu terminal como contexto estruturado, e eu continuo a execucao localmente onde tenho controlo total sobre operacoes de ficheiros, execucao de testes e fluxo de trabalho Git. A opcao 1 e tentadora para tarefas simples, mas descobri que a execucao ainda beneficia da supervisao local — especialmente quando o plano envolve ficheiros que mudaram desde que o snapshot na nuvem foi criado.
Dito isto, o caminho de execucao na nuvem e para onde o Ultra Plan esta a ir. E para equipas que querem um pipeline de planeamento-para-PR com intervencao humana minima, ja esta quase la.
Dez prompts, dois modos, uma comparacao honesta
Falar de funcionalidades e facil. O que importa e o desempenho. Entao executei os mesmos dez prompts tanto no Ultra Plan como no modo de planeamento local, comparando o resultado em quatro dimensoes: velocidade, qualidade do plano, detecao de riscos e executabilidade.
Aqui esta o que testei:
Tarefas simples:
- Trocar Qwen 3.5 por Gemma 4 como modelo de inferencia local
- Adicionar um toggle de modo escuro a um componente React existente
- Renomear uma coluna da base de dados com migracao
Complexidade media: 4. Refatorizar middleware de autenticacao de baseado em sessoes para JWT 5. Adicionar limitacao de taxa a todos os endpoints de API com limiares configuraveis 6. Migrar um esquema Prisma de PostgreSQL para MySQL
Alta complexidade: 7. Atualizar tRPC v10 para v11 num monorepo 8. Implementar uma camada de isolamento de dados multi-tenant 9. Adicionar encriptacao ponta-a-ponta para mensagens de utilizadores 10. Auditar um codebase para vulnerabilidades OWASP Top 10
Os resultados dividiram-se claramente ao longo das linhas de complexidade — mas nao da forma que eu esperava.
Onde o Ultra Plan igualou o modo local (e nada mais)
Para os prompts 1 a 3 — as tarefas simples — o Ultra Plan nao ofereceu nenhuma vantagem significativa sobre o modo de planeamento local. Os planos eram estruturalmente semelhantes. Os mesmos ficheiros foram identificados. Os mesmos passos foram propostos. A unica diferenca foi a apresentacao: o resultado do Ultra Plan parecia mais bonito no browser.
Trocar Qwen 3.5 por Gemma 4 gerou planos quase identicos em ambos os modos. Plano local: alterar a configuracao do modelo, atualizar o endpoint de inferencia, ajustar as configuracoes do tokenizador, testar. Ultra Plan: mesmos passos, descricoes ligeiramente mais detalhadas, uma nota sobre verificar compatibilidade — mas nada que eu nao tivesse apanhado sozinho.
Para tarefas simples, a viagem adicional ida e volta a nuvem adiciona latencia sem adicionar conhecimento. O modo de planeamento local tratou destas em 15-30 segundos. O Ultra Plan precisou de 45-90 segundos para o mesmo resultado, porque a sessao na nuvem precisa de iniciar, sincronizar o snapshot do repositorio e renderizar a interface web.
A minha recomendacao: se consegues descrever a alteracao numa frase e ja sabes quais ficheiros precisam de ser tocados, fica no modo de planeamento local. A vantagem de velocidade e real.
Onde o Ultra Plan se destacou — e por quanto
Os prompts 4 a 6 — complexidade media — mostraram a primeira diferenca significativa. O Ultra Plan comecou a detetar coisas que o modo de planeamento local falhou.
A migracao para JWT (prompt 4) e um bom exemplo. O modo de planeamento local deu-me um plano razoavel: criar o utilitario JWT, atualizar o middleware de autenticacao, modificar o endpoint de login para emitir tokens, adicionar logica de renovacao de tokens. Solido. Correto. Mas falhou o problema de limpeza de sessoes — utilizadores existentes tinham sessoes ativas que precisariam de ser invalidadas durante a janela de migracao. Tambem nao mencionou a necessidade de atualizar a configuracao CORS para o novo padrao do cabecalho Authorization.
O Ultra Plan apanhou ambos. O plano incluia um passo de migracao dedicado para sessoes ativas, uma estrategia de rollback caso a verificacao JWT falhasse para um limiar de utilizadores, e uma secao de atualizacao CORS. A detecao de riscos foi notavelmente mais profunda.
Para a migracao Prisma (prompt 6), o modo de planeamento local propôs uma reescrita direta do esquema. O Ultra Plan assinalou quatro armadilhas especificas do MySQL: a diferenca do tipo @db.Text, a falta de suporte nativo a arrays exigindo uma tabela de juncao, a diferenca de sensibilidade a maiusculas e minusculas em comparacoes de strings, e uma limitacao de comprimento de indice que quebraria um dos meus indices compostos. Três desses quatro teriam causado erros em tempo de execucao que me teriam custado horas de depuracao.
A diferenca alargou-se ainda mais na alta complexidade. A migracao de tRPC v10 para v11 (prompt 7) foi onde o Ultra Plan realmente provou o seu valor. O modo de planeamento local produziu um guia de migracao razoavel. O Ultra Plan produziu o que so posso descrever como um documento de engenharia — completo com ordenacao de dependencias, analise de compatibilidade de tipos, uma lista de APIs descontinuadas que eu estava a usar com os seus substitutos v11, e uma estrategia de implementacao faseada que me permitia migrar rota a rota em vez de tudo de uma vez.
A auditoria de seguranca (prompt 10) mostrou a diferenca mais dramatica. O modo de planeamento local identificou problemas superficiais: validacao de entrada em falta, alguns vetores de injecao SQL, segredos codificados no codigo. O Ultra Plan encontrou esses mais tres problemas mais profundos: uma referencia direta a objeto insegura no endpoint de perfil de utilizador, uma condicao de corrida no fluxo de reset de palavra-passe que poderia permitir a reutilizacao de tokens, e um limite de taxa em falta no endpoint de login que o tornava vulneravel a credential stuffing. O plano local assinalou 6 problemas. O Ultra Plan assinalou 11.
Mas aqui e onde a historia se complica.
Os tres modos ocultos de que ninguem te fala
Depois de executar estes testes, a inconsistencia incomodava-me. Por que e que o Ultra Plan gerava diagramas Mermaid para alguns prompts mas nao para outros? Por que e que a auditoria de seguranca produziu uma analise multi-perspetiva enquanto a troca de modelo produziu basicamente o mesmo resultado que o modo local?
Investiguei o codigo fonte do Claude Code — especificamente os prompts de sistema divulgados que vieram a publico apos o incidente do source map do npm em marco de 2026 — e encontrei algo que explica tudo.
O Ultra Plan nao executa um modo de planeamento. Executa tres. E a Anthropic atribui-os dinamicamente, invisivelmente, com base em configuracao do lado do servidor.
Simple Plan e a base. E estruturalmente semelhante ao modo de planeamento local — uma analise direta que identifica ficheiros, propoe passos e produz um plano limpo. Sem diagramas. Sem analise multi-perspetiva. Quando recebes um Simple Plan, estas essencialmente a receber o modo de planeamento local com uma interface mais bonita e execucao na nuvem. Foi isto que recebi para as tarefas simples.
Visual Plan adiciona diagramas. A mesma profundidade analitica do Simple Plan, mas com geracao de diagramas Mermaid e Asy como camada adicional. O fluxograma de dependencias que obtive para a migracao de tRPC? Isso foi um Visual Plan. Os diagramas nao sao decoracao — codificam relacoes estruturais que o texto simples tem dificuldade em comunicar. Mas a analise em si nao e mais profunda que o Simple Plan.
Deep Plan e aquele que muda o jogo. E e aquele que explicou os meus resultados da auditoria de seguranca.
O Deep Plan ativa um sistema multi-agente. Nao e um modelo a pensar no teu problema — sao multiplos sub-agentes especializados, cada um focado numa dimensao diferente:
- Um agente analisa codigo e arquitetura — examinando as implicacoes estruturais da alteracao
- Um agente localiza todos os ficheiros que precisam de modificacao — nao apenas os alvos obvios, mas consumidores a jusante e ficheiros de teste
- Um agente identifica riscos, casos limite e conflitos de dependencias — o especialista em "o que pode correr mal"
- Um agente revê o plano completo quanto a consistencia logica, mitigacoes em falta e ordem de execucao
Estes agentes correm em paralelo, contribuem as suas descobertas para um contexto partilhado, e o sistema sintetiza os seus resultados num plano unificado. A auditoria de seguranca que encontrou 11 problemas em vez de 6? Isso foi Deep Plan. O agente de risco assinalou especificamente a condicao de corrida no fluxo de reset de palavra-passe — algo que uma analise de passo unico consistentemente falha porque requer raciocinar sobre estados concorrentes.
Aqui esta a parte que me frustrou: nao podes escolher qual modo recebes.
Es parte de um teste AB (e a Anthropic sabe disso)
A atribuicao de modo nao e aleatoria no sentido de atirar uma moeda ao ar. A Anthropic controla-a atraves de configuracoes do lado do servidor — essencialmente um sistema de feature flags que determina qual variante de planeamento cada utilizador recebe para cada sessao. O codigo fonte divulgado confirma que isto e um framework de AB testing deliberado.
A Anthropic esta a medir varias coisas atraves deste sistema:
- Taxas de aceitacao dos utilizadores para cada variante de planeamento — os utilizadores aprovam e executam Simple Plans a mesma taxa que Deep Plans?
- Eficacia dos prompts de planeamento — quais prompts de sistema produzem planos que os utilizadores realmente seguem?
- Desempenho do modelo — a infraestrutura poderia ser usada para testar proximas versoes do modelo entre si em cenarios de planeamento ao vivo
Isto explica por que a minha experiencia foi inconsistente entre execucoes. Algumas das minhas sessoes de Ultra Plan estavam a alcancar Simple Plan (quase identico ao modo local), enquanto outras estavam a alcancar Deep Plan (dramaticamente melhor). Eu nao estava a comparar "Ultra Plan vs Plano Local" de forma controlada. Estava a comparar "qualquer variante que o sistema AB da Anthropic me atribuiu" contra o plano local.
Quando percebi isto, voltei atras e reexecutei os prompts de alta complexidade varias vezes. A migracao de tRPC produziu planos notavelmente diferentes em tres execucoes — um com diagramas, um sem, um com a analise de riscos multi-agente. Mesmo prompt. Mesmo estado do repositorio. Variantes de planeamento diferentes.
Para utilizadores que se preocupam com consistencia — e se estas a construir software de producao, deverias preocupar-te — isto e a coisa mais importante a compreender sobre o Ultra Plan neste momento. O teto de qualidade e genuinamente alto. O piso de qualidade e basicamente o modo de planeamento local com latencia extra. E nao tens controlo sobre qual recebes.
Essa incerteza e a razao pela qual, por agora, optei por um fluxo de trabalho especifico que me da o melhor dos dois mundos. Mas antes de o partilhar, ha mais um detalhe tecnico que vale a pena compreender.
Como o Ultra Plan le o teu codebase (e onde falha)
Quando ativas o /ultraplan, o Claude Code nao carrega todo o teu repositorio para a nuvem da Anthropic. Cria um snapshot — uma copia pontual sincronizada para o ambiente CCR onde a sessao de planeamento corre. O agente de planeamento le entao deste snapshot como se fosse um codebase local.
Isto cria uma limitacao subtil mas importante: a sessao na nuvem nao vê alteracoes que facas apos lancar o Ultra Plan. Se ativares um Ultra Plan para uma migracao de base de dados, e depois modificares o esquema localmente enquanto o plano esta a ser gerado, o plano estara baseado no esquema antigo. Aconteceu-me uma vez — aprovei um plano que referenciava uma coluna que eu ja tinha renomeado durante a janela de planeamento.
A janela de computacao de 30 minutos e generosa para a maioria das tarefas. A minha sessao de Ultra Plan mais longa — a auditoria OWASP completa — completou-se em cerca de 8 minutos. Mas a janela importa para repositorios extremamente grandes onde a analise inicial do codebase demora um tempo consideravel. A Anthropic nao publicou limites de tamanho de repositorio para o CCR, mas nos meus testes, repositorios com menos de 500 MB de codigo fonte (excluindo node_modules e artefactos de compilacao) planearam sem problemas.
Mais uma coisa sobre a abordagem de snapshots: o Ultra Plan funciona melhor com repositorios alojados no GitHub. A sincronizacao depende do remoto do teu repositorio, o que significa que repositorios apenas locais ou repositorios com grandes alteracoes nao comitadas podem produzir planos baseados em contexto incompleto. Aprendi a fazer sempre commit e push antes de executar /ultraplan para qualquer coisa importante.
Se preferires que alguem configure um fluxo de trabalho otimizado do Claude Code de raiz — completo com integracao Ultra Plan, skills personalizados e orquestracao de agentes — aceito esse tipo de projetos. Podes ver o que construi em fiverr.com/s/EgxYmWD.
O meu fluxo de trabalho real — Como uso o Ultra Plan hoje
Apos duas semanas de testes, este e o fluxo de trabalho em que me fixei. Nao e "usar sempre o Ultra Plan" nem "saltar completamente." E condicional, e as condicoes sao especificas.
Para tarefas que posso descrever numa frase e onde ja conheco os ficheiros afetados: Modo de planeamento local. Sem viagem de ida e volta a nuvem necessaria. Shift+Tab, rever, executar. Rapido.
Para tarefas envolvendo mais de 5 ficheiros, cadeias de dependencias ou alteracoes incompativeis: Ultra Plan. A analise multi-agente (quando recebes Deep Plan) apanha riscos que o planeamento de passo unico consistentemente falha. A interface web torna a iteracao mais rapida. Mesmo quando recebo Simple Plan, a revisao no browser e mais confortavel para planos complexos.
Para auditorias de seguranca e revisoes de arquitetura: Ultra Plan, sempre. A variante Deep Plan e dramaticamente melhor a encontrar vulnerabilidades nao obvias. E uma vez que estas sao avaliacoes de alto risco onde falhar um caso limite tem consequencias reais, prefiro aceitar o impacto de latencia pela hipotese de uma analise mais profunda.
Para alteracoes urgentes onde cada segundo conta: Modo de planeamento local. A viagem de ida e volta do Ultra Plan adiciona 30-90 segundos antes de sequer veres o plano. Quando a producao esta em baixo e preciso de uma correcao rapida, essa latencia e inaceitavel.
Para multitarefa: O Ultra Plan e imbativel. Lanço regularmente duas ou tres sessoes de Ultra Plan para diferentes tarefas, e depois revejo e aprovo a medida que ficam prontas. Este fluxo de trabalho de planeamento paralelo e algo que o modo local simplesmente nao consegue fazer — cada plano local bloqueia o teu terminal ate terminar.
O truque do Skill de Deep Plan
Aqui esta o ponto mais tatico de toda esta publicacao.
Uma vez que a Anthropic nao te deixa escolher qual variante de planeamento recebes, e o Deep Plan produz os melhores resultados por uma margem significativa, extrai a estrutura do prompt de sistema do Deep Plan e transformei-a num skill personalizado do Claude Code.
A abordagem: criar um skill que imita o padrao de analise multi-agente do Deep Plan localmente. O skill instrui o Claude Code a analisar o prompt atraves de quatro lentes sequenciais — impacto arquitetural, identificacao de ficheiros, avaliacao de riscos e revisao do plano — antes de sintetizar um plano unificado. Nao e identico ao Deep Plan real (que executa agentes paralelos verdadeiros no CCR), mas aproxima 80% da melhoria de qualidade nos meus testes.
Aqui esta o esqueleto:
---
name: deep-plan
description: >
Multi-perspective planning for complex code changes.
Trigger when user asks for a detailed plan, migration
strategy, or architecture review.
---
## Deep Plan — Multi-Agent Analysis Skill
### Phase 1: Architecture Analysis
Analyze the requested change from a structural perspective.
Identify affected modules, data flows, and integration points.
Map dependencies between components.
### Phase 2: File Discovery
Locate ALL files that need modification — not just the obvious
targets. Include test files, type definitions, configuration
files, and downstream consumers.
### Phase 3: Risk Assessment
For each proposed change, identify:
- Edge cases that could cause runtime failures
- Breaking changes for existing consumers
- Race conditions or state management issues
- Security implications
- Rollback complexity
### Phase 4: Plan Synthesis & Review
Combine findings from all phases into a unified implementation
plan. Order steps by dependency chain. Flag any phase where
findings conflict. Include rollback procedures for each step.
### Output Format
Use numbered steps with sub-items. Include file paths.
Generate a Mermaid dependency diagram if more than 5 files
are affected. End with a risk summary table.
Isto da-me analise de qualidade Deep Plan a pedido, sem a lotaria do AB testing. A contrapartida e velocidade — executar isto localmente demora mais do que um plano de passo unico porque sao quatro passagens de analise sequenciais. Mas para tarefas complexas, os dois minutos extra de planeamento poupam horas de depuracao.
Continuo a usar o comando /ultraplan real para cenarios de multitarefa e quando quero a experiencia de revisao na interface web. Mas para os meus planeamentos de maior risco — aqueles onde preciso de profundidade garantida — o skill personalizado da-me controlo que o Ultra Plan atualmente nao oferece.
O que isto revela sobre o rumo do Claude Code
Recua um momento dos detalhes taticos e observa o que o Ultra Plan revela sobre o roteiro da Anthropic.
A infraestrutura CCR nao e so para planeamento. E um ambiente de execucao na nuvem de proposito geral. Hoje executa sessoes de planeamento. Amanha — e isto e especulacao baseada na arquitetura, nao conhecimento interno — poderia executar sessoes de implementacao completas, suites de testes ou ate pipelines de integracao continua alimentados por agentes do Claude Code.
O framework de AB testing e igualmente revelador. A Anthropic esta a usar sessoes de Ultra Plan ao vivo para otimizar prompts de planeamento e medir quais abordagens produzem planos que os utilizadores realmente executam. Esta e uma retroalimentacao ao vivo para melhorar a capacidade de planeamento do modelo. Cada vez que aprovas ou rejeitas um Ultra Plan, estas a contribuir dados para esse processo de otimizacao.
A arquitetura multi-agente do Deep Plan e a peca mais visionaria. Hoje executa tres a quatro sub-agentes especializados para planeamento. O padrao generaliza-se para qualquer tarefa complexa: agentes de implementacao, agentes de testes, agentes de documentacao, agentes de revisao de seguranca — cada um com prompts de sistema especializados, a correr em paralelo, sintetizando os seus resultados. A funcionalidade de equipas de agentes do Claude Code ja faz algo disto localmente. A infraestrutura do Ultra Plan sugere que a Anthropic esta a construir a espinha dorsal na nuvem para o executar em escala.
Espero tres coisas nos proximos seis meses:
- Modos de planeamento selecionaveis pelo utilizador — a fase de AB testing terminara e poderemos escolher entre Simple, Visual ou Deep Plan explicitamente
- Melhorias na execucao na nuvem — executar planos no CCR com criacao direta de PR tornara-se o caminho padrao para equipas
- Sessoes de planeamento persistentes — a capacidade de guardar, partilhar e voltar a sessoes de Ultra Plan entre membros da equipa
Quer estas previsoes se concretizem ou nao, a direcao e clara: o Claude Code esta a tornar-se uma ferramenta de planeamento primeiro onde a execucao e a parte facil.
As contrapartidas honestas que deves conhecer
O Ultra Plan nao e uma melhoria pura. Aqui estao as limitacoes que encontrei em uso real, e nenhum dos materiais promocionais as menciona.
O desfasamento do snapshot e real. A tua sessao na nuvem planeia contra uma copia congelada do teu repositorio. Se estiveres a desenvolver ativamente enquanto o plano e gerado, receberás recomendacoes baseadas em codigo desatualizado. Faz sempre commit e push antes de lancar o Ultra Plan para tarefas criticas.
Nao podes controlar a variante de planeamento. Esta e a minha maior frustracao. O Deep Plan e significativamente melhor que o Simple Plan, mas o sistema decide qual recebes. Para uma funcionalidade que supostamente ajuda no planeamento de alto risco, a aleatoriedade parece um defeito de design — mesmo que a justificacao do AB testing faca sentido da perspetiva da Anthropic.
A interface web requer mudanca de contexto. Saltar do terminal para o browser para rever um plano quebra o fluxo. Sou um programador orientado pelo teclado. Cada vez que pego no rato para clicar numa secao do plano no browser, uma pequena parte de mim morre. Os comentarios inline sao otimos quando ja la estas, mas a transicao do terminal para o browser e abrupta.
A latencia importa para trabalho iterativo. Quando estou num ciclo apertado de construir-testar-depurar, o tempo de resposta de 15 segundos do modo de planeamento local ganha aos 45-90 segundos do Ultra Plan todas as vezes. O Ultra Plan e uma ferramenta de pensamento profundo, nao uma ferramenta de feedback rapido.
A janela de 30 minutos e maioritariamente teorica. Nenhuma das minhas sessoes de Ultra Plan excedeu 10 minutos. Mas se estiveres a trabalhar com um codebase excepcionalmente grande ou a pedir uma analise que requer a leitura de milhares de ficheiros, a janela pode tornar-se uma restricao. Pessoalmente nao a atingi.
Requer Claude Code na web. O Ultra Plan precisa de uma conta conectada e um repositorio alojado no GitHub. Se estiveres a trabalhar com repositorios apenas locais, instancias privadas do GitLab ou num ambiente isolado, o Ultra Plan nao e uma opcao. O modo de planeamento local e o teu unico caminho.
Estas nao sao fatores decisivos. Sao o tipo de pontos de friccao que importam quando estas a decidir se adotas uma nova ferramenta para trabalho de producao versus apenas brincar com ela em projetos paralelos. Conhece-os antecipadamente.
Entao, deves mesmo usar o Ultra Plan?
Ha duas semanas, teria dado uma resposta simples. Agora e mais honesta.
Se estas a fazer refactorizacoes complexas, atualizacoes de dependencias, auditorias de seguranca ou alteracoes de arquitetura — e consegues tolerar a lotaria do AB testing — o Ultra Plan vale a pena adicionar ao teu fluxo de trabalho. O teto de qualidade quando apanhas Deep Plan e significativamente mais alto do que qualquer coisa que o modo de planeamento local produz. A interface web torna a revisao e iteracao do plano mais rapida para alteracoes nao triviais. E a capacidade de planeamento paralelo e genuinamente unica.
Se a maior parte do teu trabalho envolve alteracoes direcionadas a ficheiros conhecidos, o modo de planeamento local continua a ser mais rapido e previsivel. Nao adiciones latencia na nuvem para tarefas que nao precisam de analise a escala da nuvem.
Se queres qualidade de Deep Plan garantida sem a aleatoriedade, constroi o skill personalizado que descrevi acima. Executa-o localmente. Aceita a contrapartida de velocidade pela garantia de profundidade.
E se es o tipo de programador que acompanha de perto o comportamento das suas ferramentas — o que, se leste ate aqui, provavelmente es — continua a observar os padroes de AB testing. Executa o mesmo prompt varias vezes. Nota quando recebes diagramas versus quando nao. Nota quando a analise de riscos e superficial versus cirurgica. Compreender qual variante estas a receber ajuda-te a calibrar a tua confianca no resultado.
O que ninguem diz sobre o Ultra Plan e isto: nao e uma funcionalidade acabada. E uma pre-visualizacao de investigacao que funciona simultaneamente como plataforma de otimizacao ao vivo para as capacidades de planeamento da Anthropic. Estas simultaneamente a usar uma ferramenta e a treina-la. Isso nao e uma critica — e a realidade de construir na fronteira do desenvolvimento assistido por IA. Mas significa que o Ultra Plan que usas hoje nao sera o Ultra Plan que usaras daqui a tres meses. E essa versao futura, informada por milhoes de sessoes de planeamento reais, sera quase certamente melhor do que qualquer coisa que possamos construir com skills personalizados.
Mantenho o /ultraplan na minha rotacao diaria. Mantenho o meu skill de Deep Plan como backup. E executo ambos, comparo resultados e arquivo cada diferenca como um ponto de dados.
Porque os engenheiros que compreendem as suas ferramentas profundamente — nao apenas o que as ferramentas fazem, mas como funcionam por baixo — sao os que mais tiram partido delas. Isso tem sido verdade desde o primeiro compilador, e continua a ser verdade agora.
Perguntas frequentes
Como executo o Ultra Plan no Claude Code?
Escreve /ultraplan seguido do teu prompt de planeamento no terminal do Claude Code. A sessao inicia na nuvem da Anthropic e recebes um URL no browser para rever o plano gerado. Precisas de uma conta Claude Code on the web e um repositorio alojado no GitHub.
O Ultra Plan e mais rapido que o modo de planeamento local?
Para o computo de planeamento, o Ultra Plan corre ate 2x mais rapido porque usa recursos dedicados na nuvem com Opus 4.6. Mas a viagem de ida e volta total — incluindo o arranque na nuvem e a revisao no browser — adiciona 30-90 segundos comparado com os 15-30 segundos de resposta do modo de planeamento local para tarefas simples.
Posso escolher entre Simple Plan, Visual Plan e Deep Plan?
Atualmente nao. A Anthropic atribui variantes de planeamento atraves de configuracao do lado do servidor como parte do seu framework de AB testing. Podes aproximar a qualidade do Deep Plan construindo um skill personalizado que replica o seu padrao de analise multi-agente localmente.
O Ultra Plan funciona com repositorios privados?
O Ultra Plan requer um repositorio GitHub acessivel atraves da tua conta Claude Code on the web. Repositorios apenas locais, repositorios alojados no GitLab e ambientes isolados nao sao suportados. Para essas configuracoes, o modo de planeamento local continua a ser a unica opcao.
O que acontece ao meu codigo durante sessoes de Ultra Plan?
O Claude Code cria um snapshot de leitura apenas do teu repositorio sincronizado com a nuvem. O agente de planeamento analisa este snapshot — nao pode modificar os teus ficheiros locais. As alteracoes so acontecem depois de aprovares o plano e escolheres um caminho de execucao (nuvem ou local).
Vamos trabalhar juntos
Procuras construir sistemas de IA, automatizar fluxos de trabalho ou escalar a tua infraestrutura tecnologica? Adoraria ajudar.
- Fiverr (desenvolvimentos personalizados e integracoes): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (solucoes empresariais): ramlit.com
- ColorPark (design e branding): colorpark.io
- xCyberSecurity (servicos de seguranca): xcybersecurity.io
