Premesso, questa è una proposta di analisi, il paper lo trovate su Academia cliccando qui

Analizziamo perché strumenti come Claude Code o Gemini CLI a volte sembrano geni e altre volte si bloccano in loop infiniti. Spoiler: il problema non è il modello LLM, ma l’architettura che lo guida.

L’illusione della perfezione

Tutti abbiamo provato quella sensazione: chiedi a un AI Coding Agent di implementare una funzionalità complessa. L’agente risponde con una sicurezza disarmante, analizza i file correttamente e sembra aver capito tutto al 100%. Poi, però, inizia a scrivere il codice e… crash. Oppure, peggio, entra in un loop: legge lo stesso file dieci volte, prova la stessa soluzione sbagliata tre volte e infine dichiara di aver finito, lasciandoti un bug che un programmatore junior avrebbe evitato in due minuti.

Cosa sta succedendo? La risposta intuitiva è: “L’IA non è ancora abbastanza intelligente”.

In realtà, i dati ci dicono che non è così.

Il “collo di bottiglia” non è l’intelligenza

Nel mio ultimo lavoro di ricerca, ho analizzato le inefficienze di questi sistemi. Un dato sorprendente emerge da studi recenti: circa il 67% dei bug in questi strumenti è di natura funzionale. Ma la cosa più interessante è dove si concentrano questi errori: non nella comprensione del linguaggio (che è altissima), ma nell’orchestrazione.

In parole semplici: l’IA sa cosa fare (l’intento è chiaro), ma non sa come gestire gli strumenti a sua disposizione in modo efficiente. È come avere un architetto di fama mondiale che però deve costruire il palazzo consegnando un solo mattone alla volta, camminando avanti e indietro per chilometri tra il magazzino e il cantiere.

I tre “peccati capitali” dell’architettura attuale

Perché questi strumenti sono così inefficienti? Ho identificato tre problemi strutturali:

1. L’ossessione per la sequenzialità (Le “Bolle” nella Pipeline)

Gli agenti attuali tendono a lavorare in modo rigidamente sequenziale. Se devono interrogare un database per 10 utenti diversi, faranno 10 query separate. In informatica, questo è un errore grossolano: si dovrebbe usare una singola query ottimizzata (una JOIN o un operatore batch).

Questo crea le cosiddette “Pipeline Bubbles”: mentre la CPU esegue lentamente queste piccole operazioni ripetitive, la GPU (il “cervello” costoso e potente dell’IA) resta inattiva, a girare a vuoto, aspettando che arrivino i dati. È un enorme spreco di risorse e di tempo.

2. L’amnesia strategica (La gestione della Cache)

Per evitare che l’IA inizi a “allucinare” (ovvero a inventare cose basandosi su errori precedenti), molti sviluppatori di framework impostano una pulizia aggressiva della memoria a breve termine (la cosiddetta KV-cache). È un’euristica difensiva: “Cancelliamo tutto ogni tanto, così l’IA ricomincia da zero e non si confonde”. Il problema? Questo costringe l’agente a rigenerare continuamente il contesto, portando a una frammentazione del lavoro e a una perdita di memoria operativa che rende il processo lentissimo e a volte incoerente.

3. Il caos dei Multi-Agenti (Quando “troppi cuochi” guastano il codice)

Quando usiamo sistemi con più agenti che collaborano, il problema si amplifica. Senza un piano globale (che in termini tecnici chiamiamo DAG – Grafo Aciclico Diretto), gli agenti iniziano a parlare a vuoto:

• Ripetizione dei passaggi: L’Agente A fa una cosa, l’Agente B non se ne accorge e la rifà.
• Disallineamento: L’Agente A pensa che l’obiettivo sia X, l’Agente B pensa che sia Y.
• Verifiche superficiali: L’agente finale dice “Il codice compila, quindi funziona!”, ignorando completamente che la funzione non risolve affatto il problema originale.

Come uscirne? La strada verso agenti affidabili

Se vogliamo passare da “prototipi divertenti” a “strumenti di produzione”, dobbiamo smettere di potenziare solo il modello (aggiungendo più parametri o dati) e iniziare a progettare meglio il sistema.

Le soluzioni che propongo nel mio paper sono tre:

1. Orchestrazione Intelligente (DAG-Aware): L’IA non deve solo “scrivere”, ma deve prima “compilare” un piano di lavoro ottimizzato, unendo le richieste simili e parallelizzando i compiti.
2. Verifica Multi-Livello: Non basta che il codice “compili”. Serve un sistema di revisione che controlli se l’output è allineato agli obiettivi di business iniziali.
3. Gestione dell’Incertezza: Invece di tirare a indovinare quando non ha dati (causando allucinazioni), l’agente deve avere un “sensore di confidenza”: se la certezza scende sotto una soglia, deve fermarsi e chiedere chiarimenti all’utente.

In conclusione

L’automazione del software non dipenderà solo da quanto diventeranno “intelligenti” i modelli, ma da quanto saremo capaci di applicare i classici principi di ingegneria dei sistemi distribuiti e di ottimizzazione delle query all’intelligenza artificiale.

L’IA ha già il cervello; ora dobbiamo costruirle un sistema nervoso che funzioni.