Modo plan: que la IA proponga antes de actuar
El modo plan obliga a un agente de IA a investigar y proponer antes de editar. Cómo se activa en Claude Code, Codex y Cursor y cómo se aprueba el plan.
¿Qué hace un agente en modo plan?
El agente explora el problema: lee los archivos relevantes, consulta el estado del proyecto y escribe un plan con los pasos que propone. Es una fase del loop de un agente, la de pensar antes de actuar, separada de forma explícita de la de actuar. Cuando el plan está listo, lo presenta y pregunta cómo seguir.
La documentación de Claude Code lo resume así: el modo plan deja que Claude lea archivos y ejecute comandos de shell para investigar, y luego escriba un plan sin editar tu código fuente. Las ediciones quedan bloqueadas hasta que apruebas el plan. Esa frontera, leer y proponer frente a editar, es lo que da al modo su utilidad.
¿Cómo se activa en cada herramienta?
Los tres casos siguientes están tomados de la documentación oficial de cada producto, consultada en octubre de 2026.
| Herramienta | Cómo se entra | Qué produce |
|---|---|---|
| Claude Code | Shift+Tab hasta que la barra de estado muestre ⏸ plan mode on; /plan antes de un prompt; claude --permission-mode plan; o permissions.defaultMode: "plan" en .claude/settings.json | Un plan que se aprueba para pasar a editar |
| Codex | /plan (con texto opcional en la misma línea) o Shift+Tab | Un plan antes de implementar; la guía de buenas prácticas dice que Codex reúne contexto y hace preguntas aclaratorias |
| Cursor | Shift+Tab en el campo del agente | Un archivo Markdown con rutas de archivos y referencias a código, que se puede editar |
Detalles que conviene conocer. En Claude Code, Shift+Tab recorre los modos default, acceptEdits y plan (y, si están disponibles, bypassPermissions y auto); para salir del modo plan sin aprobar nada, se vuelve a pulsar Shift+Tab. En Codex, /plan no está disponible mientras el agente ya está trabajando. En Cursor, el agente investiga el código, revisa documentación y hace preguntas aclaratorias antes de redactar el plan, y los planes se guardan por defecto en el directorio personal; el botón “Save to workspace” los mueve al proyecto.
¿Por qué separar planear de ejecutar?
Porque un error de dirección es más caro que un error de detalle. Si el agente decide reescribir un módulo entero cuando bastaba un cambio de configuración, cada paso posterior profundiza el error, y la persona lo descubre cuando ya hay muchos archivos tocados.
El modo plan obliga a que la decisión sobre el camino se tome a la vista. La persona lee el plan, corrige lo que no le gusta y recién entonces el agente toca el código. Es una aprobación de estrategia, no de cada línea, y una forma anticipada de control humano. También reduce la necesidad de frenar a mitad de camino, que es lo que describe interrumpir y redirigir a un agente. Revisar un plan de cinco pasos toma minutos; revisar el resultado de cuarenta cambios toma mucho más, y deshacerlos más todavía.
¿Cómo se aprueba un plan?
El diseño de la aprobación importa tanto como el modo. En Claude Code, cuando el plan está listo, el agente lo presenta y ofrece tres opciones:
- “Yes, and use auto mode”. Aprueba e inicia el modo automático. Si ese modo no está disponible en la sesión, la opción dice “Yes, auto-accept edits”.
- “Yes, manually approve edits”. Aprueba, y la persona revisa cada edición.
- “No, keep planning”. Se queda en modo plan para decirle al agente qué cambiar.
Además, Ctrl+G abre el plan en el editor de texto para modificarlo antes de que el agente continúe. En Cursor, el plan también se edita a mano, incluidas sus tareas pendientes, y se construye con un clic cuando está listo.
Esas opciones muestran un patrón de diseño útil: aprobar tal cual, aprobar eligiendo cuánta supervisión tendrá la ejecución, pedir cambios sin ejecutar nada y editar el plan directamente. La opción que más se olvida y más ahorra es la tercera: corregir antes de que haya archivos tocados. Un detalle importante: aprobar el plan sale del modo plan y cambia a un modo de edición, así que el agente empieza a editar justo después. La pantalla debe decir con claridad qué sigue y cuánta revisión tendrán los cambios. Para el patrón general de pedir permiso, mira aprobación de acciones y UX de permisos para agentes.
¿Qué queda bloqueado y qué se puede ejecutar mientras se planea?
En Claude Code, lo permitido es leer archivos y ejecutar comandos de shell para explorar; lo bloqueado es editar el código fuente. Los comandos de terminal tienen reglas propias. Según la documentación, aplica el primer caso que coincida:
- Terminal interactiva con permisos de bypass disponibles: la planeación no se aplica de forma estricta; solo piden confirmación las reglas explícitas de “preguntar” y los borrados de rutas críticas.
- Modo automático disponible y
useAutoModeDuringPlanactivo (el valor por defecto): un clasificador revisa los comandos de shell en lugar de preguntarte; los aprobados corren y los rechazados se bloquean. - Modo automático no disponible, o
useAutoModeDuringPlandesactivado: los comandos fuera del conjunto de solo lectura incorporado piden aprobación.
La lección de diseño: un modo plan que dice “no toca nada” pero deja correr comandos que modifican algo engaña a la persona. En una interfaz propia, declara qué puede hacer el agente en esa fase y pide permiso para todo lo demás. La documentación consultada de Codex y Cursor no detalla qué comandos corren durante la planeación, así que conviene probarlo en tu versión antes de confiar en ello.
Ejemplo
Ejemplo ilustrativo: un equipo quiere cambiar el sistema de temas de su aplicación, repartido hoy en veinte archivos. Antes de tocar nada, activan el modo plan. El agente lee los archivos y propone: “Centralizar los colores en un solo archivo de tokens, migrar cuatro componentes primero y luego el resto. Riesgo: el componente de gráficas usa colores fijos que habría que revisar”.
La diseñadora pide un cambio: “Migra primero el componente de facturas, no el de gráficas, que no tiene pruebas”. Edita el plan, lo aprueba con “Yes, manually approve edits” y revisa cada edición de la primera tanda. El cambio que el equipo temía se hace en dos tandas, con la decisión de fondo tomada al principio y no a mitad de la tarea.
¿Cuándo NO conviene el modo plan?
- Para cambios pequeños y bien conocidos. Corregir una errata o cambiar un color no necesita un plan; el paso de aprobación solo añade fricción.
- Cuando la persona necesita ver el resultado para decidir. En exploraciones visuales a veces sirve más un prototipo rápido que un plan escrito; ahí ayuda previsualizar los cambios.
- Cuando la planeación se vuelve otra tarea. Si el plan tarda más que el trabajo, el modo está mal aplicado.
Errores comunes
- Usar modo plan para todo, incluidas tareas triviales.
- Aprobar planes sin leerlos porque el paso parece un trámite.
- Creer que el modo plan nunca ejecuta nada, cuando algunos comandos sí corren.
- No usar la opción de pedir cambios sin ejecutar.
- Aprobar el plan y perder de vista el cambio de modo que eso produce.