Cuando escribir código era lento, planificar antes se sentía natural: total, escribir la primera versión ya llevaba su tiempo, así que pensar un poco más no cambiaba mucho el ritmo general. Con un agente que genera cientos de líneas en segundos, la tentación cambia: ¿para qué planificar si puedo simplemente probar y ver qué sale?
He caído en esa tentación varias veces, y el patrón siempre es el mismo: la primera versión sale rápido, y luego me paso el doble de tiempo deshaciendo decisiones que un rato de planificación habría evitado desde el principio.
La velocidad de generación no reduce el coste de una mala decisión
Un agente que escribe rápido no hace que una decisión de arquitectura equivocada sea más barata de deshacer. Al contrario: cuanto más rápido genera código sobre una base mal pensada, más código hay que deshacer cuando el problema aparece. La velocidad multiplica el coste del error, no lo reduce.
Esto es lo que cambia realmente con los agentes: no que planificar sea menos necesario, sino que el coste de no planificar se paga más rápido y en mayor volumen.
Qué significa planificar cuando quien ejecuta es un agente
No es escribir un documento de diseño de veinte páginas antes de tocar una tecla. Es responder, antes de pedirle nada al agente, tres preguntas concretas: qué archivos va a tocar esto, qué debería quedar exactamente igual, y cómo voy a saber que el resultado es correcto sin tener que revisar cada línea a mano.
Con esas tres respuestas ya escritas, el prompt que le doy al agente es mucho más preciso, y el resultado necesita muchas menos rondas de corrección después.
El caso en el que sí tiene sentido improvisar
No toda tarea necesita planificación previa. Cuando el problema es pequeño, acotado a un archivo, y el coste de un error es bajo y reversible en segundos, planificar de más es, ahí sí, perder el tiempo. La planificación se justifica cuando el error es caro de detectar o de deshacer, no como paso obligatorio universal.
El criterio, otra vez, es reversibilidad y alcance, no la sensación de que "esto es importante".
Planificar en voz alta con el propio agente
Una técnica que uso a menudo: antes de pedir que ejecute nada, le pido al agente que me describa su plan sin tocar código todavía. Leo ese plan y corrijo ahí, en texto, antes de que se traduzca en cambios reales. Corregir un plan mal enfocado cuesta un párrafo. Corregir el código que ya generó siguiendo ese plan mal enfocado cuesta mucho más.
Esto convierte la planificación en un paso barato y rápido, no en la carga pesada que solía ser cuando planificar significaba escribir documentación formal antes de nada.
La recomendación
No confundas velocidad de generación con ahorro de tiempo total. Un agente rápido que ejecuta un plan malo llega antes al mismo sitio equivocado. Antes de pedirle que actúe, define qué toca, qué debe quedar igual y cómo vas a verificar que salió bien. Ese rato de planificación, ahora que ejecutar es prácticamente gratis, es proporcionalmente la parte más valiosa de todo el proceso.
Relacionado: Cómo estructuro un proyecto para que un agente no se pierda