Sí, de dos maneras complementarias: regenerar la aplicación a partir de una descripción enriquecida: la vía sin código, adaptada a los cambios de estructura: o recuperar el código fuente y hacerlo evolucionar como cualquier proyecto, por ti mismo o a través de un desarrollador. La segunda vía supone una condición a menudo pasada por alto: que el código generado sea estándar y legible, no una maraña que nadie se atreve a tocar.
«Generada por IA» abarca dos realidades muy distintas
Todo depende de QUÉ escribió la IA. En la generación «IA pura», un gran modelo de lenguaje escribe el código él mismo, línea a línea: dos generaciones de la misma necesidad producen dos códigos distintos, plausibles pero nunca garantizados. La modificación hereda esa fragilidad: cada retoque vuelve a pasar por el modelo, que puede reescribir de paso lo que funcionaba, y nadie sabe de antemano qué código saldrá.
Blueprint Maker hace lo contrario: la IA no escribe el código, escribe la ESPECIFICACIÓN, la lista estructurada de tus entidades, pantallas e indicadores, que validas como un plan. Después, builders deterministas traducen ese plan en código: el mismo plan produce siempre el mismo código, con las mismas convenciones. Esa separación es lo que hace seguras las dos vías de abajo: regenerar no reinventa tu aplicación, y el código exportado sigue siendo legible para cualquier desarrollador.
Primera vía: regenerar a partir de la descripción
¿La necesidad evoluciona? La descripción evoluciona con ella. Añades «cada intervención tiene ahora un técnico asignado y un nivel de urgencia», relanzas la generación, validas el nuevo plan: la aplicación regenerada integra la entidad, las pantallas y los indicadores correspondientes. Es el modo de evolución natural de Blueprint Maker, sin escribir una sola línea.
Esta vía es la adecuada para los cambios estructurales: nuevas entidades, nuevos estados, nuevos indicadores. La descripción sigue siendo la fuente única: documenta tu herramienta en lenguaje sencillo, y el pipeline determinista garantiza que un mismo plan validado produzca una misma aplicación.
Segunda vía: hacer evolucionar el código exportado
Para lo que supera el perímetro generado: una necesidad muy específica, una integración particular, la salida de emergencia es el código mismo. Las aplicaciones Blueprint Maker se exportan en ZIP o se envían a tu GitHub: un proyecto Next.js + Prisma estándar, la estructura que todo desarrollador web conoce.
Es aquí donde pesa el método de generación: un código escrito libremente por un modelo suele ser ilegible y frágil de modificar; un código escrito por builders deterministas es homogéneo de una aplicación a otra: las mismas convenciones, las mismas estructuras. Como el código es exportable y estándar, un desarrollador puede añadir lo que la generación no cubre.
Elegir la vía según el cambio
Las dos vías no se excluyen; cada una tiene su terreno.
- Añadir una entidad, un estado, un indicador: regenerar a partir de la descripción enriquecida.
- Ajustar un perímetro aún cambiante: regenerar mientras la estructura no se estabilice.
- Integrar un sistema externo o una necesidad fuera de perímetro: hacer evolucionar el código exportado con un desarrollador.
- Retomar el control de la herramienta de forma duradera a nivel interno: pasar al código, a la URL dedicada o a tu propio alojamiento, a elección.