Sì, in due modi complementari: rigenerare l'applicazione da una descrizione arricchita: la via senza codice, adatta alle evoluzioni di struttura: oppure recuperare il codice sorgente e farlo evolvere come qualsiasi progetto, da soli o tramite uno sviluppatore. La seconda via presuppone una condizione spesso trascurata: che il codice generato sia standard e leggibile, non un groviglio che nessuno osa toccare.
«Generata dall'IA» copre due realtà molto diverse
Tutto dipende da COSA ha scritto l'IA. Nella generazione «IA pura», un grande modello linguistico scrive il codice stesso, riga per riga: due generazioni dello stesso bisogno producono due codici diversi, plausibili ma mai garantiti. La modifica eredita questa fragilità: ogni ritocco ripassa dal modello, che può riscrivere ciò che funzionava, e nessuno sa in anticipo quale codice uscirà.
Blueprint Maker fa l'opposto: l'IA non scrive il codice, scrive la SPECIFICA, l'elenco strutturato delle tue entità, schermate e indicatori, che convalidi come un piano. Builder deterministici traducono poi questo piano in codice: lo stesso piano produce sempre lo stesso codice, con le stesse convenzioni. È questa separazione a rendere sicure le due vie qui sotto: rigenerare non reinventa la tua applicazione, e il codice esportato resta leggibile per qualsiasi sviluppatore.
Prima via: rigenerare dalla descrizione
L'esigenza evolve? La descrizione evolve con essa. Aggiungi «ogni intervento ha ora un tecnico assegnato e un livello di urgenza», rilanci la generazione, convalidi il nuovo piano: l'applicazione rigenerata integra l'entità, le schermate e gli indicatori corrispondenti. È il modo di evoluzione naturale di Blueprint Maker, senza scrivere una riga.
Questa via è quella giusta per le evoluzioni strutturali: nuove entità, nuovi stati, nuovi indicatori. La descrizione resta la fonte unica: documenta il tuo strumento in linguaggio semplice, e la pipeline deterministica garantisce che uno stesso piano convalidato produca una stessa applicazione.
Seconda via: far evolvere il codice esportato
Per ciò che va oltre il perimetro generato: un'esigenza molto specifica, un'integrazione particolare, la via d'uscita è il codice stesso. Le applicazioni Blueprint Maker si esportano in ZIP o si inviano al tuo GitHub: un progetto Next.js + Prisma standard, la struttura che ogni sviluppatore web conosce.
È qui che pesa il metodo di generazione: un codice scritto liberamente da un modello è spesso illeggibile e fragile da modificare; un codice scritto da builder deterministici è omogeneo da un'applicazione all'altra: le stesse convenzioni, le stesse strutture. Essendo il codice esportabile e standard, uno sviluppatore può aggiungervi ciò che la generazione non copre.
Scegliere la via in base al cambiamento
Le due vie non si escludono; ciascuna ha il suo terreno.
- Aggiungere un'entità, uno stato, un indicatore: rigenerare dalla descrizione arricchita.
- Adeguare un perimetro ancora in movimento: rigenerare finché la struttura non si stabilizza.
- Integrare un sistema esterno o un'esigenza fuori perimetro: far evolvere il codice esportato con uno sviluppatore.
- Riprendere in mano lo strumento in modo duraturo internamente: passare al codice, all'URL dedicato o al proprio hosting a scelta.