30 ago 2025·8 min
Un semplice modello mentale di come l'IA “pensa” quando costruisce app
Un modello mentale chiaro su come l'IA genera codice e decisioni nelle app—token, contesto, strumenti e test—con limiti e consigli pratici per il prompting.
Un modello mentale chiaro su come l'IA genera codice e decisioni nelle app—token, contesto, strumenti e test—con limiti e consigli pratici per il prompting.
Quando la gente dice “l'IA pensa”, generalmente intende qualcosa del tipo: capisce la tua domanda, ragiona su di essa e poi decide una risposta.
Per le AI testuali moderne (LLM), un modello mentale più utile è più semplice: il modello predice quale testo dovrebbe venire dopo.
Questo può sembrare deludente—fino a che non si vede fino a dove può arrivare quel “testo successivo”. Se il modello ha appreso abbastanza schemi durante l'addestramento, prevedere la parola successiva (e la successiva, e così via) può produrre spiegazioni, piani, codice, riassunti e persino dati strutturati che la tua app può usare.
Non devi imparare tutta la matematica sottostante per sviluppare buone funzionalità AI. Ciò che ti serve è un modo pratico per anticipare il comportamento:
Questo articolo è quel tipo di modello: niente hype, niente paper tecnici approfonditi—solo i concetti che ti aiutano a progettare esperienze prodotto affidabili.
Dal punto di vista di chi costruisce, il “pensiero” del modello è il testo che genera in risposta all'input che gli dai (il tuo prompt, i messaggi utente, le regole di sistema e qualsiasi contenuto recuperato). Il modello di default non verifica i fatti, non naviga il web e non “sa” cosa contiene il tuo database a meno che tu non passi quelle informazioni.
Imposta le aspettative di conseguenza: gli LLM sono estremamente utili per redigere, trasformare e classificare testo e per generare output simili al codice. Non sono motori magici della verità.
Divideremo il modello mentale in alcune parti:
Con queste idee puoi progettare prompt, UI e salvaguardie che rendono le funzionalità AI coerenti e affidabili.
Quando si dice che un'AI “pensa”, è facile immaginarla che ragiona come una persona. Un modello mentale più utile è più semplice: fa un autocomplete estremamente rapido—un piccolo pezzo alla volta.
Un token è un frammento di testo con cui il modello lavora. A volte è una parola intera (“mela”), a volte una parte di parola (“app” + “le”), a volte una punteggiatura e a volte anche uno spazio. La frammentazione esatta dipende dal tokenizer del modello, ma la conclusione è: il modello non elabora il testo come frasi ordinate—elabora token.
Il ciclo centrale del modello è:
Questo è tutto. Ogni paragrafo, elenco puntato e catena di “ragionamento” che vedi è costruita ripetendo questa predizione del token successivo molte volte.
Poiché il modello ha visto enormi quantità di testo durante l'addestramento, impara schemi come il flusso tipico di una spiegazione, come suona un'email cortese o come viene descritto di solito un fix. Quando fai una domanda, genera una risposta che si adatta agli schemi appresi e che corrisponde al contesto fornito.
Questo è il motivo per cui può sembrare sicuro e coerente anche quando sbaglia: ottimizza per quale testo dovrebbe venire dopo, non per verificare la realtà.
Il codice non è speciale per il modello. JavaScript, SQL, JSON e messaggi di errore sono tutti sequenze di token. Il modello può produrre codice utile perché ha imparato schemi comuni di programmazione, non perché “capisca” la tua app come farebbe un ingegnere del tuo team.
Quando qualcuno chiede “da dove ha preso quella risposta il modello?”, il modello mentale più utile è: ha imparato schemi da un'enorme quantità di esempi e ora ricombina quegli schemi per predire quale testo dovrebbe venire dopo.
Durante l'addestramento, al modello vengono mostrati molti frammenti di testo (libri, articoli, codice, documentazione, Q&A e altro). Si esercita ripetutamente in un compito semplice: dato un testo, predire il token successivo. Quando sbaglia, il processo di addestramento aggiusta i parametri interni in modo che la previsione successiva sia un po' più probabile.
Col tempo, quegli aggiustamenti si accumulano. Il modello inizia a codificare relazioni come:
Perché impara regolarità statistiche—non uno script fisso—può combinare schemi in modi nuovi. Se ha visto molti esempi di “spiegare un concetto” e molti esempi del “tuo scenario app”, spesso può fonderli in una risposta su misura.
Per questo un LLM può scrivere una plausibile email di onboarding per un prodotto di nicchia o adattare una spiegazione di integrazione API a uno stack specifico. Non sta recuperando un paragrafo memorizzato; sta generando una nuova sequenza che corrisponde agli schemi appresi.
Anche se nell'addestramento ci fosse un fatto specifico (per esempio, una fascia di prezzo o una policy interna), non dovresti presumere che il modello possa “consultarlo” in modo affidabile. L'addestramento non funziona come l'indicizzazione di una knowledge base interrogabile. È più vicino a una compressione: molti esempi vengono distillati in pesi che influenzano le predizioni future.
Ciò significa che il modello può sembrare certo su dettagli che in realtà sta indovinando sulla base di ciò che appare più spesso in contesti simili.
L'apprendimento di schemi è potente per produrre testo fluido e rilevante, ma la fluidità non è la stessa cosa della verità. Il modello può:
Per chi costruisce app, la conclusione principale è: le risposte di un LLM provengono solitamente da schemi appresi, non da fatti verificati. Se la correttezza è importante, devi ancorare l'output con i tuoi dati e controlli (ne parleremo nelle sezioni successive).
Quando un LLM scrive una risposta, non sta estraendo una singola “frase corretta” da un database. A ogni passo predice una gamma di possibili token successivi, ciascuno con una probabilità.
Se il modello scegliesse sempre il token singolarmente più probabile, le risposte sarebbero molto coerenti—ma anche ripetitive e a volte rigidamente innaturali. La maggior parte dei sistemi invece campiona dalle probabilità, il che introduce una casualità controllata.
Due impostazioni comuni determinano quanto variano gli output:
Se costruisci un'app, queste manopole servono meno a “essere creativi” in senso artistico e più a scegliere tra:
Poiché il modello ottimizza per testo plausibile, può produrre affermazioni che suonano certe—anche quando la premessa è incorretta o manca contesto. La sicurezza nel tono non è una prova. Per questo motivo le app spesso necessitano di ancoraggio (come retrieval) o passi di verifica per compiti fattuali.
Chiedi a un LLM: “Scrivi una funzione JavaScript che rimuova duplicati da un array.” Potresti ottenere uno qualsiasi di questi, tutti validi:
// Option A: concise
const unique = (arr) => [...new Set(arr)];
// Option B: explicit
function unique(arr) {
return arr.filter((x, i) => arr.indexOf(x) === i);
}
Scelte di campionamento diverse portano a stili differenti (conciso vs esplicito), compromessi diversi (velocità, leggibilità) e perfino comportamenti diversi su casi limite—il tutto senza che il modello “cambi idea”. Sta solo scegliendo tra molte continuazioni ad alta probabilità.
Quando si dice che un modello “ricorda” la conversazione, ciò che ha davvero è il contesto: il testo che può vedere in quel momento—il tuo ultimo messaggio, eventuali istruzioni di sistema e la porzione di chat precedente che ancora rientra nella finestra.
La finestra di contesto è un limite fisso su quanto testo il modello può considerare alla volta. Quando la conversazione si allunga abbastanza, le parti più vecchie escono dalla finestra e scompaiono dalla vista del modello.
Per questo vedrai comportamenti come:
Se continui ad aggiungere messaggi in un thread, stai competendo per uno spazio limitato. I vincoli importanti vengono spinti fuori dalla vista dalle nuove interazioni. Senza un sommario, il modello deve inferire cosa conta da quel che rimane visibile—quindi può sembrare sicuro mentre mancano dettagli chiave.
Una soluzione pratica è sintetizzare periodicamente: riaffermare l'obiettivo, le decisioni e i vincoli in un blocco compatto, poi continuare. Nelle app questo viene spesso implementato come “sommario della conversazione” che viene reinserito nel prompt.
I modelli tendono a seguire istruzioni che sono vicine all'output che stanno per generare. Quindi se hai regole da rispettare, mettile verso la fine del prompt—subito prima di “Ora produci la risposta.”
Se costruisci un'app, tratta questo come design di interfaccia: decidi cosa deve rimanere nel contesto (requisiti, preferenze utente, schema) e assicurati che sia sempre incluso—o riducendo lo storico della chat o aggiungendo un sommario compatto. Per più suggerimenti su come strutturare prompt, vedi /blog/prompting-as-interface-design.
Gli LLM sono molto bravi a produrre testo che sembra la risposta che ti aspetteresti da uno sviluppatore competente. Ma “sembra giusto” non è la stessa cosa di “è giusto.” Il modello predice token plausibili, non verifica l'output rispetto al tuo codebase, alle tue dipendenze o al mondo reale.
Se il modello suggerisce una correzione, un refactor o una nuova funzione, è comunque solo testo. Non esegue la tua app, non importa i pacchetti, non chiama la tua API e non compila il progetto a meno che tu non lo colleghi a uno strumento che possa farlo (per esempio un runner di test, un linter o un passaggio di build).
Questa è la contrasto chiave:
Quando l'AI sbaglia, spesso lo fa in modi prevedibili:
Questi errori possono essere difficili da notare perché la spiegazione circostante è di solito coerente.
Tratta l'output dell'AI come una bozza veloce di un collega che non ha eseguito il progetto in locale. La fiducia deve crescere nettamente dopo che:
Se i test non passano, considera la risposta del modello solo un punto di partenza, non una soluzione definitiva.
Un modello di linguaggio è ottimo nel proporre cosa potrebbe funzionare—ma da solo continua a generare solo testo. Gli strumenti permettono a un'app con AI di trasformare quelle proposte in azioni verificate: eseguire codice, interrogare un database, recuperare documentazione o chiamare un'API esterna.
Nei flussi di lavoro per costruire app, gli strumenti solitamente sono:
Il cambiamento importante è che il modello non finge più di sapere il risultato—può verificare.
Un modello mentale utile è:
Così si riduce l'incertezza. Se il linter segnala import non usati, il modello aggiorna il codice. Se i test falliscono, itera fino a che passano (o spiega perché non può farlo).
eslint/ruff/prettier per confermare lo stile e rilevare problemi.Gli strumenti possono essere potenti—e pericolosi. Applica il principio del minimo privilegio:
Gli strumenti non rendono il modello “più intelligente”, ma rendono l'AI della tua app più ancorata—perché può verificare, non solo narrare.
Un modello di linguaggio è ottimo per scrivere, riassumere e ragionare sul testo che può “vedere”. Ma non conosce automaticamente le ultime modifiche al prodotto, le policy aziendali o i dettagli del conto di un cliente. Retrieval‑Augmented Generation (RAG) è una soluzione semplice: prima recupera i fatti più rilevanti, poi chiedi al modello di scrivere usando quei fatti.
Considera RAG come “AI con libro aperto”. Invece di chiedere al modello di rispondere dalla memoria, la tua app estrae rapidamente alcuni passaggi rilevanti dalla tua sorgente di fiducia e li aggiunge al prompt. Il modello genera poi una risposta ancorata al materiale fornito.
RAG è un'ottima impostazione di default quando la correttezza dipende da informazioni esterne al modello:
Se il valore della tua app dipende dalla “risposta giusta per la nostra azienda”, RAG è di solito preferibile a sperare che il modello indovini.
RAG è efficace quanto la qualità del recupero. Se la ricerca restituisce passaggi obsoleti, irrilevanti o incompleti, il modello può produrre con sicurezza una risposta sbagliata—ora “ancorata” a una fonte errata. In pratica, migliorare la qualità della retrieval (chunking, metadata, freschezza e ranking) spesso aumenta l'accuratezza più di quanto facciano i ritocchi al prompt.
Un “agente” è semplicemente un LLM che gira in loop: fa un piano, compie un passo, osserva cosa è successo e decide cosa fare dopo. Invece di rispondere una volta sola, itera finché non raggiunge l'obiettivo.
Un modello mentale utile è:
Pianifica → Esegui → Verifica → Revisione
Questo loop trasforma un singolo prompt in un piccolo workflow. È anche il motivo per cui gli agenti possono sembrare più “indipendenti” della chat: il modello non si limita a generare testo, sceglie azioni e le sequenzia.
Gli agenti hanno bisogno di regole chiare per sapere quando fermarsi. Condizioni comuni di stop includono:
Le salvaguardie sono i vincoli che mantengono il loop sicuro e prevedibile: strumenti consentiti, fonti permesse, passaggi di approvazione umana e formati di output richiesti.
Poiché un agente può sempre proporre “un altro passo”, devi progettare per i casi di errore. Senza budget, timeout e limiti di passi, un agente può ripetersi in azioni ridondanti (“riprovare con una query leggermente diversa”) o accumulare costi.
Default pratici: limita le iterazioni, registra ogni azione, richiedi la validazione dei risultati degli strumenti e interrompi con una risposta parziale più quello che ha provato. Spesso è un design di prodotto migliore che lasciare l'agente in esecuzione indefinitamente.
Se costruisci con una piattaforma orientata al codice come Koder.ai, questo modello mentale “agente + strumenti” è particolarmente pratico. Non ti limiti a ricevere suggerimenti in chat—usando checkpoint (snapshot) e rollback l'assistente può aiutarti a pianificare feature, generare componenti React/Go/PostgreSQL o Flutter e iterare con punti di controllo in modo da muoverti velocemente senza perdere il controllo delle modifiche.
Quando metti un LLM dietro a una funzionalità, il tuo prompt non è più “solo testo”. È il contratto d'interfaccia tra il prodotto e il modello: cosa il modello deve fare, cosa è autorizzato a usare e come deve rispondere affinché il tuo codice possa consumare l'output in modo affidabile.
Una mentalità utile è trattare i prompt come moduli UI. I buoni moduli riducono l'ambiguità, costringono le scelte e rendono ovvia l'azione successiva. I buoni prompt fanno lo stesso.
Prima di rilasciare un prompt, assicurati che dichiari chiaramente:
I modelli seguono schemi. Un modo efficace per “insegnare” il pattern desiderato è includere un singolo esempio di input buono e output buono (soprattutto se il compito ha casi limite).
Anche un solo esempio può ridurre i tentativi e impedire al modello di inventare un formato che l'interfaccia non può mostrare.
Se un altro sistema deve leggere la risposta, richiedila strutturata. Chiedi JSON, una tabella o punti rigidi.
You are a helpful assistant.
Task: {goal}
Inputs: {inputs}
Constraints:
- {constraints}
Output format (JSON):
{
"result": "string",
"confidence": "low|medium|high",
"warnings": ["string"],
"next_steps": ["string"]
}
Questo trasforma il “prompting” in design di interfaccia prevedibile.
Aggiungi una regola esplicita come: “Se mancano requisiti chiave, poni domande chiarificatrici prima di rispondere.”
Quella singola linea può impedire output sicuri ma errati—perché il modello è autorizzato (e ci si aspetta) di fermarsi e chiedere i campi mancanti invece di indovinare.
Nella pratica, i prompt più affidabili rispecchiano il modo in cui il tuo prodotto builda e distribuisce. Per esempio, se la tua piattaforma supporta pianificazione prima, poi generazione delle modifiche, poi esportazione del codice o deployment, puoi rispecchiare ciò nel contratto del prompt (pianifica → produce diff/step → conferma → applica). La “planning mode” di Koder.ai è un buon esempio di come trasformare il processo in fasi esplicite riduca il drift e aiuti i team a revisionare le modifiche prima del rilascio.
La fiducia non nasce dal fatto che un modello “suona” sicuro. Nasce dal trattare l'output AI come qualsiasi altra dipendenza del prodotto: misurata, monitorata e vincolata.
Inizia con un piccolo insieme di compiti reali che la tua app deve svolgere bene. Poi trasformali in controlli ripetibili:
Invece di chiederti “Va bene?”, monitora “Quanto spesso passa i test?” Metriche utili includono:
Quando qualcosa va storto, devi poterlo riprodurre. Registra (con opportuna redazione):
Questo rende il debug praticabile e ti aiuta a rispondere: “È cambiato il modello o i nostri dati/strumenti?”
Alcuni default prevengono incidenti comuni:
Di solito significa che il modello può produrre testo coerente e orientato a uno scopo che sembra comprensione e ragionamento. In pratica, un LLM effettua una predizione del token successivo: genera la continuazione più probabile dato il tuo prompt, le istruzioni e qualsiasi contesto fornito.
Per chi costruisce app, la conclusione utile è che il “pensiero” è il comportamento dell'output che puoi modellare e vincolare — non una garanzia interna di verità.
Un token è un pezzo di testo che il modello elabora e genera (una parola intera, parte di una parola, punteggiatura o spaziatura). Poiché i modelli operano sui token, non sulle “frasi”, costi, limiti e troncamenti sono tutti misurati in token.
Praticamente:
Perché la generazione è probabilistica. A ogni passo il modello assegna probabilità a molte possibili token successivi e la maggior parte dei sistemi campiona da quella distribuzione invece di scegliere sempre l'opzione più probabile.
Per rendere gli output più ripetibili:
Gli LLM ottimizzano per produrre testo plausibile, non per verificare fatti. Possono risultare sicuri perché una formula assertiva è un pattern comune nei dati di addestramento, anche quando l'affermazione sottostante è un'ipotesi.
Nel design di prodotto, considera la scorrevolezza come “buona scrittura”, non come “correttezza”, e aggiungi controlli (retrieval, strumenti, test, revisioni umane) quando la correttezza è importante.
La finestra di contesto è la quantità massima di testo che il modello può considerare contemporaneamente (istruzioni di sistema, storico della conversazione, frammenti recuperati, ecc.). Quando la conversazione diventa troppo lunga, le parti più vecchie escono dalla finestra e il modello non può più “vederle”.
Mitigazioni:
Non automaticamente. Per impostazione predefinita il modello non naviga il web, non legge il tuo database né esegue codice. Ha accesso solo a ciò che includi nel prompt e agli strumenti che connetti esplicitamente.
Se la risposta dipende da informazioni interne o aggiornate, passale tramite retrieval (RAG) o una chiamata a uno strumento invece di “chiederlo più forte”.
Usa gli strumenti quando hai bisogno di risultati verificati o di azioni reali invece di testo plausibile. Esempi comuni:
Un buon pattern è proponi → verifica → aggiusta, dove il modello itera in base agli output degli strumenti.
RAG (Retrieval‑Augmented Generation) è “AI con libro aperto”: la tua app recupera frammenti rilevanti da fonti attendibili (doc, ticket, policy) e li include nel prompt in modo che il modello risponda usando quei fatti.
Implementalo quando:
Il principale punto debole è una cattiva retrieval: migliorare ricerca, chunking e aggiornamento dei dati spesso è più efficace di ritoccare il prompt.
Un agente è un LLM che esegue un ciclo multipasso (pianifica, esegue un'azione, verifica i risultati, rivede) spesso utilizzando strumenti. È utile per workflow come “trova informazioni → prepara bozza → valida → invia”.
Per mantenere gli agenti sicuri e prevedibili:
Tratta i prompt come un contratto d'interfaccia: definisci obiettivo, input, vincoli e formato dell'output in modo che la tua app possa consumare i risultati in modo affidabile.
Costruttori di fiducia pratici: