Per quanto possa sembrare strano a molti, il primo lancio di ChatGPT — quello che ha dato il via a ciò che oggi chiamiamo l’AI boom — è avvenuto meno di quattro anni fa. Da allora, la maggior parte di noi ha assistito a un cambiamento radicale nel modo di lavorare, in una grande varietà di professioni.
Lo sviluppo software è stato uno dei campi più colpiti, e le reazioni sono state comprensibilmente contrastanti. Le prime preoccupazioni hanno riguardato il futuro del lavoro e parecchi si sono chiesti: gli sviluppatori diventeranno superflui? Personalmente non credo che andra’ così. In tutte le grandi rivoluzioni della storia, gli esseri umani non sono mai diventati superflui: si sono semplicemente adattati, e così faranno anche gli sviluppatori. Ma come avviene in ogni processo di cambiamento, i vecchi modi di fare le cose scompaiono per fare spazio ai nuovi. Il processo può essere doloroso perché porta con sé una forma di resistenza, un’inerzia nel cambiare il modo in cui si lavora e il modo in cui si pensa.
Per superare questa resistenza, credo sia importante avere in mente un’idea chiara di come un sistema agentico funzioni in modo astratto, in quanto permette di capire cosa un’agente puo’ e non puo’ fare, e quali sono le pratiche migliori per sfruttare al meglio tutte le sue potenzialita’. In questo post voglio condividere la mia immagine mentale degli agenti e le abitudini pratiche che ne derivano. Voglio precisare che qui condivido un mio modo di pensare ai sistemi agentici: potrebbe non essere l’unico modo, né il modo giusto, ma avere in mente un’astrazione chiara ha sicuramente reso più semplice il mio lavoro.
Quanto segue si basa su alcune idee rese popolari nel 2025 da Andrej Karpathy.
Un modello mentale per i sistemi agentici
Probabilmente conosciamo tutti i principali componenti hardware di un computer. Al cuore di un computer c’è l’unità di elaborazione, ovvero la CPU. La CPU è il luogo in cui avviene la computazione — dove i bit di informazione vengono elaborati. Tutti gli altri componenti sono costruiti attorno ad essa: la RAM, l’hard disk, la tastiera, il display. Questi componenti fanno parte dell’hardware, che è il substrato in cui vive la computazione. Ma l’hardware da solo non specifica che cosa calcolare; per questo serve il software.
Sul versante software, il Sistema Operativo (OS) orchestra il flusso di bit dalle sorgenti esterne (l’hard disk, gli input da tastiera, e così via) attraverso la CPU, e di ritorno verso il display, o qualsiasi altro output. Ma non specifica ancora come questa informazione debba essere elaborata. Quest’ultimo passaggio — quello critico per la risoluzione di un problema specifico — è definito in un programma: un insieme di istruzioni che stabilisce come i bit di informazione devono essere elaborati per un determinato compito.
A questo punto, se smettiamo di pensare a «bit» di informazione e iniziamo a pensare a «token» di informazione — ovvero al testo scritto — salta agli occhi che un sistema agentico opera secondo uno schema concettuale molto simile. La seguente tabella riassume l’analogia.
| Livello | Equivalente nel coding agent |
|---|---|
| CPU | L’LLM — processore di linguaggio naturale |
| (nessun equivalente) | L’essere umano — co-processore affiancato all’LLM |
| RAM | Context window |
| OS | L’harness dell’agente |
| Programma | Il task iniziale (prima richiesta dell’utente) |
| Programma installato | Una skill (sottoprogramma) |
| Runtime | La sessione (contesto di input) |
L’OS è analogo all’harness dell’agente. Si puo’ pensare all’harness come al codice TypeScript o Python che gestisce le sessioni e orchestra l’esecuzione dei tools. Spingendoci oltre, si puo’ pensare al context window del modello come alla RAM, e a operazioni come la compressione del contesto — che fanno parte dell’harness dell’agente — come analoghe a un OS che libera RAM quando la capacità massima è vicina. Ma è nei paralleli tra programma, sottoprogrammi, runtime e CPU che l’analogia diventa più interessante.
Il programma, il runtime e la CPU che parla linguaggio naturale
In un computer tradizionale, il programma è un insieme fisso di istruzioni scritte prima dell’esecuzione. Queste istruzioni possono anche implicare che durante l’esecuzione vengano richiamati altri sottoprogrammi per svolgere operazioni specifiche. Il runtime è lo stato che si accumula mentre il programma è in esecuzione.
In un sistema agentico, il programma è il task iniziale — il primo prompt dell’utente, oppure il task che un agente di livello superiore assegna a un subagente. Un sottoprogramma corrisponde a una skill: un insieme di istruzioni già scritte che può essere invocato durante l’esecuzione del programma principale per una specifica operazione. Il runtime è la sessione — il contesto di input che si accumula nel context window mentre il programma (il task) viene eseguito.
E la CPU? In un computer tradizionale, la CPU esegue operazioni binarie deterministicamente. L’LLM occupa la posizione della CPU — ma non è una CPU. È un processore di linguaggio naturale. Questa differenza è importante: la CPU parla binario, l’LLM elabora linguaggio naturale — lo stesso mezzo che usa l’essere umano. Questo rende il confine tra uomo e macchina molto più permeabile: il “cervello” della macchina parla “umano” adesso, e quindi l’uomo può contribuire al runtime in modo diretto, molto più facilmente che con una CPU, senza che una specifica formale si frapponga tra lui e l’esecuzione.
Inoltre, la lingua condivisa implica che il programma può essere guidato durante l’esecuzione. Ogni messaggio plasma il contesto, e quindi l’output, di ogni turno successivo. L’uomo non è più al di fuori dell’esecuzione — è un co-processore del runtime, affiancato all’LLM.
Come ottimizzare un coding agent: tre abitudini, un principio
1. Inizia parlando, non agendo
Lavorare con un coding agent non significa configurare una macchina. Significa avviare una sessione collaborativa con un “peer-processor”. I primi turni stabiliscono il contesto che plasma la distribuzione di probabilità di tutto ciò che segue: come viene inquadrato il problema, quali vincoli vengono chiariti, quali assunzioni vengono rese esplicite.
Come regola generale, la prima mossa in una sessione dovrebbe essere una domanda, non un’istruzione. Qualche minuto di esplorazione prima del primo comando spesso produce risultati migliori. A questo proposito, trovo molto utile grill-with-docs, una skill per Claude Code creata da Matt Pocock, che istruisce l’agente a continuare a fare domande finche’ non e’ stato stabilito un chiaro allineamento fra l’essere umano e l’agente stesso.
2. Riconosci quando la sessione è andata per la tangente
L’esplorazione è naturale e spesso produttiva, ma può anche essere dannosa se si spinge troppo oltre, cioè se perde di vista il task principale. Porre una domanda correlata o considerare un approccio diverso può essere utile, ma a volte la conversazione va per la tangente, il che nella nostra analogia significa che il sistema inizia a eseguire un nuovo programma principale, non correlato a quello iniziale, nello stesso runtime. Anche se si riesce a tornare alla task principale, il suo contenuto resta nel contesto di input, saturando la context window e confondendo l’agente.
La soluzione è una sessione nuova. Quando riconosci la tangente, qualcosa come handoff, un’altra skill di Matt Pocock, puo’ tornare utile. Comprime la sessione corrente in un riassunto mirato da cui una nuova sessione può ripartire immediatamente. Nella nostra analogia, è un sottoprogramma autonomo che crea il programma principale da eseguire in un nuovo runtime per sviluppare l’idea emersa nella tangente, mentre il runtime originale può proseguire concentrato sul programma originale.
3. Si puo’ delegare il pensiero, ma non la comprensione
Il paradigma specs-to-code — scrivere una specifica completa, consegnarla e lasciare che l’agente costruisca tutto in autonomia — cerca di ripristinare il confine originario tra l’uomo e la macchina: l’uomo come autore all’esterno, l’agente come esecutore all’interno. Può funzionare, ma in ogni caso si perde il vantaggio di poter guidare l’esecuzione in corso d’opera. L’essere umano non è più un co-processore — aspetta l’output, che comunque dovrà poi essere revisionato e compreso, e tutto in una volta sola.
L’alternativa sono i passi incrementali: scomporre il problema in piccole unità, completarne una alla volta, revisionare ciascuna prima di passare alla successiva. Ricorda che l’LLM può andare per la tangente esattamente come può farlo l’essere umano. La revisione incrementale è l’unico modo per intercettare queste deviazioni prima che il loro contenuto si accumuli nel contesto di input e si amplifichi. Comprendere ogni passo prima di procedere significa restare dentro l’esecuzione.
«Si puo’ delegare il pensiero, ma non la comprensione» descrive perfettamente la causa di ciò che può andare storto quando un coding agent viene trattato troppo come un contractor autonomo anziché come un runtime collaborativo.
Conclusione
L’architettura di un sistema agentico è simile a quella di un computer tradizionale, ma con una CPU che parla la lingua degli esseri umani. L’LLM è la CPU, la sessione è il runtime e l’essere umano e’ un co-processore. L’agente puo’ essere programmato in linguaggio naturale ed e’ possibile interagire con il runtime agendo direttamente sulla CPU. Da questa visione discendono naturalmente tre abitudini pratiche: inizia stabilendo il contesto prima di impartire comandi, riconosci le tangenti prima che si amplifichino e resta dentro l’esecuzione attraverso la revisione incrementale. Si puo’ delegare il pensiero, ma non la comprensione.
Autore: Giovanni Vacanti, Data Scientist @ Bitrock