Modo plan en Claude Code: cuándo usarlo y cuándo estorba

El modo plan de Claude Code es la función que más me ha salvado y la que más tiempo me ha hecho perder. Las dos cosas.

Te explico qué es en una línea: le pides algo, y en vez de ponerse a tocar archivos, te escribe lo que piensa hacer y espera a que le digas que sí. Nada se modifica hasta que apruebas. Se activa pulsando shift más tabulador hasta que abajo veas que pone "plan mode".

Suena a que deberías usarlo siempre. No. Usarlo siempre es una forma elegante de no terminar nada.

¿Cuándo conviene usar el modo plan?

Cuando el coste de equivocarse es alto y el coste de revisar es bajo. Ese es el criterio entero, y todo lo demás son ejemplos de eso.

En la práctica, yo lo activo en cuatro situaciones.

Cuando toca varios archivos a la vez. Si le pido que cambie cómo se llama una función que se usa en veinte sitios, quiero ver la lista de los veinte sitios antes de que empiece. No porque desconfíe, sino porque en esa lista voy a encontrar dos archivos que yo había olvidado que existían.

Cuando no sé bien lo que quiero. Esto es más frecuente de lo que parece. Le describo el problema, le pido el plan, y al leer el plan me doy cuenta de que lo que quería era otra cosa. El plan aquí no sirve para controlarle a él, sirve para pensar yo.

Cuando el proyecto ya tiene cosas dentro que funcionan. En un proyecto vacío no hay nada que romper. En un proyecto con seis meses de trabajo encima, un cambio mal entendido te puede tumbar algo que llevaba funcionando desde enero y que no vas a notar hasta dentro de dos semanas.

Cuando la tarea lleva la palabra "todos". "Actualiza todos los posts", "renombra todas las imágenes", "revisa todos los archivos de esta carpeta". El plural masivo es la señal más fiable de que hay que mirar antes de saltar.

¿Y cuándo estorba?

Cuando la tarea es pequeña, reversible y la tienes clara en la cabeza.

"Cámbiame el color del botón a azul". "Arregla esta falta de ortografía". "Añade un campo más a este formulario". Pedirle un plan para eso es pedirle que te escriba tres párrafos explicándote que va a cambiar una línea. Lees los tres párrafos, dices que sí, y has tardado más en leer que lo que habrías tardado en deshacer el cambio si hubiera salido mal.

Estorba también cuando estás explorando. Hay días en los que no sabes qué quieres construir y lo que necesitas es ver cosas en pantalla rápido, probar, tirar, probar otra vez. Meter una puerta de aprobación en medio de eso te mata el ritmo. En modo exploración yo trabajo directo y con la red de seguridad puesta por otro lado, que ahora te cuento cuál es.

Y estorba, sobre todo, cuando se convierte en un ritual. Esa es la trampa de verdad.

La trampa: planificar como forma de procrastinar

Aquí es donde me he pillado a mí mismo varias veces.

Le pides un plan. Lees el plan. Te parece que el punto tres podría estar mejor. Le pides que lo replantee. Te devuelve otro plan. Ahora es el punto cinco el que no te convence. Le pides que lo afine. Tercer plan.

Cuarenta minutos después tienes un documento precioso de doce puntos y no has escrito una sola línea de código.

Esto se siente como trabajo. Se siente productivo. Estás leyendo, valorando, decidiendo. Pero no ha cambiado nada en el proyecto, y el proyecto es lo único que cuenta.

Mi regla: dos vueltas de plan como máximo. Si tras la segunda revisión sigo sin verlo claro, el problema no es el plan, es que no tengo claro el objetivo. Y eso no se arregla pidiendo otro plan, se arregla parando y escribiendo en dos frases qué quiero conseguir.

Es la misma tensión de fondo que hay en cualquier trabajo con IA y que desarrollo en planificar frente a ejecutar con Claude Code: la planificación tiene rendimientos decrecientes muy rápidos, y el punto donde dejan de compensar llega antes de lo que te crees.

Cómo leer un plan sin leerlo entero

Los planes son largos. Nadie los lee de arriba abajo, y menos el quinto del día. Yo miro cuatro cosas.

La lista de archivos que va a tocar. Es lo primero. Si aparece un archivo que no esperabas, para ahí y pregunta por qué. Ese es el noventa por ciento del valor del modo plan concentrado en diez segundos de lectura.

Si va a borrar algo. Busca las palabras eliminar, borrar, reemplazar. Crear cosas nuevas rara vez rompe nada. Quitar cosas sí.

Si toca configuración o dependencias. Instalar librerías nuevas, cambiar versiones, tocar archivos de configuración. Ahí es donde aparecen los problemas raros que luego cuesta media tarde diagnosticar.

El último punto. Suele ser el más ambiguo, porque es donde mete el "y ajustar lo que haga falta". Ese "lo que haga falta" es un cheque en blanco. Píntalo bien antes de aprobar.

Lo demás lo puedes ojear en diagonal.

La alternativa al modo plan: la red de seguridad

Aquí viene lo que más me ha cambiado la forma de trabajar. El modo plan es una de las dos maneras de protegerte, y muchas veces no es la mejor.

La otra es tener control de versiones. Si cada trozo de trabajo terminado queda guardado, puedes dejarle ir a toda velocidad sin aprobar nada, porque si la lía vuelves atrás en cinco segundos y no has perdido nada.

Con esa red puesta, el cálculo cambia entero. Ya no necesitas aprobar cada movimiento porque deshacer es barato. Y cuando deshacer es barato, la velocidad gana casi siempre.

Yo hago las dos cosas: guardo el estado antes de empezar cualquier tanda de trabajo, y reservo el modo plan para lo que no se puede deshacer fácil. Borrar registros de una base de datos, tocar algo que ya está publicado, cambios en cosas que otra gente está usando. Eso siempre con plan, aunque tenga la red.

Cómo pedir mejores planes

Un plan malo casi siempre viene de una petición mala. Tres cosas que me funcionan.

Dile lo que no debe tocar. "Haz esto pero no toques la carpeta de estilos". Esa frase sola elimina la mitad de los sustos.

Pídele alternativas en vez de un plan único. "Dame dos formas de hacer esto y dime cuál recomiendas y por qué". Un plan te dice qué va a hacer. Dos planes te enseñan qué opciones había, que es información distinta y más útil.

Y pídele que te diga qué se puede romper. "Antes del plan, dime qué partes del proyecto podrían verse afectadas por este cambio". Es la pregunta que más veces me ha hecho cambiar de idea.

Y ahora qué

Si estás empezando y todo esto te suena a chino, no te agobies: el modo plan es una función de segundo nivel y se aprende sobre la marcha. Lo básico para arrancar lo tengo recogido en Claude Code para no programadores, y el recorrido de un proyecto entero desde cero está en tu primer proyecto web con Claude Code.

Y si ya lo usas, prueba esta semana a hacer el ejercicio al revés: en vez de preguntarte cuándo activarlo, apunta cada vez que lo activas y luego revisa cuántas de esas veces te sirvió de algo. A mí me salió que la mitad eran ritual. Desde que las quité, avanzo más rápido y no he roto nada.

Todo esto lo enseño aplicado a un proyecto real, desde la instalación hasta tener tu web publicada, sin dar por hecho que sabes programar.

Crea tu web con Claude Code