Prima di Claude Code: AI, LLM, agenti e strumenti

La mappa: AI, machine learning, LLM e Claude Code

Se parti da zero, la prima difficoltà non è tecnica: è capire che parole molto simili indicano cose diverse. Mettiamo ordine adesso, così più avanti saprai sempre chi sta producendo una risposta e chi, invece, sta davvero agendo sui tuoi file.

Intelligenza artificiale, o AI, è un nome ampio per sistemi che svolgono compiti associati all’intelligenza umana, come riconoscere immagini, prevedere valori o produrre testo. Il machine learning è una famiglia di tecniche con cui un sistema apprende regolarità da molti esempi invece di ricevere una regola scritta per ogni caso. L’AI generativa è la parte che crea nuovi contenuti, come testo, immagini, audio o codice.

Un Large Language Model, abbreviato LLM, è un modello generativo addestrato su grandi quantità di testo e codice. Claude è una famiglia di LLM. Claude Code è un’applicazione che usa un modello Claude e aggiunge istruzioni operative, accesso controllato a strumenti e un ciclo di verifica per lavorare su un progetto. Questi nomi non sono sinonimi: Claude Code collega il modello a capacità operative che il solo LLM non possiede.

1. Parti dall’insieme più ampio: AI.
2. Dentro trovi il machine learning e, fra i suoi usi, l’AI generativa.
3. Un LLM è un tipo di modello generativo specializzato nel linguaggio.
4. Claude è una famiglia di LLM; Claude Code li collega a un ambiente di lavoro.

Come nasce una risposta: token, probabilità e limiti

Una risposta fluida può sembrare il risultato di un ragionamento infallibile. In realtà nasce da molte piccole previsioni successive. Capire questo passaggio evita l’errore più comune: scambiare una frase ben scritta per un fatto già verificato.

Un LLM non cerca una risposta completa in un archivio. Riceve una sequenza, la divide in unità chiamate token e stima quale token sia plausibile dopo quelli già presenti. Un token può essere una parola breve, una parte di parola, un segno o uno spazio: non coincide sempre con una parola. La risposta nasce un token alla volta, ripetendo la previsione molte volte.

Durante l’addestramento il modello ha appreso schemi statistici del linguaggio e del codice. Questo gli permette di spiegare, riassumere e proporre soluzioni, ma non gli dà automaticamente coscienza, intenzioni o accesso ai fatti aggiornati. Una frase molto sicura può ancora essere sbagliata. Piccole differenze nella richiesta o nella generazione possono inoltre produrre risposte diverse.

Il modello è quindi utile come motore di interpretazione e proposta, non come fonte infallibile. Per un compito reale devi fornirgli il contesto corretto e confrontare l’output con prove esterne: file esistenti, documentazione attendibile, test o osservazioni dirette.

Prompt, contesto, finestra e memoria non sono la stessa cosa

Prompt, contesto e memoria vengono spesso usati come se fossero la stessa cosa. Non lo sono. Il prompt è la richiesta che fai adesso; il contesto è ciò che il modello può vedere adesso; la memoria è un modo per conservare e recuperare alcune informazioni nel tempo.

Il prompt è ciò che chiedi in un dato momento. Il contesto è l’insieme delle informazioni che il modello può usare mentre genera la risposta: la conversazione disponibile, le istruzioni, i file forniti e i risultati degli strumenti. La finestra di contesto è il limite di capienza di questo insieme. Quando il lavoro cresce, alcune parti possono essere riassunte, escluse o diventare meno rilevanti.

La memoria è informazione conservata e recuperata fra momenti o sessioni; non è l’intera finestra di contesto e non significa che il modello ricordi tutto. Anche un dato salvato può essere incompleto o non essere richiamato. Più avanti userai file di istruzioni e meccanismi di memoria, ma dovrai sempre controllare che la regola importante sia davvero presente nel contesto corrente.

Un buon contesto non è il più lungo possibile. Contiene i fatti che cambiano una decisione: obiettivo, stato reale, vincoli, esempi pertinenti e criterio di successo. Informazioni vecchie o contraddittorie possono peggiorare la risposta quanto le informazioni mancanti.

Allucinazioni, incertezza ed evidenze

Quando un modello inventa un nome di file o una funzione, non sta cercando di ingannarti: sta completando un vuoto con una continuazione plausibile. Per te, però, l’effetto pratico è lo stesso di un’informazione falsa. Serve quindi un metodo per riconoscerla prima che guidi una modifica.

Si parla di allucinazione quando il modello produce un’affermazione plausibile ma non sostenuta dai fatti: può inventare un file, citare una funzione che non esiste o descrivere un test mai eseguito. Non è una bugia intenzionale; è l’effetto di generare la continuazione linguisticamente plausibile senza una verifica sufficiente.

Riduci il rischio chiedendo al sistema di osservare prima di concludere. Se parla di un progetto, deve indicare i file reali che ha letto. Se propone una modifica, deve mostrare il diff. Se dichiara che il comportamento funziona, deve eseguire un controllo pertinente e riportarne l’esito. Una prova non rende vero tutto il resto: deve sostenere esattamente la conclusione dichiarata.

1. Separa ciò che è stato osservato da ciò che è soltanto ipotizzato.
2. Chiedi la fonte o l’artefatto che sostiene la conclusione.
3. Controlla che il test misuri davvero il comportamento promesso.
4. Mantieni espliciti dubbi, limiti e verifiche non eseguite.

Da chatbot ad agente: chi decide e chi agisce

Un agente non è semplicemente un chatbot che scrive di più. È un sistema che può osservare un risultato, scegliere un passo, usare uno strumento e decidere cosa fare dopo. La parte decisiva è il ciclo, non la quantità di autonomia dichiarata.

In una chat, il ciclo tipico è domanda e risposta. Un agente riceve invece un obiettivo, interpreta il contesto, sceglie un’azione, usa uno strumento, osserva il risultato e decide se fermarsi o continuare. Possiamo descriverlo così: agente = LLM + istruzioni + contesto + strumenti + feedback + permessi + condizione di arresto.

Il modello propone il passo successivo; lo strumento compie l’azione concreta. Leggere un file, eseguire un test o cercare nel web non avviene per il solo fatto che il modello lo descriva: serve una capacità collegata e autorizzata. Il risultato dello strumento torna nel contesto, così l’agente può correggere il piano.

Autonomia non significa assenza di controllo. Sei tu a definire l’obiettivo, la portata, i checkpoint e quando un risultato può essere accettato. Un agente affidabile deve anche sapersi fermare quando manca un permesso, incontra una sorpresa o non possiede una prova adeguata.

Strumenti, permessi e confini di sicurezza

Un permesso non è un pulsante burocratico da accettare per proseguire. È il confine entro cui un errore può produrre effetti reali. Prima di concederlo devi capire azione, destinazione e possibilità di recupero.

Uno strumento è un ponte verso un’azione: può leggere una cartella, modificare un file, lanciare un comando o contattare un servizio. Un permesso stabilisce quali azioni sono consentite. Autorizzare uno strumento non dimostra però che l’azione sia corretta, e l’approvazione di una persona non sostituisce la verifica del risultato.

Concedi il minimo necessario. Per capire un progetto basta iniziare in sola lettura; per correggere un file locale serve una scrittura limitata alla cartella del progetto; per pubblicare, cancellare o inviare dati all’esterno serve un checkpoint esplicito. Più l’azione è ampia, irreversibile o esterna, più forte deve essere il controllo umano.

Prima di approvare, leggi l’azione proposta in termini concreti: quale comando, quali file, quale destinazione e quale effetto. Se non li comprendi, chiedi una spiegazione o una simulazione. Fermarsi non è un fallimento: è il comportamento corretto quando l’autorità o le informazioni non bastano.

1. Identifica l’azione reale dietro la richiesta di permesso.
2. Limita il permesso alla cartella, al comando e al tempo necessari.
3. Prevedi una conferma separata per azioni remote o irreversibili.
4. Controlla l’esito con una prova indipendente dall’approvazione.

File, cartelle, terminale e Git: il luogo di lavoro

Il terminale può sembrare ostile perché risponde con testo asciutto, ma il suo comportamento è regolare: esegue un comando in una cartella e restituisce un risultato. Git aggiunge una cronologia delle modifiche. Insieme ti permettono di vedere cosa è successo, invece di affidarti alla memoria.

Un progetto è una cartella che contiene file e, spesso, altre cartelle. Un percorso indica dove si trova un elemento. Il terminale è un’interfaccia testuale: mostra un prompt, riceve un comando, lo esegue nella cartella corrente e restituisce output più uno stato di successo o errore. Non devi memorizzare molti comandi; devi sapere dove sei e leggere cosa è accaduto.

Git registra la storia dei file di un progetto. `git status` distingue file non tracciati, modifiche in preparazione e modifiche ancora fuori dal prossimo commit. Per impostazione predefinita, `git diff` mostra le modifiche non preparate dei file già tracciati; `git diff --staged` mostra quelle preparate. Un commit registra intenzionalmente lo stato preparato con un messaggio. Git non è automaticamente un backup completo: prima di ripristinare o cancellare, controlla sempre lo stato reale.

Per la prima missione ti bastano quattro concetti: cartella corrente, file modificato, differenza osservabile e controllo eseguito. L’agente può digitare o proporre comandi, ma l’output appartiene al processo reale. Se il comando fallisce, quel fallimento è informazione da leggere, non testo da nascondere.

La prima missione guidata, dall’osservazione alla prova

Ora uniamo i pezzi in una missione minuscola. Lo scopo non è dimostrare che l’agente può fare molto; è dimostrare che tu sai mantenere visibili obiettivo, autorizzazione, cambiamento e prova dall’inizio alla fine.

In questa simulazione guidata, una piccola app locale chiamata Task Notes deve cambiare una sola etichetta: da «Le mie cose» a «Le mie attività». Non devi possedere l’app né eseguire comandi. Usi lo scenario per provare le decisioni in ordine; nel Modulo 2 applicherai lo stesso metodo a un ambiente reale.

La sequenza inizia con una lettura senza modifiche. Ti fai indicare dove compare il testo e richiedi un piano di una riga. Concedi una scrittura limitata, immagini di controllare il diff e scegli una prova pertinente. Accetti il lavoro soltanto se file, differenza e comportamento raccontano la stessa storia.

1. Nello scenario, colloca la missione nella cartella Task Notes e identifica i file disponibili.
2. Formula la richiesta di sola lettura: «Trova dove appare “Le mie cose”. Non modificare nulla».
3. Prevedi di confrontare la risposta con il file indicato prima di autorizzare cambiamenti.
4. Formula una modifica limitata a quella etichetta e richiedi un piano breve.
5. Scegli il permesso minimo: scrittura nella sola cartella del progetto locale.
6. Richiedi come evidenza un `git diff` limitato a ciò che hai chiesto.
7. Scegli un test o un controllo del risultato visibile come seconda prova.
8. Definisci il criterio: compare «Le mie attività» e il resto continua a funzionare.
9. Stabilisci lo stop: davanti a un cambiamento inatteso, non proseguire e chiedi spiegazione.