Hay una discusión que lleva meses dando vueltas entre quienes usamos agentes de código a diario: para qué sirve el modo plan. Ayman Nadeem, que construyó una app entera alrededor de esa idea, escribió esta semana que la mata: el modo plan como producto separado está muerto, y lo dice alguien que apostó por él. Me llamó la atención porque yo vengo de una trinchera parecida, aunque mi conclusión es distinta y quiero contarla.
El problema real nunca fue el plan
Nadeem separó dos cosas que el modo plan mezclaba: primero, darle instrucciones lo bastante precisas a un agente; segundo, ayudarte a ti a entender qué estás construyendo. La primera mitad se está volviendo obsoleta porque los modelos son buenos explorando un repositorio y llenando los huecos de tu descripción con supuestos razonables. La segunda importa más que nunca, y ahí está el quid: el plan como documento es una abstracción equivocada, pero la necesidad de entender lo que la máquina está haciendo no desaparece nunca.
Su mea culpa tiene una frase que me gustó: confundió planificar con el plan. Planificar es un proceso continuo, algo que pasa mientras construyes; el plan es un artefacto de texto que, cuando lo escribe la IA, da paja leerlo. Especificaciones larguísimas que nadie revisa de verdad son burocracia disfrazada de ingeniería.
Lo que veo yo en la práctica
En mi flujo diario con agentes, lo que funciona no es planear antes y ejecutar después, sino un ciclo: entender, actuar, mirar el resultado, corregir, actuar de nuevo. El plan aparece adentro del ciclo, no en una fase previa. Cuando intento forzar la fase de planificación como documento formal termino con dos problemas: o el documento queda desactualizado a los diez minutos porque el agente descubrió algo que cambia todo, o pierdo tiempo discutiendo detalles que el agente habría resuelto solo.
Pero ojo con tirar el bebé con el agua de la bañera. Cuando un agente corre sin supervisión en un servidor, con acceso a credenciales y servicios en producción, ahí el plan escrito sí salva vidas. No como documento para leer, sino como contrato: qué puede tocar, qué no, y qué se considera éxito. La diferencia entre planificación y plan no es que uno sea bueno y otro malo; es que el plan sirve cuando el que lo ejecuta no está delante tuyo preguntándote en vivo. Para un cron que corre a las 3 de la mañana en tu VPS, el plan es lo único que queda de ti.
El problema que sigue abierto
La parte que nadie ha resuelto es entender el sistema cuando hay decenas de agentes cambiándolo a la vez. Con uno, revisas el diff y listo. Con diez corriendo en paralelo, ya no da el tiempo: los agentes tendrían que decidir dónde vale la pena poner tu atención y traerte el contexto justo. Eso no existe todavía, o existe de forma muy precaria, y mientras tanto cada persona con cinco agentes abiertos está apilando deuda de comprensión: código que funciona pero que nadie entiende de punta a punta.
Mi opinión: el funeral del modo plan está justificado como interfaz, no como disciplina. Los menús que te obligan a decidir si esta tarea merece planificación son carga cognitiva innecesaria; la conversación donde decides qué construir no se puede automatizar y tampoco conviene. Lo que muere es el botón. Lo que se queda es la obligación de saber qué estás haciendo, que es la misma de siempre, solo que ahora con máquinas muy rápidas equivocándose muy rápido contigo.
Fuente de inspiración: Plan mode is dead | Ayman Nadeem
