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.
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.