¿Murió el plan mode? Qué cambia al trabajar con agentes de IA

Activas el plan mode, el agente lee 40 archivos y te devuelve un plan de dos pantallas. Lo apruebas sin leerlo bien. Lo ejecuta y hace algo un poco distinto de lo que estaba escrito. Si esta escena te resulta familiar, el texto Plan mode is dead, de Ayman Nadeem, va a tener sentido para ti. La provocación es simple: el plan mode, ese modo en el que el agente solo planifica y no toca nada, puede haberse vuelto más ritual que herramienta.

Estoy de acuerdo con buena parte. No estoy de acuerdo con el certificado de defunción. Te explico por qué.

Qué es el plan mode y por qué existía

Casi toda herramienta de código con IA tiene alguna versión de esto. En Claude Code, en Cursor, en Copilot, en Codex. El agente queda en modo solo lectura: explora el repositorio, hace preguntas y propone un paso a paso. Solo cuando lo apruebas empieza a editar archivos.

La lógica era buena. Los primeros agentes eran caros, lentos y bastante torpes. Una ejecución equivocada podía costar 10 minutos y un montón de tokens. Y encima dejaba el repositorio en un estado que tenías que deshacer a mano. Planificar antes era un cinturón de seguridad. Era más barato equivocarse en el texto que en el código.

El problema es que esa cuenta cambió.

Por qué dicen que el plan mode murió

Resumo la tesis a mi manera: hoy ejecutar es más barato que planificar. Y cuando ejecutar es barato, el plan escrito pierde valor.

Piensa en lo que cambió en poco tiempo:

• Los modelos son mucho más rápidos y más certeros en tareas de alcance medio.
• Las herramientas incorporaron checkpoint y rewind. Si sale mal, vuelves atrás.
• Git worktree se volvió el estándar para correr un agente aislado sin ensuciar tu rama.
• El sandbox en la nube dejó de ser un lujo.

Con esto, el flujo "planificar, aprobar, ejecutar" empieza a parecer burocracia. Un plan en markdown es una promesa. El agente dice "voy a modificar el useAuth, crear un middleware y ajustar tres tests". Lo lees, te parece razonable, lo apruebas. Pero no tienes forma de saber si el plan es correcto hasta ver el código funcionando. El plan no compila.

Un plan es una hipótesis. Un diff es un experimento.

Y hay un efecto secundario que poca gente admite: un plan largo genera aprobaciones perezosas. Nadie lee con atención el quinto punto de un plan de 30 líneas. Lo apruebas por cansancio. En la práctica, el plan mode se convirtió en un botón de "ok, adelante" con pasos extra.

Qué cambia en el flujo de trabajo en la práctica

Si sacas el plan mode del centro, ¿qué ocupa su lugar? En mi día a día, tres cosas: aislamiento, criterio de aceptación y descartar sin piedad.

Primero, aislamiento. En vez de pedir un plan, doy el objetivo y dejo que el agente trabaje en un lugar donde equivocarse no cuesta nada.

git worktree add ../app-intento-1 -b agent/refresh-token
cd ../app-intento-1
# ejecuta el agente aquí, con libertad para editar

Si queda mal, borro la carpeta y listo. Si queda bien, abro un PR. Dos intentos en paralelo cuestan menos que media hora discutiendo un plan.

Segundo, criterio de aceptación. El plan que de verdad importa es el que dice cuándo la tarea está lista. Y eso cabe en un test. Antes de pedir la feature, escribo (o pido que escriban) el contrato:

import { test, expect } from 'bun:test'
import { refreshSession } from './session'

test('renueva el token cuando faltan menos de 5 minutos', async () => {
  const session = { expiresAt: Date.now() + 4 * 60_000, refreshToken: 'abc' }
  const next = await refreshSession(session)
  expect(next.expiresAt).toBeGreaterThan(session.expiresAt)
})

test('no renueva un token todavía válido', async () => {
  const session = { expiresAt: Date.now() + 30 * 60_000, refreshToken: 'abc' }
  const next = await refreshSession(session)
  expect(next).toBe(session)
})

Este test es un plan mejor que cualquier lista en markdown. Es verificable. El agente puede iterar hasta que pase, y yo no necesito fiarme de su palabra.

Tercero, descartar sin piedad. Es lo más difícil para quien viene del flujo antiguo. Cuando el agente se equivoca feo, dan ganas de corregirlo en la conversación: "no, vuelve, hazlo así". Muchas veces es más rápido tirarlo todo y empezar de nuevo con un prompt mejor. El contexto contaminado de un mal intento estorba en el siguiente.

Juntándolo todo, el flujo queda más o menos así:

1. Escribe el objetivo en dos o tres frases.
2. Define el criterio de aceptación, de preferencia en un test.
3. Ejecuta el agente aislado, en una worktree o un sandbox.
4. Revisa el diff, no el plan.
5. Si no sirvió, descártalo y ajusta el prompt.

Fíjate que la revisión humana no desapareció. Solo cambió de lugar. Dejas de revisar intenciones y pasas a revisar resultados.

Dónde el plan mode todavía te salva

Aquí no estoy de acuerdo con el título. Hay situaciones en las que planificar antes sigue siendo la decisión correcta. Ignorarlo es buscarse dolores de cabeza.

Operaciones irreversibles. La migración de base de datos es el ejemplo clásico. Si el agente va a tocar el schema de PostgreSQL con datos de producción, quiero ver el plan antes. Un DROP COLUMN no tiene Ctrl+Z. Una worktree no protege tu base de datos.

-- esto lo quiero leer antes, no después
ALTER TABLE orders DROP COLUMN legacy_status;

Un codebase que no conoces. Cuando entro en un proyecto nuevo, el plan mode funciona más como herramienta de lectura que de planificación. Pedirle al agente que explore y explique cómo funciona el flujo de autenticación, sin tocar nada, es excelente para entender el terreno.

Cambios que atraviesan muchas cosas. Cambiar el gestor de estado de toda una app React Native, migrar de Express a Hono, renombrar un concepto central del dominio. Aquí el plan sirve para alinearse con el equipo, no con el agente. Es un documento de decisión.

Alto costo por ejecución. Si cada ronda del agente tarda 20 minutos porque hay un build nativo o una suite de tests pesada, equivocarse vuelve a ser caro. La cuenta del principio del texto vuelve a valer.

Entonces, para mí, el plan mode no murió. Lo degradaron. Dejó de ser el estándar para toda tarea y se volvió una herramienta para casos específicos. Igual que el debugger: no lo abres para cada bug, pero cuando lo necesitas, lo necesitas de verdad.

¿Vale la pena cambiar tu forma de usar agentes?

Vale la pena probarlo una semana. Un experimento simple: toma las tareas pequeñas y medianas (un bug, un endpoint nuevo, un componente, una refactorización local) y sáltate el plan mode. Ve directo a la ejecución aislada con un criterio de aceptación claro. Anota cuánto tardó cada una y cuántas veces tuviste que descartar.

Apuesto a que vas a notar dos cosas. La primera: muchas de tus aprobaciones de planes eran automáticas. La segunda: el tiempo que pasabas leyendo planes rinde más leyendo diffs.

¿Y si el agente hace una tontería? Perfecto, fue en una carpeta desechable. Mejor eso que hacerla después de que aprobaste un plan bonito. Por lo menos ahora la culpa no es tuya por haber dado el ok.

Mi opinión

El punto más fuerte del texto no tiene que ver con un modo específico de una herramienta. Tiene que ver con dónde está el control. Durante mucho tiempo creímos que controlar al agente era controlar lo que pretende hacer. En la práctica, el control de verdad es tener tests que te dicen si quedó bien y un entorno donde equivocarse sale barato.

Si tu proyecto no tiene eso, ningún plan mode te va a salvar. Si lo tiene, casi no lo necesitas.

Así he estado trabajando en mis proyectos últimamente, y puedes ver algo de ese resultado en los proyectos que publiqué por aquí.

¿Apruebas planes de 30 líneas sin leer el quinto punto? Yo también lo hacía.

Leí "Plan mode is dead", de Ayman Nadeem, y estoy de acuerdo con buena parte. Ejecutar se volvió más barato que planificar.

Un plan es una hipótesis. Un diff es un experimento. Hoy ejecuto el agente en una worktree aislada, defino el criterio de aceptación en un test y reviso el resultado, no la intención.

Pero no firmo el certificado de defunción. Una migración de base de datos, un codebase desconocido y un cambio que atraviesa a todo el equipo todavía piden un plan antes. Un DROP COLUMN no tiene Ctrl+Z.

El plan mode no murió. Lo degradaron. El control de verdad es tener tests que te dicen si quedó bien y un entorno donde equivocarse sale barato.

Escribí en el blog cómo esto cambió mi flujo. ¿Cómo estás usando el plan mode en tu día a día?

#IA #AgentesDeIA #DesarrolloDeSoftware #ClaudeCode #Productividad