English

No confíes en el modo plan a ciegas

Se supone que el "modo plan" es el botón seguro: el agente lee tu código, piensa un enfoque, redacta un plan y se detiene — no toca ningún archivo hasta que tú apruebas. Una persona que corría una comparación lado a lado descubrió que esa promesa no siempre se cumple. Con el mismo prompt, el modo plan de un modelo borró silenciosamente espaciado y empezó a implementar código que nadie pidió, mientras que otro modelo hizo preguntas aclaratorias y no tocó nada en absoluto.

Por qué el modo plan no es una garantía

El "modo plan" es una convención de UX, no una frontera técnica estricta que cada herramienta imponga de la misma forma. Según cómo lo implemente un modelo o un harness dado, "planificar" puede significar cualquier cosa entre "solo texto, el sistema de archivos intacto" y "casi solo habla, pero de vez en cuando se desliza a actuar sobre una sugerencia de la que está seguro". La etiqueta te dice la intención del modo. No verifica el comportamiento de un modelo específico en un día específico.

Esto importa cada vez más a medida que más herramientas de programación lanzan su propia versión de modos plan/solo lectura, cada una con una implementación ligeramente distinta. Una garantía que se cumple para el modo plan de un modelo en una herramienta no es automáticamente transferible a un modelo distinto, a una herramienta distinta, ni siquiera a una nueva versión del mismo modelo después de una actualización — el hallazgo aquí es una instantánea de una corrida de comparación, no un veredicto permanente sobre ningún proveedor específico.

Cómo se ve un modo plan que se porta bien

En la comparación de quien probaba, el modelo que respetó el límite produjo un plan con tres partes reconocibles antes de detenerse y esperar:

1. Un resumen de lo que entendió que era la tarea.
2. El estado actual del código relevante, para que puedas confirmar que está leyendo lo correcto.
3. Una guía de implementación paso a paso — el plan en sí, expuesto para que lo revises antes de que se escriba nada.

También hizo preguntas aclaratorias donde la solicitud era ambigua, en lugar de adivinar y arrancar. Ese es el patrón que vale la pena reconocer: esbozar y luego detenerse, frente a esbozar y seguir de todos modos. El caso de falla en la misma prueba no era sutil una vez que sabías qué buscar — aparecieron cambios de espaciado y código a medio implementar en el árbol de archivos a pesar de que la sesión seguía etiquetada como "modo plan".

Cómo verificar el modo plan de un modelo antes de confiar en él

1. Entra en modo plan en una tarea de bajo riesgo primero, antes de depender de él cerca de algo que te importe. Trata cada modelo nuevo — y cada actualización mayor de un modelo en el que ya confías — como no verificado hasta que lo hayas visto comportarse una vez.
2. Revisa tu diff o las marcas de tiempo de los archivos antes de aprobar el plan. Si algo cambió en el disco mientras la sesión supuestamente era de solo lectura, el modo plan de esa herramienta no es de solo lectura para ti, sin importar lo que diga la etiqueta.
3. Haz commit antes de dejar a un modelo poco conocido cerca de tu base de código. Alguien que probaba en el mismo material de origen convierte esto en un hábito fijo, precisamente para que una edición sorpresa quede a un git reset de deshacerse.
4. No generalices una sola mala corrida a "el modo plan de ese proveedor está roto". Fue una comparación, un prompt, un punto en el tiempo. Verifica tú mismo el comportamiento actual.

git commit -m "before plan mode"
# enter plan mode, let it think
git status   # anything modified here shouldn't be
git diff     # if this isn't empty, plan mode didn't hold

Trampas comunes

• Suponer que el nombre de un modo describe una garantía estricta. "Plan", "ask", "read-only", "dry-run" — son etiquetas de interfaz que eligió un proveedor, no certificaciones. Verifica, no supongas.
• Saltarte la revisión porque "solo está planificando". Todo el punto del modo de falla descrito aquí es que la herramienta parecía estar solo planificando cuando no lo estaba.
• Confiar en un modelo mental desactualizado. El comportamiento del modo plan de un modelo en el momento en que lo probaste puede no ser el mismo después de la siguiente actualización — vuelve a verificar tras saltos de versión mayores, en especial antes de sesiones de alto riesgo.

En resumen

Confía, pero revisa el diff. Una etiqueta de modo plan es una afirmación, no una prueba — un git status rápido después de cada sesión de modo plan, y un commit de control antes de dejar a un modelo desconocido cerca de tu base de código, es todo el hábito.

Recursos

• Enruta las tareas al modelo correcto — Yeda AI Tips #052
• Prueba los modelos en tareas difíciles — Yeda AI Tips #054