Come costruire un'app (o un sito) con l'AI senza creare caos

Se hai provato a usare ChatGPT (o Claude, o qualsiasi "AI che scrive codice") per costruire un'app, probabilmente hai vissuto questo film: all'inizio sembra magia, poi dopo qualche modifica tutto si rompe, non sai cosa hai rotto, e ogni nuova richiesta genera ancora più caos.

Il punto è che l'AI non è "un programmatore junior super veloce". È qualcos'altro. E se capisci cosa è davvero, capisci anche perché spesso ti lascia con un progetto che sembra funzionare… finché non diventa ingestibile.

Il modo più semplice per capirla è questo: l'AI è un modello probabilistico che genera la parte mancante di un input iniziale, basandosi sul contesto.

Esempio terra-terra:

Scrivi: "Chi dorme non piglia ____".

È molto probabile che completi con "pesci". Perché è un pattern comune, perché il contesto è chiaro, perché la frase "suona" già in un certo modo.

Ma se scrivi solo: "Chi dorme…", senza dire nient'altro, l'AI deve indovinare che cosa intendi: stai citando un proverbio? Stai facendo una battuta? Stai iniziando un discorso sul sonno? Il ventaglio di completamenti possibili esplode, e con lui cresce la probabilità di errore.

Questa è la chiave: l'AI è un amplificatore della qualità dell'input. Più il contesto è preciso, più il completamento è utile. Più il contesto è vago, più il completamento diventa "creativo" nel senso sbagliato: sembra plausibile, ma non è affidabile.

Quando chiedi all'AI "fammi una web app", stai facendo l'equivalente di scrivere "Chi dorme…".

Un programmatore, quando chiede a un'AI di generare un file, di solito sta implicitamente passando un contesto enorme, anche se non lo scrive tutto nel prompt. Sa già:

Tu magari stai chiedendo "fammi la login con Google" senza sapere che stai aprendo una scatola piena di dettagli: sessioni vs token, callback URL, gestione dei refresh token, ambienti diversi, configurazioni, segreti, redirect, error handling, logging.

E qui arriva la frustrazione tipica: il codice sembra giusto… ma tu sei troppo lontano dal risultato per poterlo governare. Non perché sei "scarso", ma perché ti manca il ponte tra parole e sistema.

All'inizio un progetto è piccolo. Anche una soluzione imperfetta regge, perché c'è poco da tenere insieme. È come costruire una casa di LEGO: finché fai una casetta, tutto ok. Quando provi a farci un grattacielo, scopri che sotto hai messo pezzi a caso.

Nel software questa cosa ha un nome molto concreto: debito tecnico.

Il debito tecnico non è "codice brutto" in senso estetico. È quando le prime scelte strutturali (cartelle, responsabilità dei moduli, gestione dei dati, naming, flussi, dipendenze) creano un costo nascosto che paghi dopo. E lo paghi con interessi.

Il problema è che l'AI può generare codice "che compila" anche se l'architettura è fragile. E più vai avanti, più ogni patch diventa una toppa su una toppa. A un certo punto ti ritrovi nel loop:

E spesso la risposta, purtroppo, diventa: sì, si rifà.

Serve eccome. Tantissimo.

Solo che va vista per quello che è: un moltiplicatore. Se hai direzione, struttura e criterio, l'AI ti fa andare 5–10 volte più veloce. Se non li hai, ti fa andare 5–10 volte più veloce… nella direzione sbagliata.

È la stessa differenza che c'è tra:

L'AI oggi è spesso un "no-code che scrive codice": fantastico per prototipi, demo, mockup, prove di concetto. Ma se l'obiettivo è un prodotto serio, destinato a crescere, con utenti reali e soldi che passano dentro, allora la qualità delle fondamenta diventa tutto.

Qui arriva la parte controintuitiva: non è che "devi imparare i prompt". Quella è una conseguenza.

Prima serve una mappa minima: cosa stai costruendo, come si compone, quali parti parlano con quali, dove stanno i dati, chi fa cosa, cosa succede quando qualcosa va storto.

Perché quando non hai questa mappa, i prompt diventano inevitabilmente generici. E i prompt generici producono output generici. Output generici, nel software, non sono "neutri": sono una fonte continua di incoerenze.

Esempio semplice: se in un punto l'AI decide che usi JWT, in un altro punto ti genera sessioni, in un altro ancora mischia le due cose, tu non hai un "criterio" per vedere l'errore subito. Lo scopri quando esplode. E a quel punto è già tardi.

Se leggendo hai pensato "ok, ma deploy che vuol dire?" oppure "che differenza c'è tra sviluppo e produzione?" oppure ancora "cos'è esattamente il debito tecnico?", allora è molto probabile che tu stia usando l'AI nel modo più comune: prompt generici che generano più caos che struttura.

E non è una colpa. È solo un segnale: significa che oggi stai chiedendo all'AI di correre più veloce di quanto tu riesca a seguirla.

La soluzione, qui, è sorprendentemente semplice (anche se non è "istantanea"): ridurre la distanza tra te e ciò che l'AI produce. Non devi diventare un ingegnere software, ma devi capire le fondamenta minime del mondo in cui stai costruendo.

Se stai lavorando nel web, il percorso più efficace è questo: chiarirti cosa fa davvero HTML (struttura), CSS (stile), JavaScript (logica e interazioni). Capire com'è composta una pagina. Capire cos'è un server, cos'è un'API, dove vivono i dati (database) e perché "sviluppo" e "produzione" sono ambienti diversi. Sono concetti che non ti servono per fare "il programmatore puro", ti servono per orientarti: leggere quello che l'AI ha generato, capire dove mettere le mani, e soprattutto fare richieste sensate.

La parte bella è che l'AI può aiutarti anche qui: puoi usarla come tutor, chiedendole spiegazioni con esempi su misura, facendoti creare mini-esercizi, chiedendo "perché questa cosa è sbagliata?" e facendoti tradurre termini e flussi in parole semplici. Ma funziona solo se lo studio ha una struttura: un tema alla volta, obiettivi chiari, e un modo per verificare se hai capito davvero.

In altre parole: l'AI non sostituisce le basi. Le rende più veloci da imparare. E quando inizi a capirle, smetti di generare caos e inizi a costruire progetti che reggono anche dopo la prima "feature in più".