Cosa l’LLM non sa: aggiornamento, dominio, repo

Un LLM può parlare bene di molte tecnologie, ma non possiede automaticamente informazioni aggiornate, regole interne del tuo dominio o conoscenza della tua codebase. Ogni volta che il prompt presuppone una di queste conoscenze, stai chiedendo al modello di colmare un vuoto. A volte lo farà chiedendo chiarimenti. A volte lo farà inventando.

Perché questa lezione conta

Il problema non è che il modello “non sa abbastanza”. Il problema è che spesso non sa di non sapere. Se gli chiedi una risposta su una libreria appena cambiata, una policy aziendale o una funzione privata del progetto, può produrre una risposta plausibile invece di fermarsi.

Questa lezione ti insegna a riconoscere tre vuoti di conoscenza e a scegliere come riempirli: documentazione aggiornata, contesto di dominio e contesto di repo.

Vuoto 1: aggiornamento

Le API cambiano, le librerie rilasciano versioni nuove, vulnerabilità e best practice si aggiornano. Un modello può conoscere pattern generali ma essere impreciso sui dettagli correnti.

Quando il task dipende da informazioni recenti, devi:

• portare documentazione ufficiale o link verificabili;
• chiedere di distinguere conoscenza certa e punti da verificare;
• eseguire comandi locali quando possibile;
• evitare prompt che chiedono “l’ultima versione” senza fonte.

Esempio:

Usa solo la documentazione allegata per valutare questa API.
Se una funzione non compare nel testo fornito, non assumerne l'esistenza.
Restituisci una sezione "da verificare nella documentazione ufficiale".

Vuoto 2: dominio

Il dominio è l’insieme di regole, parole e vincoli che rendono il tuo progetto diverso da un esempio generico. Può includere:

• regole di business;
• vincoli legali o privacy;
• glossario interno;
• ruoli utente;
• casi limite noti;
• decisioni di prodotto.

Se non fornisci queste informazioni, il modello userà convenzioni generiche. In un gestionale, per esempio, “utente attivo”, “prestito chiuso”, “ordine evaso” o “cliente verificato” non sono parole neutre: hanno regole.

Vuoto 3: codebase

Il modello non conosce struttura, pattern e debiti tecnici della tua repo se non glieli dai o se non può leggerli con strumenti. Questo vale anche quando il task sembra piccolo.

Per una modifica su codebase reale servono spesso:

• file coinvolti;
• punto di ingresso;
• pattern già usato;
• test esistenti;
• vincoli di build;
• cose da non toccare.

Un prompt utile non dice solo “scrivi il codice”. Dice dove deve integrarsi e come capire che non ha rotto il resto.

Esempio operativo

Prompt fragile:

Implementa la gestione dei prestiti nel modo giusto.

Prompt con vuoti esplicitati:

Devi modificare la gestione dei prestiti nel Registro laboratorio.

Contesto di dominio:
- uno strumento guasto non può essere prestato;
- un prestito chiuso non può essere chiuso di nuovo;
- lo stato "in manutenzione" blocca il prestito come "guasto".

Contesto di repo:
- regole in src/domain;
- casi d'uso in src/application;
- persistenza in src/infrastructure;
- non mettere regole di dominio nella UI.

Prima di proporre codice:
1. elenca quali file devi leggere;
2. indica quali regole sono già coperte;
3. segnala cosa manca o è ambiguo.

Laboratorio guidato

Scegli un task reale e costruisci una “mappa dei vuoti”.

Vuoto	Domanda	Fonte da fornire	Rischio se manca
Aggiornamento	Quale dettaglio può essere cambiato di recente?	docs, changelog, comando locale	API inventata o obsoleta
Dominio	Quale regola interna non è ovvia?	README, glossario, policy	soluzione generica ma sbagliata
Repo	Quale pattern va rispettato?	file, test, struttura	patch fuori stile o regressiva

Poi riscrivi il prompt includendo solo le fonti necessarie.

Output atteso

Una mappa dei vuoti di conoscenza tipici del tuo progetto, con strategia di contesto per ciascuno.

La mappa deve indicare:

• quali informazioni cambiano spesso;
• quali regole di dominio vanno sempre fornite;
• quali file descrivono l’architettura;
• quali fonti sono affidabili;
• quali domande il modello deve fare prima di procedere.

Checklist di verifica

• so distinguere conoscenza generale e conoscenza aggiornata;
• so fornire regole di dominio senza sommergere il prompt;
• so indicare file e pattern rilevanti della repo;
• so chiedere al modello di dichiarare cosa non sa;
• ho una strategia per evitare invenzioni su API, regole e codice interno.

Errori comuni

Chiedere dettagli aggiornati senza fonte. Se la risposta dipende da una versione recente, porta documentazione o verifica localmente.

Dare per ovvio il dominio. Le regole che per il team sono naturali per il modello sono solo ipotesi.

Fornire file ma non intenzione. Il codice da solo non spiega sempre perché una scelta è stata fatta.

Collegamenti

• Modulo: Fondamenti per sviluppatori — lezione 5 del corso.
• Lezione precedente: Costi, latenza, qualità: i tre vincoli reali.
• Prossimo modulo: Anatomia del prompt operativo.