Qué es el modo plan
Imagínalo así: contratas a un excelente albañil. Antes de que empiece a derribar paredes, le pides el plano. Lo dibuja, tú lo revisas, lo ajustas y solo entonces él ejecuta la obra. Plan mode es el plano antes de la obra.
En el modo normal de Claude Code, pides algo y se pone a hacerlo: lee archivos, edita código y ejecuta comandos. Funciona bien para tareas simples. Pero cuando la tarea es compleja, es como construir sin planos. El plan mode cambia ese comportamiento: en vez de actuar, Claude primero piensa y propone qué pretende hacer.
Para activarlo, solo tienes que presionar Shift+Tab antes de enviar tu mensaje, o incluye la palabra "plan" en el prompt. Claude analizará el codebase, considerará las implicaciones y presentará un plan estructurado con los pasos que pretende seguir. Lo lees, lo ajustas si es necesario y solo entonces autorizas la ejecución.
En 1 frase: plan mode = Claude muestra lo que va a hacer antes de hacerlo; tú decides si continuar.
Cuándo usarlo (y cuándo no)
Imagínalo así: tú no haces un plano para cambiar una bombilla. Pero sí lo haces para remodelar la cocina. El criterio es el mismo: complejidad y riesgo.
El modo Plan destaca cuando la tarea implica varios archivos, decisiones de arquitectura o cuando es caro revertir el error. Para un «agrega un console.log aquí», no tiene sentido planificar. Para «refactoriza el sistema de autenticación para usar OAuth», planificar puede ahorrarte horas.
La regla práctica: si la tarea afecta más de 3 archivos o no tienes claro el camino, usa plan mode. Si es un cambio puntual y reversible, ve directo. Con el tiempo calibrarás esa intuición.
Usa el modo plan
- - Nueva funcionalidad con varios archivos
- - Refactorización que cambia interfaces
- - Un bug que no sabes dónde está
- - Migraciones de dependencias
Ve directo (sin plan)
- - Corrección de un error tipográfico o de una cadena de texto
- - Agregar un log o comentario
- - Cambio aislado en 1 archivo
- - Tarea cuyo camino ya conoces
En 1 frase: plan mode para lo complejo y arriesgado; ejecución directa para lo simple y reversible.
Anatomía de un plan
Imagínalo así: una buena receta de pastel tiene ingredientes, pasos numerados y tiempo de horneado. Un buen plan tiene la misma estructura: qué hacer, en qué orden y qué verificar.
Un buen plan de Claude Code tiene cuatro partes: (1) objetivo claro en una frase, (2) lista de archivos que se modificarán, (3) pasos ordenados de lo que se hará en cada uno, y (4) riesgos o puntos de atención. Si falta alguna de estas partes, pídele a Claude que la complete antes de aprobar.
La calidad del plan depende directamente de la calidad de tu solicitud. Un prompt vago genera un plan vago. Cuanto más contexto des (qué patrones seguir, qué archivos revisar, qué no cambiar), más preciso será el plan.
En 1 frase: un plan necesita un objetivo, archivos, pasos y riesgos; si falta algo, pídelo antes de aprobarlo.
Flujo de aprobación — revisión y ajustes
Imagínalo así: El arquitecto entrega el plano. No firmas con los ojos cerrados. Lo revisas, preguntas «¿y si llueve?», él lo ajusta y tú firmas la versión revisada.
Cuando Claude presenta el plan, tienes tres opciones: aprobar y lo ejecuta, rechazar y empezar de nuevo, o refinar pidiendo ajustes específicos. La tercera opción es la más poderosa: "buen plan, pero cambia el enfoque del paso 3" o "agrega pruebas unitarias al plan".
El flujo de aprobación es tu punto de control. Es donde aplicas el criterio humano: ¿el plan tiene sentido para el proyecto? ¿Respeta los estándares existentes? ¿Afecta solo lo necesario? Si alguna respuesta es "no", ajústalo antes de aprobarlo.
¿Qué haces cuando el plan está 90% bien?
En 1 frase: El approval flow es tu punto de control de calidad; casi siempre es mejor ajustar que aprobar a ciegas.
Iterar el plan antes de ejecutarlo
Imagínalo así: un escritor revisa el borrador 3 veces antes de publicar. Cada revisión cuesta minutos; una publicación incorrecta cuesta horas. Con los planes es igual: cada iteración del plan es barata; corregir después de ejecutarlo es caro.
La técnica más poderosa del plan mode es iterar varias veces en el plan antes de ejecutar. No necesitas aprobar el primer borrador. Pídele a Claude: "refina el paso 2, considera que ya tenemos un middleware de auth", o "cambia el orden, haz las pruebas primero". Cada ronda cuesta pocos tokens; corregir código equivocado después cuesta mucho más.
Trata el plan como un documento vivo. La primera versión rara vez es la mejor. Dos o tres rondas de refinamiento suelen ser el punto ideal: ya capturan los matices sin gastar demasiado en planificación.
Consejo práctico
Usa preguntas específicas en la iteración: «¿y si el usuario no está autenticado?», «¿cómo afecta esto al componente X?», «agrega manejo de errores al paso 4». Las preguntas genéricas como «mejora el plan» generan respuestas genéricas.
En 1 frase: iterar en el plan es barato; corregir después de la ejecución es caro. Refínalo 2-3 veces antes de aprobarlo.
Antipatrones comunes
Tres errores que casi todo el mundo comete al principio:
Antipatrones del modo plan
- Aprobación automática sin revisión: aprobar sin leer. El plan parece largo y haces clic en "go" sin revisarlo. Resultado: Claude hace algo que no querías y pierdes más tiempo revirtiéndolo.
- Planificación excesiva: planificar demasiado, iterar 10 veces sobre el plan sin ejecutarlo nunca. En algún momento, es mejor ejecutar y corregir que seguir refinando el plan indefinidamente.
- Desviación del plan: aprobar el plan y luego, en el siguiente prompt, dar instrucciones que lo contradicen. Claude se confunde entre lo que se había planeado y lo que le estás pidiendo ahora.
Antes de aprovar o plano, cheque: [ ] Li todos os passos (nao so o titulo) [ ] O plano lista os arquivos que serao tocados [ ] Nenhum passo toca algo que nao deveria [ ] Riscos estao identificados [ ] 2-3 rounds de refinamento ja foram feitos Se 3+ falharam, refine antes de aprovar.
En 1 frase: no apruebes sin leer, no planifiques sin parar y no contradigas el plan después de aprobarlo.
Resumen del módulo
Siguiente módulo:
2.2 — Planes que funcionan: cómo crear planes eficaces para features, refactors y correcciones de errores.