Cosa sa fare bene un LLM, cosa sbaglia in modo prevedibile

Un LLM non è onnisciente né inutile. È uno strumento con una distribuzione di forze e debolezze stabile e prevedibile. Conoscerle non è opinione, è prerequisito per usarlo bene. Senza, finisci a fidarti dove non dovresti e a diffidare dove sarebbe efficace.

Perché questa lezione conta

Il marketing dei modelli oscilla fra “fa tutto” e “non fa nulla di affidabile”. La verità operativa è più precisa: ci sono famiglie di task in cui un LLM ben usato accelera di 10x, e famiglie in cui sbaglia in modo sistematico anche con prompt ottimi. Questa lezione costruisce la mappa, basata su come funzionano davvero i modelli (predittori statistici di token addestrati su corpus testuale), non su narrazioni.

Obiettivo operativo

Alla fine devi saper:

1. nominare almeno cinque task in cui un LLM è affidabile, e cinque in cui sbaglia in modo prevedibile;
2. spiegare il “perché” di entrambi gli elenchi (non memorizzare, derivare dalla natura dello strumento);
3. costruire una tua checklist personale dei segnali di allarme prima di accettare codice generato.

Nucleo della lezione

1. Punti forti reali

Un LLM è forte quando il task ha pattern testuali ben rappresentati nel training, struttura prevedibile e basso bisogno di stato esterno aggiornato:

• Trasformare testo in struttura: testo libero → JSON, tabella, schema, classificazione.
• Generare boilerplate: setup framework, configurazioni standard, scaffold di componenti, test di base, regex comuni.
• Spiegare codice esistente: parafrasare, identificare flusso, suggerire nomi, riassumere funzione.
• Proporre alternative: dato un approccio, generare 3 varianti con trade-off.
• Sintetizzare errori: dato uno stack trace o log, individuare la riga rilevante e la categoria di problema.
• Riformulare: rinominare, riscrivere stesso comportamento con stile diverso, tradurre fra linguaggi simili.

Ragione: questi task hanno pattern stabili, output verificabile e non richiedono fatti aggiornati o ragionamento profondo su contesto specifico del progetto.

2. Punti deboli prevedibili

Un LLM sbaglia in modo sistematico in casi precisi:

• Dettagli aggiornati: API recenti, versioni di librerie, breaking change. Il training ha un cutoff e il modello inventa coerentemente al posto di ammettere ignoranza.
• Librerie inesistenti: nomi plausibili, metodi che sembrano standard ma non esistono. Sintomo: import che non risolve, funzione non trovata.
• Sicurezza: SQL injection, XSS, gestione segreti, autorizzazione lato server. Il modello produce codice “che funziona” ma con falle classiche se non glielo chiedi esplicitamente.
• Casi limite: input vuoti, valori massimi, race condition, timezone, encoding. Coperti solo se previsti nel prompt.
• Coerenza su contesti lunghi: conversazione di 50 turni, repo grande. Il modello dimentica vincoli iniziali e contraddice decisioni precedenti.
• Requisiti impliciti: cose ovvie per te ma non scritte. Il modello non le indovina, le sostituisce con convenzioni generiche.
• Calcoli numerici precisi: aritmetica complessa senza tool esterni, conteggio esatto di elementi, manipolazione di grandi tabelle.

Ragione: il modello prevede il prossimo token plausibile, non verifica fatti. Quando i fatti contano, serve verifica esterna.

3. Plausibilità ≠ correttezza

Il problema più subdolo: un LLM produce sempre output con tono sicuro, sintassi pulita e struttura professionale. La forma è quasi sempre buona. La sostanza no. Un codice elegante può:

• chiamare una funzione che non esiste in quella libreria;
• usare un’opzione presente in v3 quando tu hai v5;
• gestire l’errore in modo che lo nasconde invece di farlo emergere;
• scegliere un’architettura plausibile ma sbagliata per il tuo contesto.

Antidoto: non leggere l’output come “spiegazione”, leggerlo come “ipotesi da verificare”. Esegui, leggi log, consulta doc ufficiale, controlla versione. La verifica non è opzionale: è parte del workflow.

Procedura pratica

Prima di accettare output generato:

1. Esiste davvero? Verifica import, funzioni, opzioni nella documentazione ufficiale della versione che usi.
2. Versione corretta? Modello potrebbe usare API di una versione diversa. Controlla package.json, requirements.txt, lockfile.
3. Edge case coperti? Input vuoto, null, valore massimo, errore di rete, utente non autenticato.
4. Sicurezza minima? Validazione server, query parametrizzate, escape output, segreti non hardcoded.
5. Esegue? Comando che dimostra il comportamento, non la frase “dovrebbe funzionare”.

Laboratorio guidato

Stesso prompt, tre richieste, stesso modello, conversazioni separate. Esempio prompt: “Implementa autenticazione email/password in [tuo stack] con sessione persistente.”

Per ogni risposta annota:

• librerie/funzioni proposte → verifica esistenza nella doc;
• versione assunta → confronta con la tua;
• sicurezza: password hash con quale algoritmo? sessione dove? cookie con quali flag?
• edge case dichiarati esplicitamente vs ignorati;
• assunzioni implicite (es. “userai PostgreSQL” senza che tu l’abbia detto).

Cerca incongruenze fra le tre risposte. Le incongruenze sono il sintomo: il modello sceglie variabili a caso fra opzioni plausibili.

Output atteso

Una checklist personale dei “segnali di allarme” da consultare prima di accettare codice generato. Esempio: import non visto prima → verifica; opzione di config sconosciuta → verifica; gestione password → verifica algoritmo; errore catchato e ignorato → riformula richiesta. Tienila accanto alla tastiera.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: sviluppare aspettative realistiche sulle capacità dell’AI, evitando sia entusiasmo cieco sia sfiducia generica. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Punti forti: trasformare testo in struttura, generare boilerplate, spiegare codice, proporre alternative, sintetizzare errori.
• Punti deboli: dettagli aggiornati, librerie inesistenti, sicurezza, casi limite, coerenza su contesti lunghi, requisiti impliciti.
• Il concetto di plausibilità: un output può sembrare professionale e contenere errori profondi.

3. Applicazione: svolgi il laboratorio: chiedere allo stesso modello tre varianti di soluzione e cercare deliberatamente incongruenze, omissioni e assunzioni non dichiarate. L’output da ottenere è: una checklist personale dei segnali di allarme da usare prima di accettare codice generato.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• so spiegare in due frasi come funziona un LLM (predittore di token, non motore di verità);
• ho almeno tre esempi vissuti di output plausibili ma sbagliati;
• ho una procedura concreta per verificare codice prima di mergiarlo;
• non confondo più “tono sicuro” con “informazione corretta”.

Errori comuni

Trattare l’LLM come un esperto. Non è un esperto: è un’interpolazione statistica di esperti. Quando i tuoi dati specifici escono dalla distribuzione del training, sbaglia.

Non chiedere mai “non lo so”. Modelli moderni con buon prompting possono ammettere incertezza, ma vanno spinti. Domande tipo “quanta confidenza hai? quali assunzioni stai facendo?” aiutano.

Fidarsi dei numeri. Se l’output contiene calcoli, conteggi, statistiche: verifica a parte. Modelli senza tool integrati sbagliano aritmetica banale con frequenza non trascurabile.

Confondere coerenza interna con correttezza esterna. Un’output può essere internamente coerente (struttura logica impeccabile) e completamente scollegato dalla realtà del tuo progetto.

Prompt di lavoro

Devo [task]. Prima di scrivere codice:

1. Quali assunzioni stai facendo su versioni librerie, stack, contesto?
2. Quali parti di questo task sono "pattern noto" (alta confidenza) e quali "scelte di progetto" (bassa confidenza)?
3. Quali edge case andrebbero gestiti che spesso vengono dimenticati?
4. Quali rischi di sicurezza/privacy sono tipici per questo tipo di feature?
5. Cosa NON sai con certezza e mi consigli di verificare manualmente?

Rispondi solo a queste 5 domande. Non scrivere ancora codice.

Esercizio finale

Prendi un output generato in passato che ti era sembrato buono. Rileggilo con la checklist. Trovi qualcosa che non avevi notato? Spesso sì: errori di versione, edge case, scelte implicite. Quel “qualcosa” è la differenza fra usare un LLM e farsi usare da un LLM.