Cosa c'è davvero dentro un'app creata con l'IA: un tour per non sviluppatori

Hai digitato una descrizione, premuto invio e venti minuti dopo avevi un’app funzionante. Ottimo. Ma adesso hai cliccato su “visualizza file” e stai fissando un albero di cartelle che sembra scritto in un’altra lingua. Cos’è package.json? Perché ci sono quaranta cose in node_modules? Cosa significa “schema” e perché ne hai uno?

Questo post è un tour guidato. Non un tutorial — un tour. Dopo averlo letto non saprai scrivere nessuno di questi file da solo, ma la prossima volta che qualcosa ti sembrerà strano, saprai quale angolo dell’app indicare.

Userò tre esempi che ricorreranno lungo tutto il pezzo, così le parti astratte hanno qualcosa di concreto a cui agganciarsi:

• Maya, responsabile marketing, che ha costruito una classifica di referral per il suo team.
• Jordan, insegnante di yoga, che ha costruito un sito per prenotare le lezioni.
• Sam, che gestisce una panetteria, che ha costruito una pagina per “preordinare i croissant di domani”.

Tutti e tre hanno usato un creatore di app con IA. Tutte e tre le app sembrano completamente diverse a un cliente. Sotto il cofano, hanno una forma sorprendentemente simile.

Il frontend: ciò che il tuo cliente vede davvero

Il frontend è tutto ciò che si carica nel browser di qualcuno. Pulsanti, layout, font, animazioni, il modo in cui un modulo si svuota dopo che lo invii. Se riesci a vederlo, è frontend.

Per Maya, il frontend è una classifica con posizione, nome e numero di referral. Per Jordan, è un calendario di lezioni con un pulsante “prenota”. Per Sam, è un elenco di dolci con dei piccoli pulsanti più-e-meno accanto a ciascuno.

Dentro il progetto, il frontend di solito vive in una cartella che si chiama qualcosa come app/, pages/ o src/. Vedrai file che finiscono in .tsx o .jsx. Ciascuno è all’incirca “una schermata” o “un pezzo di una schermata”. La riga della classifica è un file. L’intestazione è un altro file. La pagina che lega tutto insieme è un terzo.

Quando chiedi al creatore di app con IA di “rendere i pulsanti più tondi” o “spostare la classifica a destra”, è questa la parte che cambia.

Il backend: la parte che pensa

Il backend è la parte che nessuno vede, ma da cui tutti dipendono. È il codice che gira da qualche altra parte — su un server, non nel browser del cliente — quando deve succedere qualcosa di cui non ci si può fidare a lasciarlo fare al browser del cliente da solo.

Perché il browser non può fare tutto? Perché il browser è la macchina del cliente, e non ti puoi fidare. Se la classifica di Maya aggiornasse i conteggi dei referral puramente nel browser, chiunque potrebbe fare clic destro e aggiungersi 9.000 referral. Quindi il backend è dove vivono le regole: “questa persona può fare questo, ma non quello”, “salva davvero questo nel database”, “manda questa email”.

Il backend di solito vive in una cartella che si chiama api/, server/ o app/api/. I file lì dentro sono di solito corti. Ciascuno gestisce una richiesta specifica: “crea una prenotazione”, “elenca i croissant di oggi”, “aggiungi un referral”.

Quando qualcosa funziona nella tua app ma il risultato non resta — clicchi invia, vedi una conferma, ma domani i dati sono spariti — è quasi sempre nel backend che si nasconde il bug.

Il database: la memoria della tua app

Immagina la memoria della tua app come una fila di schedari. Ogni schedario ha un’etichetta sul davanti. Uno dice “utenti”. Uno dice “prenotazioni”. Uno dice “ordini_croissant”. Dentro ogni schedario, ogni cassetto è una riga. Ogni cassetto ha lo stesso insieme di scomparti: un nome, un’email, un created_at, uno stato.

Quella struttura — “quali schedari esistono, quali scomparti ha ogni riga” — si chiama schema. È il file più importante del progetto, anche se è probabilmente anche quello dall’aspetto più noioso. Trova un file chiamato schema.ts, schema.prisma, o qualcosa dentro una cartella chiamata db/ o migrations/. Aprilo. Vedrai un elenco che rispecchia ciò che la tua app ricorda davvero del mondo.

Lo schema di Jordan ha una tabella classes, una tabella bookings e una tabella users. Quello di Sam ha products, orders e order_items. Quello di Maya ha members e referrals. La forma dello schema è la forma del prodotto, ed è per questo che cambiarlo più avanti è più difficile che cambiare l’aspetto dei pulsanti.

Un trucco utile: se riesci a descrivere cosa ricorda la tua app, in parole semplici, di solito riesci a descrivere lo schema. “Ricordo il nome e l’email di ogni cliente. Per ogni cliente, ricordo gli ordini che ha fatto. Per ogni ordine, ricordo quali dolci e quanti di ciascuno.” Quella frase è, quasi parola per parola, lo schema.

Auth: il buttafuori alla porta

“Auth” sono due parole schiacciate insieme: autenticazione (chi sei?) e autorizzazione (cosa ti è permesso fare?). Entrambe sono di solito gestite da un piccolo gruppo di file in una cartella chiamata auth/, oppure da un servizio il cui nome potresti riconoscere: Clerk, Auth0, Supabase Auth, NextAuth.

Le due domande sono diverse. L’autenticazione risponde: “è davvero Maya?” — di solito con una password, un login con Google o un magic link inviato via email. L’autorizzazione risponde: “a Maya è permesso cancellare i referral degli altri?” — e la risposta onesta per la maggior parte delle app create con l’IA nella loro prima settimana è “ci siamo dimenticati di controllare”.

È questa la parte più spesso silenziosamente rotta. La schermata di login funziona, quindi dà l’impressione di essere sicura. Ma il backend non sempre controlla che la persona loggata sia la stessa persona di cui sta cercando di leggere i dati. Se la tua app ha un qualche concetto di “i miei dati contro i tuoi dati”, chiedi esplicitamente al creatore di app con IA: “Assicurati che gli utenti possano vedere e modificare solo i propri dati.” Ti stupirà quanto spesso quella singola frase riveli un controllo mancante.

Integrazioni: le cose che non hai costruito ma che usi lo stesso

È qui che la maggior parte dei non sviluppatori sottovaluta cosa sta succedendo davvero. La cosa che manda l’email “i tuoi croissant sono pronti” di Sam non è codice — è un account su SendGrid o Resend. La cosa che processa il pagamento della lezione di Jordan non è codice — è Stripe. La cosa che ospita le foto sulla classifica di Maya non è codice — è un servizio di archiviazione come S3 o Cloudinary.

Ogni integrazione compare in due posti. C’è un piccolo pezzo di codice nel backend che dice “ehi, Stripe, addebita questa carta”. E c’è una chiave — una lunga stringa segreta — conservata da qualche parte al sicuro (di solito un file chiamato .env che nessuno dovrebbe mai mettere sotto versione) che dimostra a Stripe che la richiesta è arrivata dalla panetteria di Sam e non da uno sconosciuto.

Se mai ti chiederai perché la tua app all’improvviso smette di mandare email o smette di accettare pagamenti, la causa è quasi sempre una di queste: una chiave scaduta, un limite d’uso raggiunto, o un cambiamento nelle policy dell’integrazione. Il codice non si è rotto. Si è rotta la stretta di mano.

Il deploy: come finisce su internet

Il pezzo finale è la parte che trasforma la cartella sul tuo disco in una cosa che il tuo cliente può visitare a un URL. Di solito significa tre piccole cose che lavorano insieme:

• L’host: un servizio come Vercel, Netlify, Fly o Render che esegue il tuo backend e serve il tuo frontend.
• Il dominio: un nome come classifica-di-maya.com che punta al tuo host.
• Il build: la ricetta che prende i tuoi file sorgente caotici e li trasforma nella versione più snella e veloce che gira davvero.

Quando qualcosa funziona in locale ma si rompe in produzione, il problema è di solito qui. Una chiave impostata sul tuo portatile ma non sull’host. Una libreria installata in sviluppo ma non in produzione. Un database che esiste nel tuo browser ma non sul sito live.

L’abitudine da cinque minuti che si ripaga da sola

Non devi leggere ogni file del tuo progetto. Non devi sapere cosa fa la maggior parte di essi. Ma dovresti, una volta a settimana, fare una passeggiata di cinque minuti in cui apri ognuna delle cartelle qui sopra e chiedi al creatore di app con IA, in parole semplici, cosa è cambiato.

Maya lo fa ogni venerdì pomeriggio. Digita: “Cosa è cambiato nello schema questa settimana, e perché?” E: “Ci sono nuove integrazioni in quest’app che non ho chiesto io?” Le risposte sono quasi sempre rassicuranti. Le poche volte che non lo sono, intercetta i problemi mentre sono ancora piccoli.

Ecco l’intero senso del capire le parti. Non per diventare uno sviluppatore. Solo per riuscire a fare domande migliori.

Dove andare adesso

Se questo tour ti è stato utile, due approfondimenti meritano il tuo tempo. Il bug “sembra a posto” racconta cosa fare quando una di queste parti è silenziosamente rotta, e pronto per la demo contro pronto per la produzione spiega come capire quando la tua app è passata dal primo stadio al secondo. Stessa mappa, usi diversi.