Immagina di chiedere a un collega esperto di aiutarti a sistemare un bug nel tuo progetto. Se quel collega può solo leggere i frammenti di codice che gli mostri tu, potrà darti consigli utili, ma il lavoro vero lo farai comunque tu. Se invece quel collega può aprire il progetto sul suo computer, eseguire i test, leggere i file, esplorare la struttura del codice e verificare da solo se le modifiche funzionano — allora stai lavorando con qualcuno di qualità completamente diversa. Questa è, in sostanza, la differenza tra usare un LLM in una chat e usarlo dentro un agente di codice.
Di cosa stiamo parlando
Negli ultimi mesi si fa sempre più spesso i nomi di strumenti come Claude Code (di Anthropic) o Codex CLI (di OpenAI). Sono entrambi esempi di quella categoria che in inglese viene chiamata coding agents, ovvero agenti di programmazione. Non si tratta semplicemente di chatbot più bravi a scrivere codice: sono sistemi che avvolgono un modello linguistico in un’infrastruttura operativa, spesso definita agentic harness, che trasforma il modello da generatore di testo a sistema capace di agire in modo autonomo all’interno di un ambiente reale.
È una distinzione importante, e vale la pena capirla bene, perché spiega molto di quello che stiamo vedendo succedere nel mondo dell’IA applicata.
Perché la “chat” non basta
Un modello linguistico usato in una classica interfaccia di chat è potente, ma strutturalmente limitato. Risponde a ciò che gli viene mostrato, e niente di più. Se vuoi che analizzi il tuo codice, devi incollarlo tu. Se vuoi che esegua un test, devi farlo tu e riportargli l’output. Il modello non “vede” il tuo progetto: vede solo quello che tu gli descrivi, e ogni conversazione riparte sostanzialmente da zero.
Un agente di codice funziona in modo radicalmente diverso. Ha accesso diretto al repository, conosce la struttura dei file, sa su quale ramo Git si trova il progetto, può leggere la documentazione esistente per capire come i test vengono eseguiti. Non aspetta che tu gli passi le informazioni: le va a recuperare autonomamente, le usa, e reintroduce i risultati nel suo ciclo decisionale.
Cosa cambia, concretamente
La differenza non sta solo nella comodità. Sta nella qualità del ragionamento che il sistema riesce a produrre, e in questo i meccanismi interni dell’infrastruttura agentiva giocano un ruolo fondamentale.
Uno dei problemi classici delle sessioni di lavoro lunghe con un LLM è il cosiddetto context overflow: il modello ha una finestra di contesto finita, e in sessioni complesse quella finestra si riempie rapidamente di log di errore, letture ripetute degli stessi file, output ridondanti. Un agente ben costruito gestisce questo problema in modo attivo: accorcia gli output voluminosi (clipping), elimina le letture duplicate (deduplicazione), riassume gli eventi passati mantenendo il dettaglio solo per quelli più recenti e rilevanti. È un po’ come un professionista esperto che sa cosa tenere sul tavolo di lavoro e cosa mettere in un cassetto.
C’è poi la questione della memoria strutturata. Mentre la cronologia di una chat è lineare e piatta, un agente separa lo stato di lavoro in due livelli distinti: una memoria operativa aggiornata continuamente con ciò che conta nel compito corrente, e una trascrizione completa di ogni azione svolta, che permette di riprendere una sessione interrotta senza perdere il filo. Per chi lavora su progetti complessi e distribuiti nel tempo, questa è una differenza che si sente.
Un altro elemento di efficienza è la cache dei prompt: l’agente costruisce un prefisso stabile — istruzioni generali, descrizione degli strumenti disponibili, riepilogo del contesto di lavoro — e lo mantiene in cache, così da non doverlo ricostruire da zero a ogni nuova richiesta. Il risultato è una maggiore velocità e un costo computazionale inferiore.
Infine, c’è la possibilità di delegare ad agenti secondari. Quando un compito può essere parallelizzato — ad esempio, cercare una definizione di funzione mentre si analizza un fallimento di test — l’agente principale può istanziare dei sub-agenti specializzati per quei compiti specifici, senza appesantire il flusso di controllo principale. È un modo di scalare la complessità che ricorda molto l’organizzazione del lavoro in un team umano.
Un esempio concreto: costruire un’applicazione Python con un LLM locale
Per rendere tutto questo meno astratto, vale la pena raccontare un’esperienza diretta. Ho usato Claude Code per sviluppare da zero un’applicazione desktop in Python: una utility per l’importazione e l’anteprima di dati, con un modulo di analisi AI integrato basato su un modello linguistico eseguito in locale.
L’applicazione è tutt’altro che banale: supera le 2.000 righe di codice e include funzionalità che richiedono coerenza architetturale su tutto il progetto. Ne scriverò in dettaglio in un prossimo articolo. Quello che mi interessa sottolineare qui è il modo in cui lo sviluppo è avvenuto.
In una sessione di chat tradizionale, un progetto del genere avrebbe richiesto un continuo copia-incolla: il codice esistente da rincollare ad ogni nuova richiesta, i messaggi di errore da ricopiare a mano, il contesto del progetto da rispiegare ogni volta. Il modello avrebbe risposto bene alle singole domande, ma senza mai avere una visione d’insieme del sistema in costruzione.
Lavorando invece con un agente di codice, il contesto del progetto rimaneva vivo tra una sessione e l’altra. Quando emergeva un errore, l’agente poteva analizzarlo, collegarlo alla parte di codice rilevante e proporre una soluzione coerente con il resto dell’applicazione — non una patch isolata. Il risultato è stato un flusso di lavoro molto più fluido, non perché il modello fosse “più intelligente”, ma perché l’infrastruttura attorno a lui permetteva di lavorare con il progetto invece che intorno ad esso.
La vera lezione
C’è una riflessione più ampia che vale la pena portare a casa da tutto questo. Quando un sistema come Claude Code o Codex sembra “più intelligente” rispetto allo stesso modello usato in una chat, non è necessariamente perché il modello sia diverso. È perché l’infrastruttura che lo circonda è migliore. Il modo in cui vengono gestiti il contesto, gli strumenti, la memoria e la struttura del flusso di lavoro incide sull’output finale tanto quanto le capacità del modello stesso.
Questo ridimensiona una narrativa che sentiamo spesso: quella per cui tutto ciò che conta è avere il modello più potente. In realtà, molta della “intelligenza” che percepiamo nei sistemi agentici moderni è intelligenza di sistema, non solo intelligenza di modello. È un punto che chi lavora con l’IA applicata — in ambito aziendale, consulenziale, o semplicemente per automatizzare il proprio lavoro — dovrebbe tenere ben presente.
Gli agenti di codice sono il caso più visibile di questo principio. Ma lo stesso vale, sempre di più, per qualunque sistema LLM serio: quello che sta intorno al modello conta quanto il modello stesso.
