El modo plan es pedirle a un agente de IA que primero proponga qué va a cambiar, dónde y cómo lo va a probar, sin editar nada todavía. Tú revisas el plan, lo corriges y solo después lo dejas actuar. Algunas herramientas lo traen como un modo aparte; en otras basta con pedirlo.
Una pregunta de la app. Elige una respuesta.
¿En cuál de estas tareas pedir un plan antes sobra?
Toca dinero y varias partes de la app. Ahí un plan te deja frenar errores antes de que cuesten.
Es chico y se revisa de un vistazo en el resultado. Planearlo cuesta más que hacerlo.
Muchos archivos y riesgo alto: si sale mal, nadie entra. Justo donde conviene ver el plan primero.
Un plan útil se puede revisar: dice qué pasos va a dar, qué archivos toca y cómo va a comprobar que quedó bien. Imagina que le pides a un agente de código agregar envío gratis a partir de cierto monto en una tienda online. Un buen plan nombra el cálculo del carrito, la pantalla de pago y los tests que va a correr.
Después lo comparas con dos cosas. Con las reglas del proyecto, las que dejaste por ejemplo en CLAUDE.md: si el plan suma una librería de fechas y el proyecto ya usa otra, se lo dices. Y con lo que falta: si no dice nada de los pedidos que ya se cobraron, pregunta si los toca. Señales de alerta: pasos como «ajusto lo que haga falta», archivos que no tienen que ver con el pedido o ningún paso para probar.
En las herramientas que lo traen como modo, el agente suele poder leer el proyecto pero no editarlo hasta que apruebas. Si la tuya no lo tiene, una frase alcanza: «Antes de editar, dime qué archivos vas a cambiar, en qué orden y cómo lo vas a probar. No toques nada hasta que te diga.»
Diferencia importante: un modo de la herramienta puede bloquear la edición; un pedido en el chat solo guía al agente, que puede saltárselo. Si el cambio es delicado, prefiere el modo o los permisos que te pidan aprobación antes de editar.
Sirve cuando el cambio toca varias partes, dinero, el acceso de los usuarios o sus datos: ahí corregir el plan cuesta una frase y deshacer cambios cuesta horas. Sobra cuando el cambio es chico y se revisa de un vistazo en el resultado, como renombrar una variable dentro de un solo archivo. Regla práctica: si leer el plan te lleva más que revisar el cambio, sáltalo.
Error común: «aprobé el plan, ya está». El plan dice lo que piensa hacer, no lo que hizo. Un buen plan puede ejecutarse mal, así que al final igual revisas el diff y los tests.