Modo Plan de Claude Code: revisa el enfoque antes de editar

El momento decisivo llega antes de aprobar: descubres un componente que llama al código y que faltaba considerar, mantienes un contrato existente o descartas un cambio innecesario en la base de datos. Un plan detallado justifica el esfuerzo cuando sirve para cambiar una decisión.

¿Qué permite hacer el modo Plan de Claude Code?

El modo Plan le pide a Claude que examine el código del proyecto y proponga cambios. Puede leer archivos, ejecutar comandos para investigar y redactar el plan. En condiciones normales, los cambios en el código fuente permanecen bloqueados hasta que los apruebas. Es como revisar los planos de una reforma antes de que empiecen a mover paredes. Flujo de planificación de Anthropic.

La documentación recoge una excepción importante: en una sesión de terminal interactiva que tenga disponible la omisión de permisos, los bloqueos del modo Plan no se aplican. Claude sigue teniendo instrucciones de planificar, pero un intento de edición puede ejecutarse. Esto también ocurre al habilitar esa posibilidad con --allow-dangerously-skip-permissions, aunque no se haya seleccionado como modo activo. Si quieres que los cambios en el código requieran aprobación, inicia la sesión sin habilitar la omisión de permisos. Reglas de Anthropic para los modos de permisos.

La planificación y el sistema de permisos se complementan. El plan describe lo que Claude pretende cambiar; el modo de permisos determina qué acciones puede realizar sin preguntarte.

Cómo entrar y salir del modo Plan

Para iniciar directamente en modo Plan desde la terminal:

claude --permission-mode plan

Si la sesión ya está abierta, usa los controles de la tabla. Fíjate en el indicador de modo en lugar de contar un número fijo de pulsaciones.

Desde auto, el ciclo pasa a default (Manual), después a acceptEdits y luego a plan. A continuación aparecen los modos opcionales disponibles: primero la omisión de permisos y, al final, auto. En Windows, Anthropic documenta Alt+M como alternativa cuando el entorno de ejecución de Node o Bun no habilita el modo de entrada VT. Cambio de modo, referencia del teclado, referencia de comandos.

Cuando Claude presenta un plan, el diálogo de aprobación permite:

• Elegir No, keep planning («No, seguir planificando») y dar correcciones concretas.
• Elegir Yes, manually approve edits («Sí, aprobar los cambios manualmente») para aprobar el enfoque y revisar cada cambio por separado.
• Elegir Yes, and use auto mode («Sí, y usar el modo auto») para aprobar y continuar en modo auto, cuando esté disponible.

Si el modo auto no está disponible, la opción automática pasa a aceptar los cambios automáticamente. Si la sesión se inició con la omisión de permisos habilitada, esa opción activa dicho modo. Lee qué modo ofrece antes de elegirla. La aprobación cierra el modo Plan e inicia la implementación con los permisos seleccionados. Cambiar de modo con Shift+Tab también permite salir de la planificación, pero no aprueba el plan propuesto. Cómo funciona la aprobación de planes.

¿Usas una interfaz de editor? En VS Code, haz clic en el indicador de modo situado debajo del cuadro de entrada y selecciona Plan. En la pestaña Code de Desktop, utiliza el selector de modo junto a Send. JetBrains usa los controles de la CLI dentro de su terminal. El registro de cambios también indica que VS Code admite escribir /plan desde la versión v2.1.280. Controles de las interfaces, registro oficial de cambios.

Ajustes que conviene conocer

Para que las sesiones de terminal de un proyecto se inicien en modo Plan, incorpora esta configuración a .claude/settings.json:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Si quieres establecerlo como predeterminado para las sesiones de terminal de tu usuario, usa ~/.claude/settings.json. El parámetro de inicio tiene prioridad sobre los ajustes, y la configuración del proyecto o la administrada pueden prevalecer sobre la de tu usuario. VS Code tiene su propio ajuste de inicio: establece "claudeCode.initialPermissionMode": "plan" en la configuración de usuario de VS Code. La extensión no consulta los ajustes del proyecto para determinar el modo de permisos inicial. Configuración del modo de inicio.

Estas claves adicionales van en el nivel superior de la configuración de Claude Code, fuera de permissions:

Son decisiones independientes: dónde guardar el plan, cómo revisar los comandos durante la planificación y si una opción de aprobación borra la conversación. Referencia de configuración, almacenamiento de planes, opción para borrar el contexto.

Si decides borrar el contexto, incluye en el propio plan las restricciones, las decisiones pendientes y los criterios de aceptación. De lo contrario, dependerás de una conversación que ya no estará disponible durante la implementación.

Cómo se complementan el modo Plan y el modo auto

El modo Plan reserva la decisión de implementar para que puedas revisarla. El modo auto reduce las solicitudes rutinarias de permisos mediante un modelo clasificador independiente que evalúa las acciones. El clasificador comprueba los aspectos de permisos de una acción; al revisar el plan, tú compruebas si el diseño propuesto resuelve el problema adecuado.

Cuando el modo auto está disponible y useAutoModeDuringPlan sigue habilitado, ese clasificador también revisa los comandos de shell durante la planificación. Los aprobados se ejecutan; los rechazados se bloquean. Si auto no está disponible o ese ajuste está desactivado, los comandos ajenos al conjunto integrado de solo lectura piden confirmación. La eliminación de rutas críticas tiene un tratamiento aparte, y la excepción de omisión de permisos en la terminal interactiva prevalece. Planificar no significa que todos los comandos de shell sean de solo lectura. Comandos durante la planificación.

Durante la implementación, default implica revisión manual; acceptEdits permite automáticamente los cambios dentro del alcance y los comandos habituales del sistema de archivos, con las excepciones documentadas; y auto añade una revisión de acciones en segundo plano. Ninguno determina si la arquitectura es acertada. Nuestra guía del modo auto de Claude Code explica con más detalle esa elección de permisos.

La documentación actual señala auto como modo de inicio integrado para las sesiones de terminal interactiva y VS Code desde v2.1.283, sujeto a las reglas de configuración, organización y disponibilidad. Por eso sigue siendo relevante configurar explícitamente el inicio en modo Plan. Reglas actuales del modo de inicio.

Las instrucciones antiguas pueden omitir cambios importantes. El registro de Anthropic sitúa la incorporación del argumento de descripción de /plan en v2.1.72, la ocultación predeterminada de la opción para borrar el contexto en v2.1.81 y la evaluación por el clasificador de los comandos Bash cuyo carácter de solo lectura es incierto, durante la planificación con auto, en v2.1.218. Registro oficial de cambios.

Ejemplo práctico: compartir la lógica de precios sin alterar los cobros

Considera esta refactorización: una aplicación calcula los precios de compra en su API y los de renovación en un proceso de trabajo en segundo plano. Quieres compartir las reglas de precios sin modificar el comportamiento de redondeo y descuentos que utiliza cada componente que las invoca. Este plan sirve como ejemplo; no describe un repositorio probado ni garantiza una respuesta concreta de Claude.

Entra en modo Plan y expresa la restricción real:

Supongamos que estos son los archivos relevantes del proyecto:

Un primer borrador razonable podría proponer extraer una función de cálculo común, adaptar ambos componentes que la invocan, eliminar las funciones auxiliares antiguas y actualizar las pruebas. Suena ordenado, pero está incompleto: ¿qué pasa si el cálculo de compra redondea en un punto distinto al de renovación?

Edita el plan antes de aceptarlo. Pulsa Ctrl+G durante la revisión y sustituye la eliminación anticipada por esta corrección:

Guarda el plan y vuelve a la sesión. Si la propuesta aún necesita ajustes, elige la opción de seguir planificando y pide a Claude que revise todo el plan para que sea coherente con esa corrección. El objetivo es eliminar el paso contradictorio de borrado, no añadirle una advertencia debajo. Tanto la edición directa como la continuación de la planificación forman parte del flujo documentado. Recomendaciones de Anthropic para explorar, planificar y programar.

El plan revisado debería ofrecer ahora una secuencia que se pueda implementar:

1. Registrar el comportamiento existente. Añadir casos para los importes actuales de compra y renovación, incluidos los límites de redondeo, los descuentos y las entradas no válidas. Resolver cualquier resultado esperado que aún se desconozca antes de continuar.
2. Introducir la política compartida detrás de adaptadores. Conservar las entradas, las salidas y el comportamiento ante errores de cada función existente. Expresar explícitamente las diferencias entre los componentes que las invocan.
3. Migrar los componentes que hacen las llamadas por separado. Actualizar la compra, verificarla y después actualizar la renovación. Dejar la limpieza de código no relacionada fuera de estos cambios.
4. Verificar el resultado. Ejecutar las comprobaciones reales del proyecto para precios, API y proceso de trabajo, seguidas de las comprobaciones habituales de tipos e integración. Revisar el diff para detectar cambios en las respuestas públicas o en la lógica de los cobros.
5. Conservar una vía para revertir el cambio. Mantener la capa de compatibilidad hasta que la verificación termine correctamente. Eliminar el código obsoleto en un paso separado que se pueda revisar.

Para este ejemplo, aprueba después con revisión manual de los cambios. Tras la implementación, contrasta los cambios reales y los resultados de las pruebas con el plan. Que un plan mencione pruebas no lo convierte en algo más que una propuesta hasta que esas comprobaciones se ejecuten.

Aquí el beneficio económico es concreto: detectar un cambio de comportamiento antes de reescribir ambos componentes y sus pruebas. No hace falta atribuirle un porcentaje especulativo de ahorro de tokens.

Cuándo compensa más planificar primero

Da prioridad a los trabajos en los que un error de diseño inicial pueda extenderse. Por orden de valor probable, estas son las situaciones que yo pasaría primero por planificación:

Son propuestas de trabajo, no resultados medidos. Siguen la recomendación de Anthropic de planificar cuando el enfoque no está claro, el cambio abarca varios archivos o el código resulta desconocido. Para una errata, una instrucción de registro conocida o un cambio de nombre con alcance claro, pide el cambio directamente. Cuándo recomienda Anthropic planificar.

Para presupuestar, compara ambos flujos. La ejecución directa consume tiempo de implementación y revisión antes de que descubras que el enfoque era incorrecto. Planificar añade tiempo de investigación y revisión al principio, con la posibilidad de evitar ese trabajo que habría que rehacer.

Planificar compensa cuando el costo del tiempo dedicado, sumado al uso adicional del modelo, es menor que el costo esperado del trabajo que evita rehacer. Es una regla para decidir, no una medición de ahorro de Anthropic. Usa tus propios costos de ingeniería y el consumo real. Si el plan solo va a repetir un cambio que ya puedes especificar con precisión, prescinde de él.

¿Qué producto vale la pena crear a partir de esto?

La oportunidad más sólida es un paquete de revisión de refactorizaciones para equipos: convertir un cambio propuesto en un mapa de archivos, contratos que deben conservarse, comprobaciones de aceptación y notas de reversión listos para revisar. Un responsable de ingeniería podría pagar por mantener criterios uniformes entre desarrolladores, especialmente cuando se modifica lógica de negocio compartida.

Las estimaciones de palabras clave de DataForSEO para Estados Unidos, consultadas el 12 de octubre de 2026, sitúan «code refactoring tools» en 170 búsquedas al mes. Es una señal modesta de interés por la tarea, no una prueba de que quienes buscan eso vayan a comprar un producto de revisión de planes. La versión mínima útil podría recibir un plan exportado y un mapa de archivos del repositorio, comprobar si faltan componentes que hacen llamadas o hay supuestos sin justificar y generar un documento para una solicitud de cambios. La dificultad: Claude Code ya incluye la generación de planes genéricos. El producto necesita comprobaciones propias de cada equipo y un documento de revisión útil para justificar su lugar.

Una oportunidad más acotada es un paquete de evaluación previa de migraciones para agencias: elaborar un inventario de componentes afectados, una lista de comprobación para el despliegue por etapas y una lista de decisiones pendientes antes de cotizar una actualización. La misma consulta a DataForSEO estima 20 búsquedas mensuales en Estados Unidos de «code migration tools». El escaso volumen de esa consulta comercial invita a validar la idea con clientes actuales antes de desarrollar un producto más amplio.

Su versión mínima podría centrarse en una familia de migraciones y exigir enlaces a la documentación aplicable del proveedor junto a cada cambio. El problema es el mantenimiento: las reglas de migración de cada versión envejecen rápido. El modo Plan puede ayudar a investigar, pero no aporta un manual verificado de reglas de migración. Son hipótesis de producto basadas en demanda de búsqueda, no previsiones de ingresos.

Ultraplan ya no está disponible

Anthropic ha retirado la versión preliminar de investigación de Ultraplan, incluidos /ultraplan, su activación mediante una palabra clave y la opción de aprobación que permitía perfeccionar el plan con Ultraplan en la web. Su página explica que estas versiones preliminares son experimentales y pueden cambiar o retirarse según los comentarios recibidos. Para los flujos de planificación, remite al modo Plan local y a las sesiones de Claude Code en la nube. Página actual de Ultraplan en Anthropic.

Dudas antes de la próxima sesión

El lunes, toma la próxima refactorización con componentes que invoquen lógica compartida, entra en modo Plan y pide que se especifiquen el comportamiento que debe conservarse, los archivos afectados, la verificación y la reversión. Corrige el supuesto más débil antes de aprobar. Complementa el ejercicio con los hábitos de revisión de Buenas prácticas de Claude Code.

Si tu equipo necesita un proceso repetible de planificación y revisión, podemos integrarlo en tu proceso de desarrollo.