El plan que no es el trabajo
Hay un nuevo ritual en los videos de YouTube sobre IA. Antes de escribir una sola línea de código, antes de mover nada, antes de empezar, debes pedirle a la IA que genere un PRD. Un documento de requerimientos. Un spec completo. Páginas de arquitectura para una idea que todavía no sabes si funciona.
El consejo tiene sentido. Hasta cierto punto.
Un PRD bien hecho reduce el trabajo en círculos. Obliga a pensar antes de hacer. Eso es real.
Pero hay algo que se pierde cuando lo convertimos en la única forma de trabajar con IA.
Toyota no inventó el Lean para que los equipos pasaran más tiempo planeando. Lo inventó para que el ciclo entre planear y aprender fuera lo más corto posible. Planear, Hacer, Estudiar, Actuar. No planear, planear más, afinar el plan, revisar el plan.
Hoy, Opus puede ayudarte a pensar un problema en veinte minutos. Sonnet puede implementar en cuarenta. El ciclo entero puede durar una hora.
Sin embargo, el ritual dice: primero el documento de cincuenta páginas.
El problema es usar el PRD como si todavía viviéramos en el mundo donde empezar costaba semanas. Donde una decisión equivocada al inicio era catastrófica porque deshacerla también costaba semanas.
Lo que antes justificaba planear largo ahora puede justificar planear rápido, aprender rápido y ajustar antes de que el error se vuelva caro.
El spec tiene su lugar. Pero no siempre debe ir primero.
¿Cuánto tiempo llevas refinando el plan para algo que todavía no has empezado?
Sí, en Vibe Coding sin mitos defiendo los PRDs. Este post no los cancela, los pone en contexto.