⏱️ Lectura: 12 min

Un desarrollador construyó una aplicación entera alrededor del plan mode, la cerró meses después y ahora sostiene que esa función, tal como la conocemos, ya murió.

📑 En este artículo
  1. TL;DR
  2. Qué pasó
  3. Contexto e historia: por qué alguien construiría una app entera para planificar
  4. Detalles técnicos del plan mode: dos funciones, una abstracción rota
  5. Cómo probarlo hoy
  6. Impacto y análisis para equipos en LATAM
  7. Qué sigue
  8. Preguntas frecuentes
    1. ¿Qué es el plan mode en herramientas como Claude Code?
    2. ¿Por qué Ayman Nadeem dice que fracasó su app Nuanced?
    3. ¿El plan mode ya no sirve para nada en septiembre de 2026?
    4. ¿Qué diferencia hay entre planificar y un plan, según este argumento?
    5. ¿Qué es AGENTS.md y por qué aparece en este debate?
    6. ¿Cómo aplico esto hoy si corro varios agentes en paralelo?
  9. Referencias

El 24 de septiembre de 2026, Ayman Nadeem, fundador de la app de código Nuanced, publicó el ensayo “Plan mode is dead”. Ahí explica por qué construir un producto entero sobre el plan mode fue un error, y qué necesitan de verdad los equipos que programan con agentes de IA en paralelo.

TL;DR

  • Ayman Nadeem, fundador de la app de código Nuanced, publicó el 24 de septiembre de 2026 el ensayo “Plan mode is dead”.
  • Nuanced apostó todo su producto al plan mode: convertir cada plan en un documento persistente antes de escribir código.
  • Según Nadeem, el plan mode cumplía dos funciones históricas: dar instrucciones precisas al agente y ayudar al humano a entender el sistema.
  • La primera función se vuelve obsoleta a medida que los modelos mejoran solos; la segunda importa más, pero el plan mode es la abstracción equivocada.
  • Nadeem cita 4 causas del fracaso: confundir plan con planificar, mejores modelos, rechazo a texto de IA y una separación disruptiva de tareas.
  • Antes de Nuanced, Nadeem probó Claude Code CLI, Conductor y Codex como herramientas de planificación.
  • El problema se agrava con varios agentes en paralelo: sin trazabilidad, nadie entiende qué decisión tomó cada uno.

Qué pasó

Nadeem lanzó Nuanced con una apuesta concreta: cada conversación con un agente de código debía convertirse en un documento persistente de planificación antes de tocar una sola línea de código. La idea nació de una fricción real. Cuando trabajaba con Claude Code CLI, Conductor y luego Codex, terminaba copiando fragmentos de un plan de un chat a otro para revisarlo, un flujo que describe como incómodo y difícil de sostener mientras maduraba una idea.

Meses después, Nadeem concluyó que el producto no resolvió el problema que buscaba resolver. En su ensayo lista un motivo central: confundió planificar (el proceso de pensar) con un plan (el artefacto de texto resultante). Preservar ese artefacto en un documento grande no capturó el valor real, que estaba en el proceso de pensar en voz alta junto al agente.

Nuanced buscaba convertir cada plan en un documento persistente, no en un chat efímero. Foto de Volodymyr Hryshchenko en Unsplash

Contexto e historia: por qué alguien construiría una app entera para planificar

La motivación de fondo, según cuenta Nadeem, era una pregunta que sigue vigente: ¿cómo mantiene un humano un modelo mental coherente de un sistema de software mientras una máquina lo cambia más rápido de lo que ese humano puede inspeccionar los cambios? Los modelos actuales pueden escribir miles de líneas en minutos, lo que significa heredar una carga de mantenimiento enorme antes de terminar de pensar qué se estaba construyendo o por qué.

Nadeem describe ese proceso como generador de una recompensa inmediata (ver código funcionando rápido) que a la vez ocultaba el trabajo incómodo de decidir si algo importaba de verdad, o de evaluar con rigor decisiones de producto, diseño e infraestructura. Cuando la arquitectura quedaba subespecificada, el agente rellenaba los huecos a su manera, y esas decisiones se propagaban por varios archivos, muy por debajo de lo que se veía en el chat.

💭 Clave: Nadeem dice que correr varios agentes en paralelo, algo que herramientas como Conductor y Codex ya permitían, lo dejaba con una sensación de desconexión: podía generar código a mayor velocidad de la que podía verificarlo.

Esa fue la falla que Nuanced intentó resolver: no había un rastro claro entre el prompt del usuario, la decisión del agente, el código resultante y el comportamiento final del producto. Nadeem no quería volver a leer archivo por archivo; quería razonar en lenguaje natural sin perder el control de cómo funcionaba el sistema.

Detalles técnicos del plan mode: dos funciones, una abstracción rota

El argumento técnico central del ensayo separa dos funciones que el plan mode cumplió históricamente en herramientas de código con IA. La primera es operativa: darle al agente instrucciones lo bastante precisas para ejecutar bien una tarea. La segunda es humana: ayudar a la persona a entender qué se está construyendo antes de que exista.

Nadeem sostiene que la primera función pierde relevancia rápido a medida que los modelos mejoran solos, porque necesitan cada vez menos andamiaje explícito para interpretar una intención ambigua. La segunda función, en cambio, importa más que nunca, sobre todo cuando un developer corre varios agentes en paralelo y necesita saber qué decidió cada uno. El problema es que el plan mode, como artefacto de texto encerrado en una conversación de chat, es la abstracción equivocada para resolver ese segundo problema.

La siguiente tabla resume los enfoques que hoy compiten para resolver el mismo problema: mantener a un humano al tanto de lo que un agente está construyendo.

EnfoqueDónde vive el planQué resuelve bienLimitación principal
Plan mode nativo (ej. Claude Code)Dentro de la sesión de chat, efímeroFrena al agente antes de escribir código mal alineado con la intenciónSe pierde en el historial del chat cuando la conversación avanza
Documento persistente (CLAUDE.md, AGENTS.md, PLAN.md)Un archivo versionado dentro del repositorioDa contexto estable entre sesiones y entre agentes que corren en paraleloAlguien tiene que mantenerlo actualizado a mano
Revisión de diffs después del hechoDespués de que el agente ya escribió códigoRápido cuando el cambio es chico y acotadoNo sirve si el agente ya tomó decenas de decisiones de diseño ocultas
Cortar y pegar entre chats (el flujo que describe Nadeem antes de Nuanced)Fragmentos de texto que el humano mueve a manoNo requiere ninguna herramienta especialLento, y se pierde la versión anterior del plan en cada copia

El siguiente diagrama ilustra por qué un plan efímero dentro del chat se pierde, mientras que un documento persistente sí puede alimentar a varios agentes a la vez:

flowchart TD
A["Intencion del developer"] --> B["Conversacion con el agente"]
B --> C["Plan dentro del chat"]
C --> D["Se pierde en el historial"]
B --> E["Documento persistente (PLAN.md)"]
E --> F["Agente 1 implementa"]
E --> G["Agente 2 revisa"]
E --> H["Agente 3 corre tests"]
El plan mode nativo vive dentro del chat; un archivo versionado sobrevive a la sesión. Foto de Jakub Żerdzicki en Unsplash

Cómo probarlo hoy

El plan mode de Claude Code sigue disponible y sirve como punto de partida concreto, incluso si el argumento de Nadeem es que no alcanza por sí solo. Para instalarlo:

# macOS / Linux
curl -fsSL https://claude.ai/install.sh | bash

# Windows (PowerShell)
irm https://claude.ai/install.ps1 | iex

# alternativa multiplataforma via npm
npm install -g @anthropic-ai/claude-code

Dentro de una sesión, alternar a modo planificación deja a Claude Code investigar el repositorio sin escribir código todavía, y solo pasa a implementar cuando el plan queda aprobado:

$ claude
> (Shift+Tab dos veces activa el plan mode)
⏸ plan mode on
> Migra el checkout de programacion-store de Stripe Checkout a Stripe Elements

La recomendación que se desprende del ensayo de Nadeem es no dejar ese plan atrapado en el chat. Conviene volcarlo en un archivo versionado del repositorio para que sobreviva a la sesión y esté disponible para el próximo agente:

## Objetivo
Migrar el checkout de programacion-store de Stripe Checkout a Stripe Elements

## Decisiones tomadas
- [2026-09-20] Usamos Payment Element en vez de Card Element: soporta wallets locales sin codigo extra
- [2026-09-22] El webhook de confirmacion vive en /api/webhooks/stripe, separado del handler que crea el pago

## Pendiente de decidir
- Que hacemos con los pagos en efectivo (OXXO, PagoEfectivo) que hoy dependen de Checkout

Para confirmar que un agente está leyendo ese documento y no solo el prompt suelto, basta con pedirle explícitamente que cite una línea del archivo antes de tocar código; si no puede citarla, el archivo no está en su contexto.

💡 Tip: Nombrá el archivo de plan con la fecha o el número de ticket (por ejemplo PLAN-2026-09-checkout.md) para que sobreviva a varias iteraciones sin que un agente lo sobrescriba por error.

Impacto y análisis para equipos en LATAM

Para equipos que ya integraron agentes de código al flujo diario, el argumento de Nadeem tiene una consecuencia práctica: dejar de medir la calidad de un flujo de trabajo por lo elaborado que sea el plan mode de una herramienta, y empezar a medirla por qué tan fácil es reconstruir después por qué se tomó una decisión. Eso importa más en equipos distribuidos de LATAM que coordinan trabajo asíncrono entre husos horarios, donde nadie puede simplemente preguntarle al compañero qué decidió el agente a las 3 de la mañana.

También cambia qué se prioriza al elegir herramientas. Un plan mode vistoso dentro de un chat no sirve de nada si desaparece apenas se cierra la sesión; un archivo simple como CLAUDE.md o AGENTS.md, versionado junto al código y leído por cualquier agente que entre al repositorio, resuelve más del problema real con menos infraestructura.

El costo de no resolverlo bien es real: Nadeem describe explícitamente la sensación de generar código más rápido de lo que podía verificarlo, y de perder la capacidad de detectar cuándo un supuesto incorrecto ya se había convertido en código antes de que alguien lo notara.

Qué sigue

Nadeem no propone volver a revisar línea por línea. Su conclusión apunta a herramientas que traten el plan como un documento vivo dentro del flujo normal de trabajo, no un modo aparte que se activa y desactiva, y que ese documento quede disponible para cualquier cantidad de agentes que trabajen en paralelo sobre el mismo repositorio. La tendencia más amplia en la industria de desarrollo asistido por IA va en esa dirección: mover el contexto de la conversación efímera hacia artefactos versionados que cualquier agente, humano o no, pueda leer sin depender de un historial de chat.

📖 Resumen en Telegram: Ver resumen

Probalo vos: instalá Claude Code con el comando de arriba, activá el plan mode con Shift+Tab y compará cuánto de ese plan sobrevive si lo dejás solo en el chat contra si lo volcás en un archivo del repositorio.

Preguntas frecuentes

¿Qué es el plan mode en herramientas como Claude Code?

Es un modo de trabajo en el que el agente investiga el código y propone un plan de cambios antes de escribir una sola línea, y espera aprobación explícita del developer para pasar a implementar.

¿Por qué Ayman Nadeem dice que fracasó su app Nuanced?

Porque confundió planificar, el proceso de pensar junto al agente, con un plan, el documento resultante, y preservar ese documento no capturó el valor real que buscaban los usuarios.

¿El plan mode ya no sirve para nada en septiembre de 2026?

Sigue siendo útil para frenar a un agente antes de que escriba código mal alineado con la intención del developer, pero según Nadeem no resuelve por sí solo el problema de mantener un entendimiento humano del sistema a través del tiempo y de varios agentes.

¿Qué diferencia hay entre planificar y un plan, según este argumento?

Planificar es el proceso de pensar en voz alta con el agente para llegar a decisiones; un plan es apenas el texto que queda después de ese proceso. Nadeem sostiene que Nuanced optimizó el artefacto y no el proceso.

¿Qué es AGENTS.md y por qué aparece en este debate?

Es un archivo de convenciones e instrucciones persistentes para agentes de código, alternativo o complementario a CLAUDE.md, que varias herramientas ya leen automáticamente al abrir un repositorio.

¿Cómo aplico esto hoy si corro varios agentes en paralelo?

Convertí el plan de cada tarea en un archivo Markdown versionado dentro del repo antes de lanzar el segundo agente, y pedile a cada agente que cite una línea de ese archivo antes de empezar a escribir código.

Referencias

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Juanjo Jaramillo en Unsplash


Andrés Morales

Desarrollador e investigador en inteligencia artificial. Escribe sobre modelos de lenguaje, frameworks, herramientas para devs y lanzamientos open source. Cubre papers de ML, ecosistema de startups tech y tendencias de programación.

0 Comentarios

Deja un comentario

Marcador de posición del avatar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.