El plan que te saltas es la caída que depuras después
Todos los marcos de la ingeniería de software te dicen que avances rápido, lances pronto e iteres en producción. Para los sitios web generados por IA, eso es al revés. El constructor aquí se niega a transmitir código directamente desde tu prompt: se detiene, escribe un plan y espera a que lo revises, y esa negativa es la única decisión sobre la que se construye todo lo demás en este proceso. Más lento al principio, más barato después en todo lo demás. Yo acepto ese intercambio siempre, y creo que la mayoría de quienes defienden lo contrario no han visto de verdad lo que cuesta una suposición equivocada más adelante.
Este es el fallo que el plan existe para evitar. Escribes "un sitio de reservas para mi estudio" y le das a ejecutar. El sistema tiene que adivinar qué significa "reservas" —un widget de calendario, un elemento embebido de terceros, un sistema de reservas real con verificación de conflictos— y tiene que adivinarlo antes de haber escrito nada, porque no hay otro orden posible. Si se equivoca dentro de un plan, el arreglo es una frase, cinco segundos, listo. Si se equivoca dentro del código ya generado, ya no estás editando una frase, estás deshaciendo diez archivos que ya dependen de la suposición equivocada. He visto ambos casos. La corrección en la etapa del plan es un intercambio. El giro posterior a la generación sobre la misma ambigüedad es descartar y reconstruir.
El plan tampoco es solo una lista de tareas, y esto es lo que se le escapa a la gente. Es un contrato, y el sistema se atiene a él: un verificador de conformidad, uno de los agentes que debe dar su visto bueno antes de que se publique una compilación, compara el sitio terminado con el plan que aprobaste. ¿Se construyó cada página planificada? ¿La lista de funciones coincide con lo que se lanzó? "Terminado" no es una impresión aquí, es relativo a una promesa escrita, verificable línea por línea. Es una garantía más sólida que "el código funciona", y solo la consigues porque hay un documento contra el cual comprobar. Quita el plan y quitas la vara de medir.
Dónde esto realmente da resultado
Tu influencia como la persona que dirige la compilación se concentra al principio, la ejerzas o no. Si te importa la arquitectura de la información, la estructura de páginas, qué funciones entran en la v1 frente a la v2, esa exigencia vale diez veces más en la revisión del plan que después del primer paso de generación. Cuatro minutos extra releyendo un plan superan a un ida y vuelta arreglando una compilación que ya se torció.
El ejemplo más claro es el tipo de producto: sitio estático simple, aplicación instalable, compilación basada en framework, aplicación con backend y persistencia real. Parece un menú desplegable. No lo es. Es la decisión más estructural de todo el proceso, porque determina en silencio una docena de cosas que no tienen nada que ver con el aspecto del sitio.
| Tipo de producto | Vista previa | Publicar | Cuentas / base de datos |
|---|---|---|---|
| Sitio estático simple | Instantáneo, ya que son solo archivos estáticos | El resultado estático se copia sin problemas | No es posible: pedir inicio de sesión es pedir algo que este tipo no puede hacer estructuralmente |
| Compilación basada en framework | Compila primero; una compilación rota se muestra como "sin vista previa", no como "página rota" | La misma ruta de copia estática limpia, una vez compilado | No es posible |
| Aplicación con backend | — | Necesita un lugar donde ejecutar realmente un proceso, lo que falla de otra manera: un proceso caído, no un archivo faltante | El único tipo donde las cuentas y las bases de datos existen siquiera |
Y no puedes cambiar de tipo más adelante con ligereza. Pasar de un sitio simple a una app con backend no es un interruptor de configuración: es casi una segunda compilación, porque la mitad de las suposiciones del plan (cómo cargan las páginas, dónde viven los datos, qué significa "publicar") se hicieron pensando en el tipo anterior. Así que dilo al momento de planificar, aunque no estés del todo seguro: "existe la posibilidad de que necesite cuentas". Planificar para una app con backend y usar solo las partes estáticas no cuesta nada. Descubrir que la necesitabas después del hecho cuesta una reconstrucción.
Donde los críticos tienen razón
Nada de esto es gratis, y no voy a fingir que lo es. Los espacios de trabajo aislados por ejecución significan que tus archivos de conocimiento se copian de nuevo cada vez, nada regresa a tu máquina — bueno para ti si tu portátil muere a mitad de una compilación, malo para la latencia, porque aprovisionar un espacio de trabajo y, en compilaciones de framework, ejecutar una instalación real de dependencias dentro de un límite de contenedor lleva tiempo real. Ese límite de contenedor existe porque una compilación de framework ejecuta `npm install` y scripts de compilación arbitrarios — código que tú no escribiste, ejecutándose con privilegios de tiempo de compilación — y hacer eso en un host compartido sin aislamiento está a un ataque de confusión de dependencias de tocar los datos de otro inquilino. Rápido e inseguro era una opción disponible. Simplemente no era un intercambio que valiera la pena hacer.
Lo mismo ocurre con la verificación. Una compilación terminada no sale del pipeline cuando termina la generación; sale cuando un conjunto de verificadores independientes deja de encontrar cosas que valga la pena bloquear:
- Revisión de código
- Seguridad
- Enlaces y SEO
- Accesibilidad
- Conformidad
- Una ejecución real en el navegador
Eso no es una sola pasada, es marcar-corregir-revisar, en bucle hasta que a nadie le queda nada por decir, porque una sola pasada de linter puede pasar por alto una regresión que introduce su propia corrección. Arreglar un enlace roto y romper accidentalmente la jerarquía de encabezados en la misma página es exactamente el tipo de cosa que una comprobación única pasa por alto y una revisión posterior detecta. El costo honesto de ese bucle es que, de vez en cuando, una compilación tarda un minuto más justo al final sin razón aparente. La gente nota ese minuto. No notan a los seis agentes que acaban de terminar de debatir sobre su sitio. Es una queja justa sobre la experiencia — simplemente no creo que sea un buen argumento para publicar sin que el debate haya ocurrido.
