Modello mentale di un LLM per chi sviluppa

Un LLM non esegue istruzioni come un interprete, non consulta automaticamente la tua repo e non “sa” se una risposta è corretta. Produce testo condizionato dal prompt, dal contesto disponibile, dai parametri e dall’addestramento ricevuto. Per uno sviluppatore questa differenza è decisiva: il prompt non è un comando, è un modo per costruire le condizioni in cui una risposta utile diventa più probabile.

Perché questa lezione conta

Molti errori di prompt engineering nascono da un modello mentale sbagliato. Se immagini l’LLM come un collega che conosce il progetto, tenderai a scrivere richieste vaghe: “sistema il login”, “migliora questo componente”, “trova il bug”. Se lo immagini come un motore probabilistico con capacità linguistiche forti e contesto limitato, inizi a fornire obiettivi, vincoli, dati e criteri di verifica.

In questa lezione costruisci la base del corso: capire che cosa puoi chiedere al modello, che cosa devi fornirgli tu e che cosa devi verificare fuori dalla risposta.

Tre idee da tenere ferme

1. Previsione del token successivo

Un LLM genera una sequenza scegliendo, a ogni passaggio, token plausibili rispetto a ciò che ha già visto nel prompt e nel contesto. Questo non significa che “tira a caso”: modelli moderni hanno capacità molto sofisticate di generalizzazione, trasformazione e ragionamento linguistico. Ma significa che la risposta resta condizionata da ciò che gli hai dato e da ciò che è statisticamente coerente.

Per il prompting pratico questa idea produce tre conseguenze:

• le prime istruzioni e il contesto rilevante orientano fortemente il comportamento;
• un output fluido non è una prova di correttezza;
• ambiguità, esempi sbagliati e contesto rumoroso aumentano la probabilità di risposte sbagliate ma convincenti.

2. Addestramento e allineamento non sono memoria di progetto

Pretraining, fine-tuning e allineamento rendono il modello capace di parlare di codice, API, pattern e problemi tecnici. Non gli danno però accesso alla tua codebase, alle decisioni del team, alle issue aperte o alla documentazione aggiornata. Un modello può conoscere bene il concetto di middleware, ma non sapere perché nel tuo progetto quel middleware è stato scritto in un certo modo.

Quando cambi modello o provider, non cambia solo la “qualità media”. Possono cambiare stile di risposta, tolleranza all’ambiguità, capacità di seguire formati stretti, propensione a chiedere chiarimenti, gestione del codice lungo e comportamento su casi limite.

3. Capacità emergenti e limiti strutturali convivono

Un LLM può aiutare a spiegare codice, proporre refactor, generare test, confrontare alternative e sintetizzare log. Nello stesso tempo può inventare API, trascurare vincoli di sicurezza, perdere dettagli in contesti lunghi o dare per vera una premessa falsa.

Il punto non è decidere se “fidarsi” o “non fidarsi” in assoluto. Il punto è scegliere task in cui puoi fornire contesto sufficiente e verificare il risultato.

Esempio operativo

Prompt debole:

Dimmi se questa soluzione va bene per la produzione.

Prompt migliore:

Valuta questa soluzione per un servizio Node.js interno.

Contesto:
- traffico previsto: basso, uso da team interno;
- dati trattati: email e ID cliente, nessun dato di pagamento;
- deployment: server LiteSpeed con output statico dove possibile;
- vincolo: niente nuove dipendenze se non sono motivate.

Rispondi separando:
1. rischi tecnici;
2. rischi di sicurezza/privacy;
3. assunzioni che stai facendo;
4. verifiche locali da eseguire prima di accettare la soluzione.

Se un'informazione non è nel contesto, non inventarla: mettila in "da chiarire".

Il secondo prompt non rende il modello infallibile, ma rende più controllabile il tipo di errore. Se sbaglia, puoi vedere dove ha ignorato un vincolo o fatto un’assunzione non concessa.

Laboratorio guidato

Scegli un task tecnico reale, ma piccolo: spiegare una funzione, valutare una libreria, proporre un refactor, generare test per un modulo.

Esegui tre varianti:

1. prompt vago, senza contesto;
2. prompt con contesto minimo e obiettivo chiaro;
3. prompt con contesto, vincoli e richiesta esplicita di assunzioni/verifiche.

Per ogni variante annota:

Criterio	Prompt vago	Prompt con contesto	Prompt con verifiche
Ha dichiarato assunzioni?
Ha inventato dettagli?
Ha prodotto output verificabile?
Ha rispettato i vincoli?
Richiede lavoro umano residuo?

Output atteso

Una scheda comparativa con le assunzioni implicite del modello su cui non puoi contare nel tuo workflow.

La scheda deve contenere almeno:

• task scelto;
• prompt usati;
• differenze osservate;
• assunzioni inventate o non dichiarate;
• verifiche che avresti dovuto chiedere fin dall’inizio;
• regola pratica da riusare nei prompt futuri.

Checklist di verifica

• so spiegare perché un prompt condiziona il modello ma non lo comanda;
• distinguo conoscenza generale del modello e conoscenza specifica del progetto;
• so indicare almeno tre casi in cui devo fornire contesto invece di fidarmi della memoria del modello;
• so trasformare una risposta plausibile in una risposta verificabile;
• ho salvato una regola pratica riusabile per il mio workflow.

Errori comuni

Trattare il modello come un motore di verità. Una risposta ben scritta può essere sbagliata. La verifica resta parte del lavoro dello sviluppatore.

Confondere spiegazione e garanzia. Se il modello spiega bene una scelta, non significa che la scelta sia corretta per il tuo progetto.

Cambiare modello senza riesaminare i prompt. Un prompt stabile su un modello può diventare troppo verboso, troppo permissivo o meno aderente al formato su un altro.

Collegamenti

• Modulo: Fondamenti per sviluppatori — questa lezione apre il corso.
• Prossima lezione: Token, finestra di contesto, attenzione.
• Per il metodo operativo su codice generato: vedi il corso Vibe Coding.