Debito tecnico nell'era dell'AI: stesso numero, decisioni opposte

• Il TDR (Technical Debt Ratio) misura il capitale del debito tecnico, cioè il lavoro stimato per rimuoverlo rispetto a un lavoro di riferimento. Secondo gli autori non è un metro oggettivo ma una famiglia di indicatori: strumenti, soglie e assunzioni diversi producono numeri diversi, come documenta un confronto fra nove strumenti [Avgeriou et al., 2021]. 
• Due punti ciechi del TDR: l'architettura, che pesa sulla manutenzione più degli altri tipi di debito ma che gli strumenti vedono poco, e, nella proposta degli autori, il debito funzionale, la parte di debito che non sta nel codice ma nelle lavorazioni manuali e nei processi paralleli nati da scelte di rinvio. 
• Gli autori propongono tre dimensioni distinte: capitale (quanto abbiamo accumulato), interesse (quanta frizione paghiamo oggi, a ogni cambiamento e a ogni utilizzo) ed esposizione strategica (quanto il sistema ostacolerebbe le mosse future rilevanti). Non vanno fuse in un unico indicatore. 
• TIME+ è una lettura degli autori del modello TIME di Gartner: la posizione nei quattro quadranti resta, la dimensione della bolla visualizza l'interesse, l'intensità del colore l'esposizione strategica. Permette di distinguere sistemi apparentemente simili nello stesso quadrante. 
• Nell'era dell'AI il debito può essere più facile da ripagare e, insieme, più facile da accumulare: le stime di capitale possono invecchiare più in fretta, l'interesse può pagarsi più spesso, e la decisione "non conviene intervenire" presa con i costi di ieri ha una scadenza implicita.

Prima o poi, in ogni comitato di portafoglio, il debito tecnico diventa un numero: una percentuale che promette di dire quanto è fragile un sistema. È un segnale utile, ma nessuna percentuale può decidere da sola se quel sistema vada tollerato, riprogettato, migrato o dismesso. Per decidere servono tre domande: quanto debito abbiamo accumulato, quanto ci costa portarlo e quanto conta, per il futuro dell'impresa, la capacità di quel sistema di cambiare. E nell'era dell'AI, in cui il debito è più facile da ripagare e più facile da accumulare, quel numero invecchia ancora più in fretta.

Immaginiamo due applicazioni. La prima supporta un processo stabile, viene modificata poche volte l'anno e sarà dismessa entro diciotto mesi. La seconda gestisce un servizio digitale strategico per i clienti, riceve rilasci ogni settimana ed espone dati e funzioni a nuovi servizi di AI. Supponiamo, a puro titolo di esempio, che lo stesso strumento attribuisca a entrambe un rapporto di debito tecnico (Technical Debt Ratio, TDR) del 30%: in sostanza, il lavoro stimato per rimuovere il debito vale il 30% del lavoro necessario a costruire il sistema. Dovremmo prendere la stessa decisione? Evidentemente no. 

Eppure, quando un problema difficile riesce finalmente a produrre un indicatore, il passo verso l'apparenza di oggettività è breve. Una rassegna di oltre 550 studi sulla priorità da dare al debito tecnico non trova consenso su quali fattori debbano guidarla né su come misurarli [Lenarduzzi et al., 2021]. Le metriche restano utili, purché le si usi per ciò che sanno fare.

Tendiamo a immaginare il TDR come un metro campione del debito tecnico. Non lo è. Un confronto fra nove strumenti di misura mostra regole di analisi e criteri di stima diversi, e osserva che la quantificazione del debito in termini di lavoro necessario manca ancora di una validazione empirica [Avgeriou et al., 2021]. È più corretto parlare di una famiglia di indicatori con una forma comune: 

TDR ≈ lavoro stimato per rimuovere il debito / lavoro di riferimento 

Il numeratore sembra la parte difficile, spesso lo è anche il denominatore. Nella configurazione predefinita di SonarQube, uno degli strumenti più diffusi, il lavoro di riferimento è calcolato dalle righe di codice, assumendo convenzionalmente 30 minuti per riga, e anche le soglie che separano un giudizio buono da uno cattivo sono parametri configurabili [SonarSource, 2025]: se cambiano, cambia anche il giudizio. 

Il TDR è utile soprattutto in due casi: per osservare l'andamento di uno stesso sistema quando metodo e perimetro restano stabili, e per individuare anomalie tra sistemi analizzati con criteri omogenei. Il confronto diventa invece debole quando cambiano strumenti, assunzioni o perimetri. Prima di discuterne il valore, occorre quindi sapere come è stato calcolato.

C'è però un limite che nessuna scelta di metodo può correggere. Gli strumenti lavorano soprattutto sul codice e in modo molto limitato sull'architettura, che pure pesa sulla manutenzione più degli altri tipi di debito [Avgeriou et al., 2021]. Al rischio di leggere male il numero se ne aggiunge quindi un altro: misurare con precisione ciò che lo strumento vede e lasciare in ombra il resto. Un TDR basso può rassicurare anche in presenza di un'architettura fortemente accoppiata o difficile da evolvere: assenza di debito rilevato non significa assenza di debito rilevante.

C'è un secondo limite, più radicale: una parte del debito non sta affatto nel codice. Nel primo articolo della serie [Mainetti e Ficagna, 2026] abbiamo adottato la definizione proposta a Dagstuhl: il debito tecnico è un insieme di scelte di progettazione o di implementazione convenienti nel breve periodo, che rendono i cambiamenti futuri più costosi o persino impossibili [Avgeriou et al., 2016]. Già lì osservavamo che il debito può annidarsi anche nei requisiti, e la ricerca lo descrive come la distanza fra i bisogni degli utenti e ciò che il sistema realizza [Lenarduzzi e Fucci, 2019]. 

Proponiamo di fare un passo ulteriore. Non per rivedere la definizione tradizionale di debito tecnico, che resta quella appena richiamata, ma per affiancarle un concetto che chiamiamo debito funzionale, non ancora consolidato nella letteratura, e guardare così al debito complessivo di un sistema. La ragione è manageriale: le decisioni di portafoglio riguardano il sistema intero, e un debito confinato alla sola dimensione tecnologica rischia di restare una questione per specialisti. Il rischio opposto è altrettanto chiaro: la letteratura distingue il debito tecnico, in gran parte invisibile, dalle funzionalità mancanti, che non considera debito [Kruchten et al., 2012]. Serve quindi un criterio selettivo. È debito funzionale solo ciò che deriva da una scelta passata di rinvio o di compromesso e continua a generare un costo ricorrente o a limitare le opzioni future. Un bisogno nuovo, che nessuno ha mai scelto di rinviare, non è debito: lo ritroveremo più avanti come esposizione strategica. Non lo è nemmeno un'inefficienza senza una decisione pregressa riconoscibile. Sul lato funzionale il criterio è volutamente più stretto che su quello tecnico: senza il codice come riferimento, è la decisione all'origine a distinguere il debito da una semplice carenza. 

Immaginiamo, a puro titolo di esempio, la regola di calcolo di una nuova tipologia di contratto, rinviata al rilascio successivo per rispettare la data di avvio e gestita nel frattempo con un foglio di calcolo e una verifica manuale. Anni dopo, quella soluzione provvisoria è diventata un processo con persone dedicate, controlli propri e un rischio di errore che nessuno ha mai deciso di accettare. Ha un'origine precisa, un costo che si ripete a ogni utilizzo e nessuna data di riesame. Nessuno strumento di analisi del codice può vederla: il TDR non ne coglie nulla, e chi guardasse soltanto a quel numero sottostimerebbe proprio la parte del debito che il business percepisce più direttamente.

Le metriche di rimozione descrivono soprattutto il capitale del debito, non quanto quel debito pesi oggi sull'organizzazione. L'interesse dipende da due fattori che una misura del capitale non cattura: quanta frizione il debito introduce in ciascun cambiamento e con quale frequenza il sistema viene modificato. Per questo Seaman e Guo propongono di stimare, accanto al capitale e all'interesse, anche la probabilità che l'interesse venga effettivamente pagato [Seaman e Guo, 2011]. Il debito funzionale segue lo stesso schema, con una differenza: il suo interesse può essere pagato anche a ogni utilizzo, per esempio ogni volta che una lavorazione manuale compensa ciò che il sistema non fa. 

Misurare l'interesse in senso stretto resta difficile, ma i suoi effetti sono osservabili. Gli sviluppatori dichiarano di perdere in media il 23% del tempo di lavoro a causa del debito tecnico [Besker et al., 2019], e in 39 sistemi aziendali il codice di bassa qualità è risultato associato a 15 volte più difetti [Tornhill e Borg, 2022]. Il primo dato è autodichiarato, il secondo viene da autori legati a un fornitore di strumenti di analisi, ma entrambi indicano che il debito può tradursi in frizioni concrete sul lavoro di cambiamento. 

Per un CIO, molti segnali utili sono già disponibili nei sistemi di sviluppo, rilascio e gestione operativa: tempi di rilascio delle modifiche di ciascun sistema, quota di lavoro non pianificato, rilavorazioni, incidenti e sforzo richiesto da modifiche comparabili. Per il debito funzionale i segnali vanno cercati anche fuori dall'IT, nelle lavorazioni manuali e nei fogli di calcolo paralleli. Incrociati con la frequenza del cambiamento e dell'uso, questi segnali mostrano dove il debito produce più frizione, ricordando che non tutte le inefficienze derivano dal debito. È opportuno rendere visibile quanta capacità di cambiamento viene consumata per compensare le carenze accumulate in passato, e sottratta così agli investimenti nel futuro. 

La Figura 1 torna alle due applicazioni iniziali: a parità di TDR, frequenza del cambiamento, vita residua ed esposizione strategica, che definiremo tra poco, cambiano radicalmente il significato economico di quel numero.

Capitale e interesse guardano al passato e al presente, manca ciò che potrebbe diventare rilevante domani. Proponiamo quindi una dimensione che chiamiamo esposizione strategica al cambiamento, o più brevemente esposizione strategica: il valore futuro, o il rischio, legato a cambiamenti che i limiti del sistema attuale renderebbero difficili. Non è una metrica standardizzata della letteratura, ma la traduzione operativa del valore di opzione dell'architettura discusso nel primo articolo della serie. Il risultato non è un numero, ma un giudizio esplicito e motivato sugli scenari strategici che il sistema potrebbe ostacolare. Nell'esposizione rientrano anche i bisogni nuovi, che nessuno ha mai scelto di rinviare: non sono debito, ma domande future. 

L'interesse guarda ai cambiamenti osservati oggi, l'esposizione strategica a quelli attesi domani. La valutazione può partire dalle tre o cinque mosse del piano di evoluzione che coinvolgono il sistema: un nuovo canale, un cambio di fornitore, una nuova normativa, l'esposizione di dati e funzioni ad agenti di AI. Per ciascuna mossa occorre documentare due giudizi distinti: la rilevanza per l'impresa e la difficoltà di realizzarla con il sistema attuale, considerando costo, tempo e rischio. L'esposizione è alta quando mosse importanti si scontrano con ostacoli significativi, tecnici o funzionali. L'applicazione di questa logica alla revisione del portafoglio è una nostra proposta. 

La Figura 2 mette le tre dimensioni una accanto all'altra: il capitale guarda a ciò che abbiamo accumulato, nella sua componente tecnica e funzionale, l'interesse alla frizione presente, l'esposizione a ciò che è in gioco nel futuro. Per questo non vanno fuse in un indice unico: ognuna richiede un metodo di valutazione coerente con il fenomeno che rappresenta.

Queste dimensioni possono alimentare una scorecard, come quella che abbiamo proposto per i CIO in un precedente lavoro [Ficagna e Mainetti, 2026], purché si evitino due errori. Il primo è scegliere alcuni pesi, sommare tutto e produrre un indicatore con due decimali che sembri più oggettivo di quanto sia: le grandezze in gioco non sono compensabili, e una vulnerabilità critica non diventa accettabile perché l'applicazione ha un'ottima adeguatezza funzionale. Il secondo è trasformare la misura in un obiettivo, perché a quel punto tende a smettere di essere una buona misura [Strathern, 1997]: se il TDR entra nei sistemi di valutazione delle prestazioni, i team impareranno a ottimizzare ciò che lo strumento misura anziché ciò che rende il sistema più facile da cambiare. Il compito della scorecard è rendere esplicite le ragioni della decisione, affinché CIO, CFO e responsabili di business discutano gli stessi elementi e si assumano consapevolmente i trade-off.

Partiamo dal modello TIME di Gartner perché offre ai comitati di portafoglio un linguaggio già familiare: quattro esiti (tollerare, investire, migrare, eliminare) e due valutazioni, l'adeguatezza funzionale, cioè la capacità di sostenere processi e obiettivi di business, e l'adeguatezza tecnica, cioè la qualità e la sostenibilità dell'applicazione [Gartner, 2026]. La posizione nei quattro quadranti orienta la strategia, ma non stabilisce da sola la priorità. 

Proponiamo di leggere TIME con le lenti di questa nostra serie di articoli. I due assi sono i luoghi in cui si manifestano le due componenti del debito complessivo: il debito tecnico abbassa l'adeguatezza tecnica, il debito funzionale quella funzionale. Non coincidono con il debito, perché l'adeguatezza dipende anche dal supporto dei fornitori, dalla sicurezza, dalle competenze disponibili e dal valore che il sistema produce, ma lo contengono. Allo stesso modo, i quattro esiti diventano quattro strategie sul debito: tollerare significa convivere con il debito pagandone l'interesse; investire, ripagarlo man mano mentre il sistema evolve; migrare, rifinanziarlo su una piattaforma nuova, con il rischio di trasferirlo se la struttura non viene ripensata; eliminare, estinguerlo con la dismissione. È una lettura nostra, che Gartner non propone, e serve a portare la metafora finanziaria fin dentro uno strumento che i CIO già usano.

Ciò che la posizione non mostra è quanto ci costa oggi portare quel debito e quanto conterà domani la capacità del sistema di cambiare. Proponiamo quindi di lasciare invariati i due assi originali e di aggiungere due informazioni, come mostra la Figura 3: la dimensione della bolla rappresenta l'interesse, l'intensità del colore l'esposizione strategica. Nel quadrante della migrazione, per esempio, il Sistema A genera poca frizione ed è poco esposto, mentre il Sistema B assorbe continuamente capacità di cambiamento ed è centrale per il piano di evoluzione. Stesso quadrante, priorità diverse.

TIME+ non è dunque un modello a quattro dimensioni del debito, ma una mappa conosciuta su cui le tre dimensioni trovano posto: la posizione descrive l'adeguatezza attuale del sistema, influenzata anche dal capitale del debito; la dimensione della bolla mostra la frizione che paghiamo oggi; il colore ciò che è in gioco domani. La visualizzazione non decide quale iniziativa finanziare: permette al comitato di distinguere sistemi apparentemente simili e di motivare perché uno debba precedere l'altro, rendendo esplicita e discutibile una soggettività che resta.

Nell'era dell'AI il debito tecnico è più facile da ripagare e, nello stesso tempo, più facile da accumulare. Per chi deve misurarlo, questo paradosso ha tre conseguenze precise. 

La prima riguarda il capitale: l'AI può rendere una parte del debito più economica da rimuovere, e la sua stima diventa meno stabile. McKinsey riporta, da progetti condotti con una propria metodologia, accelerazioni dal 40 al 50% nei tempi di modernizzazione e riduzioni intorno al 40% dei costi legati al debito tecnico [Bawcom e Fitzpatrick, 2024]. Sono risultati da casi aziendali, da non estendere a qualsiasi portafoglio, ma bastano a suggerire che un sistema troppo costoso da modernizzare tre anni fa potrebbe non esserlo più oggi. Ogni decisione del tipo «non conviene intervenire», presa con i costi di ieri, ha quindi una scadenza implicita e va riesaminata, almeno dove l'AI riduce davvero il costo della rimozione. 

La seconda riguarda l'interesse, che si paga più spesso, e il debito, che può accumularsi più in fretta. Se l'AI rende più economico produrre cambiamento, l'organizzazione può scegliere di cambiare di più, e ogni cambiamento è un'occasione per pagare l'interesse del debito esistente. DORA rileva che il tempo risparmiato nella scrittura del codice viene spesso riallocato su verifica e controllo, e che una maggiore adozione dell'AI si associa sia a un maggiore volume di rilasci sia a una maggiore instabilità [Baolin e Harvey, 2026]. Uno studio su progetti open source che hanno adottato un assistente di programmazione basato sull'AI ha osservato un aumento di velocità ampio ma transitorio, accompagnato da un aumento persistente della complessità del codice, associato nel tempo a un rallentamento della velocità inizialmente guadagnata [He et al., 2026]. Per la misura, la conseguenza è che una fotografia statica del capitale basta ancora meno: conta osservare quanta frizione produce ogni cambiamento e con quale frequenza viene pagata.

La terza riguarda l'AI come strumento di misura. Modelli e agenti, affiancati agli strumenti tradizionali di analisi del codice, aiutano già a individuare anomalie, ricostruire dipendenze e proporre interventi di refactoring. Ma una rassegna recente di 29 studi mostra che le applicazioni si concentrano sull'identificazione e sulla rimozione del debito in singole parti del software, mentre restano poco esplorate le altre attività di gestione, l'analisi trasversale e l'integrazione con il giudizio umano [Gosu et al., 2026]. L'AI può diventare molto efficace nella diagnosi tecnica e, in prospettiva, aiutare a ricostruire quella visione d'insieme dell'architettura che oggi gli strumenti offrono poco. Non dispone però del contesto necessario per stabilire quale debito l'impresa debba accettare: strategia, propensione al rischio, piano di evoluzione, vincoli normativi, vita attesa del prodotto, valore delle opzioni future. Molte di queste informazioni non stanno nel codice, come gran parte del debito funzionale, e richiedono un giudizio manageriale esplicito.

Un debito che oggi tolleriamo razionalmente può diventare molto più costoso in sei mesi: aumenta la frequenza delle modifiche, cambia il ruolo dell'applicazione, termina il supporto di un componente. Oppure, come abbiamo visto, può diventare molto più economico rimuoverlo. La gestione del debito deve quindi entrare nei normali processi di governo del portafoglio, senza bisogno di nuove cerimonie. Per ogni debito materiale bastano i quattro elementi proposti nel primo articolo: la ragione per cui esiste, un responsabile, una stima dell'interesse che genera e una data di riesame. 

In uno studio sul campo durato sedici mesi con un team industriale, semplici promemoria nelle attività da svolgere hanno aumentato in modo duraturo la consapevolezza sul debito, e il team ha adottato una data di riesame per richiamare periodicamente le voci aperte [Wiese et al., 2026]. Il risultato riguarda un solo team, ma il meccanismo è utile: fissare una scadenza non obbliga a rimborsare il debito, impone di verificare se valgono ancora le condizioni che ne avevano giustificato la tolleranza. 

La data di riesame può essere anticipata da segnali empirici. Possiamo osservare quando i tempi di rilascio crescono in presenza di determinate scelte architetturali, quali applicazioni concentrano una quota sproporzionata di incidenti, rilavorazioni o lavorazioni manuali e dove il costo del cambiamento cresce nel tempo. Su questa base proponiamo di costruire parametri di riferimento interni, fondati sul comportamento reale del portafoglio, da usare come segnali per riaprire la discussione: indicazioni specifiche del contesto, non soglie universali. 

Si obietterà che il consiglio di amministrazione vuole un numero. Ma comprimere le tre dimensioni in una media nasconderebbe proprio ciò che serve decidere. Meglio valutare ciascuna con il metodo adatto: misure quantitative dove sono affidabili, indicatori indiretti dove il legame causale è mediato, valutazioni basate su scenari dove una stima robusta non è possibile. Un segnale interno offre meno certezze di una soglia universale e, in cambio, permette di imparare dal comportamento del proprio portafoglio.

Il punto non è trovare la metrica perfetta, che probabilmente non esiste, ma fare in modo che CIO, CFO e CEO valutino insieme ciò che corrono il rischio di discutere separatamente. Nell'era dell'AI, che può rendere il debito più facile da ripagare e più facile da accumulare, queste valutazioni diventano ancora più necessarie e vanno riviste più spesso. In pratica, per ogni sistema rilevante del portafoglio proponiamo che il comitato si ponga quattro domande. 

1. Capitale. Quanto costerebbe oggi rimuovere il debito, tecnico e funzionale, e con quale metodo lo abbiamo stimato? 
2. Interesse. Quanta frizione stiamo pagando, su quante modifiche e su quanti utilizzi? 
3. Esposizione. Quali mosse strategiche dipendono da questo sistema, e quanto è difficile eseguirle così com'è oggi? 
4. Riesame. Quando torneremo a verificare le risposte? 
   
   TDR, scorecard, strumenti automatici e modelli di portafoglio diventano strumenti di governo dell'impresa quando collegano evidenze tecniche, impatto operativo e priorità di business. La qualità di una misura del debito non dipende dalla sua precisione, ma dalla sua capacità di motivare una scelta e di indicare quali cambiamenti dovranno farla riesaminare. 
   
   Pubblicato originariamente su LinkedIn il 12/10/2026.

Avgeriou, P., Kruchten, P., Ozkaya, I., & Seaman, C. (2016). Managing technical debt in software engineering (Dagstuhl Seminar 16162). Dagstuhl Reports, 6(4), 110-138. drops.dagstuhl.de 

Avgeriou, P., Taibi, D., Ampatzoglou, A., Arcelli Fontana, F., Besker, T., Chatzigeorgiou, A., Lenarduzzi, V., Martini, A., Moschou, A., Pigazzini, I., Saarimäki, N., Sas, D., Soares de Toledo, S., & Tsintzira, A. A. (2021). An overview and comparison of technical debt measurement tools. IEEE Software, 38(3), 61-71. research.chalmers.se 

Baolin, J., & Harvey, N. (2026). Balancing AI tensions: Moving from AI adoption to effective SDLC use. DORA, 10 marzo 2026. dora.dev 

Bawcom, A., & Fitzpatrick, M. (2024). AI for IT modernization: Faster, cheaper, and better. McKinsey & Company, 2 dicembre 2024. mckinsey.com 

Besker, T., Martini, A., & Bosch, J. (2019). Software developer productivity loss due to technical debt: A replication and extension study examining developers' development work. Journal of Systems and Software, 156, 41-61. doi.org/10.1016/j.jss.2019.06.004 

Ficagna, M., & Mainetti, S. (2026). Come misurare il debito tecnico: una guida per i CIO. ZeroUno, 14 settembre 2026. zerounoweb.it 

Gartner (2026). Connaughton, P., Travis, T., & Wilkins, G. How to Assess the Fitness of Your Application Portfolio. Gartner, 24 giugno 2026. 

Gosu, S., Feitosa, D., & Avgeriou, P. (2026). The use of Generative AI in technical debt management: A systematic literature review. Information and Software Technology, 199, 108257. 

He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2026). Speed at the cost of quality: How Cursor AI increases short-term velocity and long-term complexity in open-source projects. Proceedings of MSR 2026. ACM. arxiv.org/abs/2511.04427 

Kruchten, P., Nord, R. L., & Ozkaya, I. (2012). Technical debt: From metaphor to theory and practice. IEEE Software, 29(6), 18-21. doi.org/10.1109/MS.2012.167 

Lenarduzzi, V., & Fucci, D. (2019). Towards a holistic definition of requirements debt. Proceedings of ESEM 2019. IEEE. doi.org/10.1109/ESEM.2019.8870159 

Lenarduzzi, V., Besker, T., Taibi, D., Martini, A., & Arcelli Fontana, F. (2021). A systematic literature review on technical debt prioritization: Strategies, processes, factors, and tools. Journal of Systems and Software, 171, 110827. doi.org/10.1016/j.jss.2020.110827 

Mainetti, S., & Ficagna, M. (2026). Debito tecnico nell'era dell'AI: più facile da ripagare, più facile da accumulare. LinkedIn, 5 ottobre 2026. linkedin.com 

Seaman, C., & Guo, Y. (2011). Measuring and monitoring technical debt. Advances in Computers, 82, 25-46. doi.org/10.1016/B978-0-12-385512-1.00002-5 

SonarSource (2025). Understanding measures and metrics. SonarQube Server Documentation, versione 2025.3. docs.sonarsource.com 

Strathern, M. (1997). Improving ratings: Audit in the British University system. European Review, 5(3), 305-321. cambridge.org 

Tornhill, A., & Borg, M. (2022). Code Red: The business impact of code quality. A quantitative study of 39 proprietary production codebases. Proceedings of the International Conference on Technical Debt (TechDebt 2022). ACM/IEEE. doi.org/10.1145/3524843.3528091 

Wiese, M., Serwa, K., Besier, A., Marion-Jetten, A. S., & Bittner, E. (2026). Establishing technical debt management: A five-step workshop approach and an action research study. Journal of Systems and Software, 231, 112606. arxiv.org/abs/2508.15570