¿Murió el plan mode? Qué cambia en tu flujo con agentes

Pulsas Shift+Tab, el agente entra en plan mode y suelta un plan de 14 pasos. Lo lees todo y lo apruebas. En el paso 3 descubre que el archivo que iba a editar ya ni existe. Esa escena es el punto de partida de un texto que circuló bastante en las últimas semanas: Plan mode is dead, de Ayman Nadeem. El título es una provocación, pero la pregunta va en serio: ¿el plan mode todavía vale el tiempo que le dedicas?

Uso agentes de código todos los días, en proyectos React, React Native y backend con Bun. Así que te doy mi lectura, con lo que funciona y lo que no en mi flujo.

Qué es el plan mode y por qué surgió

El plan mode es el modo en que el agente lee el código, piensa y propone un plan, pero no modifica ningún archivo. Claude Code, Cursor y compañía tienen alguna versión de esto. Tú lo revisas, lo ajustas y solo después liberas la ejecución.

Nació de un problema real. En 2024 y a principios de 2025, los modelos se ponían a editar diez archivos a partir de una suposición equivocada. Solo veías el desastre en el git diff. El plan mode era un freno: "antes de tocar nada, cuéntame qué vas a hacer".

Tenía todo el sentido cuando:

• el modelo se equivocaba de arquitectura con frecuencia;
• deshacer un cambio era tedioso y manual;
• cada ejecución era lenta y cara.

Esos tres puntos cambiaron bastante.

Por qué dicen que el plan mode murió

La tesis, resumida según mi lectura: el plan escrito antes del código envejece demasiado rápido. El agente planifica según lo que cree que va a encontrar. Cuando empieza a ejecutar, encuentra otra cosa. El plan se vuelve un documento desactualizado que aprobaste con cuidado y que nadie sigue.

Además, los modelos actuales planifican mientras ejecutan. Leen un archivo, corren un test, corrigen el rumbo. El ciclo "pensar, actuar, observar" se volvió lo bastante corto como para que separar "pensar" en una fase propia parezca burocracia.

Súmale checkpoints, rewind y Git barato, y equivocarse también salió barato. Si el agente se fue por el lado equivocado, vuelves atrás en dos segundos.

Un buen plan es el que sobrevive al primer contacto con el código. La mayoría no sobrevive.

Un ejemplo mío, de la semana pasada. Le pedí a un agente migrar un endpoint de Express a Hono en un servicio con Bun. En plan mode, propuso crear un adaptador de middleware, reescribir la validación y ajustar los tests. Lo aprobé. Al ejecutar, descubrió que la validación ya usaba Zod y que Hono tenía el validador listo. La mitad del plan quedó en la basura. Me habría ahorrado unos 4 minutos de lectura con solo dejarlo empezar.

Dónde el plan mode todavía te salva

Aquí no estoy de acuerdo con el entierro. El plan mode perdió valor como ritual por defecto. No perdió valor como herramienta.

Hay tres situaciones en las que lo sigo usando:

1. Cambios que tocan datos. Una migration de PostgreSQL, un script que actualiza registros en producción, cualquier cosa sin un rewind de verdad. El checkpoint del agente deshace el archivo. No deshace el UPDATE que ya corrió en la base de datos.

-- esto no tiene Ctrl+Z
ALTER TABLE orders DROP COLUMN legacy_status;

Antes de algo así, quiero ver el plan. Y quiero volver a verlo después.

2. Cuando no sé lo que quiero. A veces el plan no es para el agente, es para mí. Pedir un plan es una forma rápida de ver las opciones de arquitectura sin escribir nada de código. Funciona como un borrador de RFC.

3. Un codebase grande que el agente no conoce. En un monorepo con varias apps y libs compartidas, un plan corto evita que cambie una lib usada por cinco proyectos creyendo que solo uno la consume.

Fuera de eso, estoy de acuerdo: el plan mode se volvió un hábito, y un hábito sin motivo es un costo.

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

Si vas a abandonar el plan mode como opción por defecto, tienes que poner algo en su lugar. Si no, solo estás dejando al agente suelto. Esto es lo que me ha funcionado:

Tareas más pequeñas. En lugar de "refactoriza el módulo de pagos", pido "extrae el cálculo del envío a una función pura con test". Una tarea pequeña no necesita plan. El diff ya es el plan.

El test como contrato. Escribo o pido el test primero. El test dice qué tiene que ser verdad al final. El agente puede ir por el camino que quiera, siempre que el test pase.

import { expect, test } from 'bun:test'
import { calcShipping } from './shipping'

test('envío gratis por encima de 200', () => {
  expect(calcShipping({ subtotal: 250, uf: 'SP' })).toBe(0)
})

Esto comunica la intención mejor que cualquier plan en prosa de 14 pasos.

Commits pequeños y frecuentes. Cada paso que funciona se convierte en un commit. Si el agente se pierde, git reset y listo. El historial se vuelve el plan, solo que escrito después, cuando ya es verdad.

Reglas en el archivo de instrucciones del proyecto. Lo que yo revisaba en el plan (no tocar tal carpeta, usar tal patrón de componente, nunca correr una migration por su cuenta) ahora va en el CLAUDE.md o equivalente. Lo escribo una vez y vale para todas las tareas.

Fíjate que nada de esto es nuevo. Son buenas prácticas de ingeniería que ya existían antes de la IA. El agente solo hizo que ignorarlas salga más caro.

Planificar o no: un criterio simple

Si quieres una regla de bolsillo, uso esta pregunta: ¿cuánto cuesta deshacerlo?

• Deshacerlo cuesta un git checkout: deja que el agente ejecute directo.
• Deshacerlo implica tocar la base de datos, la infra, un contrato de API pública o el dinero de alguien: plan mode, y lee el plan con atención.
• Ni siquiera sabes todavía lo que quieres: plan mode como lluvia de ideas, sin compromiso de seguirlo.

En la práctica, un 80% de mis tareas caen en el primer caso. O sea, pasaba la mayor parte del tiempo revisando planes para cambios que costaban cero revertir. Visto ahora, fue mucho tiempo tirado a la basura.

Los riesgos de matar el plan mode demasiado pronto

Vale la pena la objeción honesta. Saltarse el plan tiene dos riesgos reales.

El primero es la revisión perezosa. Si no leíste el plan, vas a tener que leer el diff. Y un diff grande generado por un agente cansa de revisar. La tentación de hacer merge sin mirarlo bien es enorme. Las tareas pequeñas lo resuelven en buena parte, pero exigen disciplina.

El segundo es el costo. Un agente que ejecuta, se equivoca y rehace gasta tokens. En un plan de pago por uso, tres intentos fallidos pueden costar más que un plan bien hecho. No es un argumento decisivo, pero cuenta si eres tú quien paga la factura.

Y hay un tercero, más sutil: el plan mode también era un momento para que tú pensaras. Sin él, es fácil tercerizar todo el razonamiento. Ya vi gente (yo incluido, lo admito) aceptar una solución solo porque el test pasó, sin entender por qué funcionó. Y a las 3 de la mañana eso te pasa factura.

Mi opinión

El plan mode no murió. Lo que murió fue el plan mode como paso obligatorio antes de cualquier tarea. Se convierte en una herramienta de excepción: para cuando equivocarse sale caro, o cuando todavía estás decidiendo qué hacer.

Para todo lo demás, el mejor plan es tarea pequeña, test primero y commits frecuentes. Parece menos sofisticado. En la práctica funciona mejor, porque el plan pasa a ser algo que verificas ejecutándolo, y no una promesa que leíste y aprobaste.

Si quieres ver cómo aparece este flujo en un proyecto real, échale un vistazo a los proyectos en los que he estado trabajando.

Revisé planes de 14 pasos durante meses. El 80% eran para cambios que un git checkout deshacía.

El plan mode no murió, pero dejó de ser un paso obligatorio. El plan escrito antes del código envejece en el primer archivo que abre el agente.

Hoy me hago una sola pregunta: ¿cuánto cuesta deshacerlo?

Si es una migration, la base de datos o el dinero de alguien, quiero ver el plan. Y lo leo dos veces.

Para lo demás, uso tareas pequeñas, test primero y commits frecuentes. El test comunica la intención mejor que cualquier plan en prosa.

Escribí en el blog cómo funciona este flujo en mi día a día. ¿Tú todavía apruebas un plan antes de todo?

#ClaudeCode #AgentesDeIA #IngenieríaDeSoftware #DevProductivo #Bun