Angolo di Anderson
Perché l’IA fatica a raccogliere un compito a metà

Sebbene gli agenti IA possano risolvere compiti complessi, uno studio recente indica che hanno difficoltà a continuare il lavoro iniziato da un altro, portando a sforzi duplicati, progressi più lenti e costi maggiori.
Uno dei compiti più faticosi ma essenziali nel lavorare con agenti e interfacce IA è che l’IA necessita di essere “portata a velocità” all’inizio di uno scambio, quasi in ogni caso.
Mentre modelli linguistici popolari come ChatGPT offrono alcun accesso a “memorie personalizzate persistenti”, l’implementazione è solitamente un affare aleatorio; alla fine, è solitamente più sicuro accettare lo sforzo di contestualizzare* il compito per l’IA – almeno, per evitare che l’IA “indovini” un contesto errato dal suo spazio latente addestrato .
Raccogliere la fiacca del mondo reale
La sfida precede l’IA, naturalmente; molte aziende richiedono già ai dipendenti di mantenere la documentazione riguardante i processi che sviluppano o raffinano (in parte per una maggiore fluidità di lavoro, ma anche per evitare che i dipendenti acquisiscano potere).
Tuttavia, nella pratica, è spesso solo le organizzazioni più grandi e meglio finanziate che onorano l’impegno di creare, aggiornare e mantenere la documentazione. Molto spesso, invece, i dipendenti che devono raccogliere il lavoro di altri sono affidati a un compito “di detective” che richiede loro di scoprire con cura la timeline che ha portato al lavoro abbandonato che ora hanno ricevuto.
È ovvio che una documentazione immacolata risparmierebbe giorni, settimane o addirittura mesi di lavoro – se solo fosse una proposta finanziariamente razionale.
Tuttavia, dove gli agenti IA sono gli operatori in questione, potrebbe esserci una maggiore possibilità di risolvere il problema.
Passare la mano
Questo onere di “non documentazione” è quantificato in un nuovo studio di ricerca degli Stati Uniti, che definisce il problema debito di passaggio.
Se debito tecnico è la sindrome in cui le soluzioni tecnologiche rapide e a buon mercato (e economiche) di oggi portano a soluzioni fragili o difficili da mantenere in futuro, allora debito di passaggio definisce il costo di ritrovamento – il ritrovamento forense dei passaggi di un lavoratore o entità che non è disponibile per consigliare (licenziamento ostile, troppo occupato, morto, ecc.) o altrimenti incapace di consigliare (ad esempio, un LLM che ha già eliminato il contesto che ha portato allo stato attuale del lavoro).
Il nuovo studio† – una collaborazione tra ricercatori indipendenti e affiliati all’Università statale della Georgia – si occupa del debito di passaggio come si applica agli agenti di codifica che sono incaricati di raccogliere dove un’altra sessione, persona o entità ha lasciato in un codice.
Uno degli obiettivi del lavoro è stabilire esattamente quanto sia necessaria la documentazione per ridurre il debito di passaggio e quali procedure e protocolli potrebbero essere raccomandati di adottare come pratica standard nel futuro per minimizzare il problema.
Preoccupazioni di bilancio
In un mondo ideale, si potrebbe impostare la registrazione su verboso e semplicemente fornire all’agente neofita (quello che raccoglie il compito) i log relativi al compito incompleto.
Tuttavia, analizzare tale volume di dati in dati utili sarebbe sia dispendioso in termini di tempo che di token – e inoltre porrebbe vincoli di spazio di archiviazione.
Questo è un problema di bilancio, perché l’uso di dump grezzi è dispendioso, mentre l’uso di log curati è meno confusionale, ma richiede un impegno di risorse preventivo.
Le note adeguate e dedicate sarebbero molto efficaci nel far sì che un “artista di raccolta” si metta in moto, ma al costo di un impegno di sforzo ancora maggiore – sforzo che potrebbe non essere mai necessario, se la logica del lavoro dovesse rivelarsi autoevidente, o se il lavoro venisse abbandonato o non revisionato mai più.
Gli autori del nuovo studio, intitolato Debito di passaggio: il costo di ritrovamento quando gli agenti di codifica prendono il controllo di compiti interrotti, hanno considerato tutti questi scenari e hanno adattato i modelli di compito esistenti a nuovi modi di quantificare e affrontare il debito di passaggio. Sebbene il lavoro si occupi specificamente di agenti di codifica, potrebbe comunque indicare percorsi utili per contesti IA più ampi e per le politiche di documentazione.
Gli autori affermano:
‘Il debito di passaggio si verifica quando un agente fa progressi visibili ma lascia uno stato che un successore non può prontamente continuare, come modifiche non spiegate, file di appunti, ipotesi nascoste o prove di convalida mancanti.
‘Una metrica basata solo sulla risoluzione finale non può distinguere tra il costo di ritrovamento costoso e la continuazione efficiente.
‘Due agenti predecessori possono lasciare lo stesso punto di controllo, ma i loro successori possono affrontare costi di continuazione molto diversi: uno può continuare immediatamente, mentre un altro deve spendere molte interazioni di strumenti per ritrovare l’intento da file di appunti e storia di comando incompleta.’
Metodo
Gli autori definiscono predecessore come l’agente precedente (quello che ha originato o ultimato il lavoro) e successore come l’agente attuale (quello incaricato di raccogliere il lavoro),
A sostegno di un benchmark progettato per misurare il costo di trasferimento di compiti di ingegneria del software incompleti tra agenti, 75 compiti da SWE-bench Verified sono stati convertiti in 181 scenari di passaggio, ognuno rappresentante un punto in cui il lavoro era stato interrotto e passato a un agente successore. Tre diversi modelli di successore sono stati quindi testati su 2.172 tentativi di acquisizione.
I modelli di famiglia utilizzati, e variamente mescolati in questi test di passaggio, sono stati Qwen, Gemma e Devstral.
Gli esperimenti hanno esaminato quattro livelli di informazioni ereditate: nel setting più restrittivo, il successore ha ricevuto solo lo stato del repository (effettivamente, camminando in un’area “disastrosa” non documentata). Altri setting hanno fornito contesti sempre più dettagliati, da tracce di attività e storie di comando a riassunti compatti che descrivono cosa era già stato tentato e appreso:
| Solo repository
Il successore riceve solo il repository e la descrizione del compito, senza alcun record di azioni, decisioni o tentativi falliti precedenti. |
Traccia grezza
Il successore riceve la storia completa del predecessore, esponendo ogni comando, osservazione, modifica, successo e fallimento. |
| Note riassuntive
Il successore riceve un riassunto in linguaggio naturale generato dalla storia di attività del predecessore, condensando le informazioni chiave in prosa. |
Note strutturate
Il successore riceve un documento di passaggio compatto che contiene campi standardizzati che descrivono lo stato del compito, le modifiche apportate e i risultati di convalida. |
Piuttosto che concentrarsi solo sulla risoluzione del compito, lo studio è stato progettato per misurare il costo della continuazione stessa, con attenzione ai tool utilizzati, ai token consumati e alla quantità di sforzo richiesto per ricostruire la logica dietro il lavoro precedente.
Tre definizioni di rilevamento del punto di passaggio e tre stati di passaggio sono stati definiti per gli esperimenti:
| Rilevamento del punto di passaggio | Stati di passaggio |
|---|---|
| Dopo la prima modifica del codice. Dopo la prima modifica del codice. Il primo agente ha iniziato a lavorare ma non ha ancora verificato se la modifica funziona. | Necessita di completamento. Il compito è incompleto e il successore deve continuare a lavorare per raggiungere una soluzione corretta. |
| Dopo il primo risultato di convalida. Il primo agente ha già eseguito un test o un passaggio di convalida, fornendo alcune prove di progresso. | Già risolto e preservato. Il compito è stato effettivamente completato e il successore deve evitare di romperlo. |
| Dopo la prima modifica post-fallimento. Un test è fallito e il primo agente ha già tentato di rispondere apportando un’altra modifica. | Comportamento esistente rotto. Qualcosa che funzionava prima è ora rotto. |
Dati e test
Per creare scenari di passaggio realistici, il benchmark degli autori è stato costruito da 75 compiti di ingegneria del software tratti da SWE-Bench Verified, con un focus su problemi che solitamente richiedono tra 15 minuti e 4 ore per essere risolti.
Piuttosto che valutare solo i compiti completati, i ricercatori hanno catturato più punti di controllo intermedi durante il lavoro, creando situazioni in cui un agente IA doveva prendere il controllo da un altro:

Costruzione del benchmark di acquisizione. Settantaquattro compiti di SWE-bench Verified sono stati ampliati in 181 punti di passaggio che coprono tre fasi di lavoro, etichettati in base allo stato del repository al momento dell’acquisizione e valutati in quattro condizioni di condivisione di informazioni, producendo 2.172 esecuzioni totali di acquisizione dell’agente successore. Fonte
Perché ogni compito poteva generare più punti di passaggio e ogni passaggio è stato testato utilizzando quattro diverse forme di informazioni trasferite, il benchmark si è ampliato rapidamente, con il set di dati finale che comprende 181 compiti di passaggio distinti e 724 valutazioni di acquisizione per ogni modello di successore, producendo 2.172 esecuzioni di acquisizione attraverso i tre sistemi IA testati.
Un ambiente di agente di codifica di tipo OpenHands è stato utilizzato per i test, con azioni terminali, congelamento del repository ai punti di passaggio, modifica del file e convalida ufficiale dal benchmark SWE-Bench.
Nel principale studio, tutti i punti di passaggio derivano da esecuzioni del predecessore basate su Qwen, al fine di fornire un punto di partenza fisso per valutare la differenza tra diverse combinazioni di agenti e scenari diversi.
Le coppie di acquisizione testate sono state Qwen-Qwen; Qwen-Gemma; e Qwen-Devstral.
Traccia grezza ha prodotto le più grandi riduzioni nello sforzo del successore, riducendo gli eventi dell’agente del 57-59%, mentre note riassuntive e note strutturate hanno ridotto gli eventi del 20-46%. L’utilizzo dei token di prompt è diminuito in tutte e tre le strategie, con riduzioni che vanno dal 42% al 63%:
| Visualizzazione | Esecuzioni | Tasso di risoluzione (% pp) | Eventi dell’agente (% Δ) | Token di prompt (% Δ) |
|---|---|---|---|---|
| Qwen → Qwen | ||||
| Repository solo | 181 | 46,4% | 99 | 1,63M |
| Traccia grezza | 181 | 52,5% (+6,1 pp) | 41 (-59%) | 811k (-50%) |
| Note riassuntive | 181 | 51,4% (+5,0 pp) | 53 (-46%) | 602k (-63%) |
| Note strutturate | 181 | 50,8% (+4,4 pp) | 55 (-44%) | 660k (-60%) |
| Qwen → Gemma | ||||
| Repository solo | 181 | 42,5% | 49 | 738k |
| Traccia grezza | 181 | 49,2% (+6,6 pp) | 21 (-57%) | 300k (-59%) |
| Note riassuntive | 181 | 44,2% (+1,7 pp) | 33 (-33%) | 319k (-57%) |
| Note strutturate | 181 | 43,6% (+1,1 pp) | 39 (-20%) | 317k (-57%) |
| Qwen → Devstral | ||||
| Repository solo | 181 | 34,3% | 175 | 3,94M |
| Traccia grezza | 181 | 49,2% (+14,9 pp) | 73 (-58%) | 1,66M (-58%) |
| Note riassuntive | 181 | 43,6% (+9,4 pp) | 123 (-30%) | 2,30M (-42%) |
| Note strutturate | 181 | 44,8% (+10,5 pp) | 125 (-29%) | 2,30M (-42%) |
Sotto passaggi di repository solo, gli agenti successori dovevano spendere interazioni aggiuntive per ricostruire l’intento del predecessore, le prove precedenti e gli approcci falliti. Traccia grezza, note riassuntive e note strutturate hanno trasferito parte di quelle informazioni direttamente, riducendo la quantità di ritrovamento richiesto, sebbene al costo di prompt iniziali più grandi.
Per testare se i guadagni fossero genuini, ogni passaggio ricco di contesto è stato confrontato con un passaggio di repository solo che inizia dallo stesso punto. In tutte le combinazioni di modelli, i passaggi più ricchi hanno costantemente ridotto il lavoro richiesto dagli agenti successori.
Le tracce degli eventi completi hanno prodotto le più grandi riduzioni, mentre le note riassuntive e strutturate hanno anche fornito risparmi sostanziali. L’effetto è apparso in tutto il benchmark e non è stato guidato da un piccolo numero di casi anomali:
| Visualizzazione | Esecuzioni abbinate | Eventi dell’agente del repository solo | Eventi dell’agente (% Δ) | 95% CI per Δ Eventi | Token di prompt (% Δ) |
|---|---|---|---|---|---|
| Qwen → Qwen | |||||
| Traccia grezza | 181 | 99 | 41 (-59%) | [-50%, -42%] | 798k (-51%) |
| Note riassuntive | 181 | 99 | 53 (-46%) | [-38%, -28%] | 572k (-65%) |
| Note strutturate | 181 | 99 | 55 (-44%) | [-34%, -24%] | 646k (-60%) |
| Qwen → Gemma | |||||
| Traccia grezza | 181 | 49 | 21 (-57%) | [-47%, -33%] | 300k (-59%) |
| Note riassuntive | 181 | 49 | 33 (-33%) | [-25%, -8%] | 319k (-57%) |
| Note strutturate | 181 | 49 | 39 (-20%) | [-18%, -1%] | 317k (-57%) |
| Qwen → Devstral | |||||
| Traccia grezza | 181 | 175 | 73 (-58%) | [-45%, -22%] | 1,65M (-58%) |
| Note riassuntive | 181 | 175 | 123 (-30%) | [-28%, -15%] | 2,28M (-42%) |
| Note strutturate | 181 | 175 | 125 (-29%) | [-28%, -17%] | 2,29M (-42%) |
Per confermare che l’effetto non fosse guidato da un piccolo numero di casi insoliti, i ricercatori hanno confrontato ogni passaggio con un passaggio di repository solo equivalente che inizia dallo stesso punto. Le riduzioni sono rimaste coerenti in tutte le combinazioni di modelli, indicando che i benefici riflettono un modello significativo, piuttosto che alcuni esempi eccezionali.
Porta via…
In breve†, gli autori hanno scoperto che quando un’IA passa un compito a un’altra, anche note semplici aiutano la seconda IA a continuare più efficientemente.
Le registrazioni complete di ciò che è accaduto funzionano meglio, ma qualsiasi informazione di passaggio è meglio che lasciare il successore a ricostruire tutto dal codice solo; e i risultati sopra illustrano che l’approccio “full fat” della traccia grezza ha inevitabilmente un costo di token più alto.
Conclusione
Sebbene il documento stesso sia rivolto strettamente ai ricercatori con interessi specifici, con un appeal limitato per il lettore casuale, il nuovo lavoro affronta comunque uno dei problemi più interessanti e urgenti riguardanti lo stato attuale dell’arte nelle interfacce e nei protocolli uomo-IA.
Sarebbe auspicabile che i paradigmi sviluppati e le intuizioni acquisite in questo tipo di esplorazione potrebbero eventualmente estendersi a un contesto più ampio di utilizzo dell’IA rispetto a quello strettamente agente di codifica.
Un’ulteriore area di esplorazione potrebbe essere per futuri progetti considerare modi per valutare quale livello di documentazione potrebbe essere considerato minimo per un progetto specifico, in base alle sue caratteristiche e al suo caso d’uso. Tuttavia, anche questa funzionalità, che aiuterebbe a razionalizzare la spesa di tempo e denaro, costa tempo e denaro; e quindi il dilemma di bilancio coinvolto negli scenari di documentazione rimane difficile da evitare.
* Personalmente, per le sessioni di ChatGPT che sono gravate da ritardi e contesto eccessivo, ho recentemente iniziato a esportare (con alcune difficoltà) un PDF pulito della chat e a utilizzarlo come punto di partenza per una nuova sessione, che diventa ‘parte 2’.
† Purtroppo, questo non è il documento più accessibile che abbia letto quest’anno, e per questo motivo non posso consigliare al lettore di leggere il lavoro originale, sebbene i risultati riassunti rimangano di interesse.
Pubblicato per la prima volta mercoledì, 3 giugno 2026












