La scena tech si è scaldata negli ultimi giorni, con una piccola folla digitale pronta a sventolare cartelli in cui spiccano termini impegnativi come game changing, pazzesco, incredibile, tutto rigorosamente accompagnato da hashtag strategici. Il colpevole di tanta euforia è il formato TOON Token-Oriented Object Notation, presentato come la nuova frontiera della compressione per i dati destinati agli LLM. Chi frequenta questo settore da tempo riconosce a colpo d’occhio la dinamica. Si presenta un’idea brillante, si grida al miracolo e si aspetta che la magia avvenga per osmosi. A volte la magia arriva. Altre volte si scopre che era solo un esercizio di stile travestito da rivoluzione. Vale la pena mantenere un minimo di compostezza, soprattutto quando qualcuno invita la comunità a credere che un nuovo formato testi la fisica dei token. La prudenza, in questi casi, è più un antidoto che una virtù.
La prima domanda che si dovrebbe porre chiunque maneggi architetture linguistiche avanzate riguarda la presenza di benchmark reali. Il mondo degli LLM è governato da numeri più di quanto non appaia nei thread su X, e affermare di aver abbattuto il costo del contesto senza un solido set di misurazioni è come promettere di piegare lo spazio tempo con un PowerPoint. L’entusiasmo fa gioco, certo, ma la credibilità si costruisce sul rigore. Il sospetto che molte prese di posizione provengano da divulgatori innamorati dell’eco che produce il proprio post è forte. La comunità lo sa, anche se finge di non ricordarlo.
Il punto cruciale è che JSON è onnipresente. Non è solo ovunque nel software moderno. È ovunque anche nei training data dei modelli, ed è stato assunto come forma mentale prima ancora che come formato di serializzazione. Gli LLM respirano JSON come gli astronomi respirano numeri. Lo comprendono in modo nativo, riconoscono la sua struttura a colpo d’occhio, si orientano nei suoi incastri con la stessa naturalezza con cui un ingegnere dei primi anni duemila navigava un file XML. Quando si introduce un formato alternativo, come TOON, si chiede al modello di imparare una sintassi nuova, che non compare nei dataset di base. Significa dedicare token a spiegare al modello un protocollo che potrebbe essere evitato. Ironia della sorte, l’obiettivo dichiarato del formato è proprio risparmiare token. C’è un vecchio detto nelle sale server: ogni nuovo standard è solo un altro standard in più.
La seconda considerazione è più scomoda di quanto sembri. JSON può essere già incredibilmente compatto senza dover abbandonare la sua forma naturale. L’argomento secondo cui JSON sarebbe troppo prolisso è vero solo a metà. La verbosità è un parametro elastico. Si può comprimere in modi molto più eleganti del riscrivere tutto da zero. Se si passa da oggetti completi a forme vettoriali più sintetiche, si ottengono riduzioni notevoli di spazio mantenendo piena leggibilità per gli umani e piena comprensibilità per i modelli. Nessuno vieta di sostituire una struttura completa con una variante più asciutta in cui gli oggetti diventano tuple ordinate. E nulla impedisce di spingere oltre la sintesi fino a trasformare ogni entità in una stringa unica con separatori, raggiungendo livelli di compattezza più che sufficienti per qualunque scenario operativo. È curioso come molti entusiasti sembrino ignorare questa evoluzione del formato, quasi volessero dimenticare che l’efficienza non richiede sempre la rivoluzione, spesso basta la manutenzione.
La terza considerazione ruota attorno al tema dell’interoperabilità. JSON è un linguaggio comune, il ponte che unisce API REST, microservizi, database, tool di validazione, frontend e backend. È lo standard de facto dell’ecosistema. Il valore degli LLM non risiede solo nella loro potenza computazionale, ma nella loro capacità di inserirsi in flussi informativi complessi. Ogni agente, ogni tool, ogni orchestratore si aspetta JSON. Cambiare formato significa rompere un patto tacito con un intero settore. Significa introdurre complicazioni inutili nei passaggi tra sistemi. Significa indebolire la toolchain e aumentare il rischio di errori. In un’epoca in cui le aziende devono integrare modelli, pipeline e automazioni con la delicatezza di un’operazione chirurgica, aggiungere un formato estraneo sembra una decisione che porta più costi che benefici. Una piccola ironia della storia: mentre molti rincorrono la compressione perfetta, il mercato reale premia ciò che si integra senza frizioni.
La parte più divertente di questa storia è che ogni volta che compare un nuovo formato si ripete lo stesso rito. C’è sempre chi promette che il nuovo linguaggio cambierà tutto. C’è sempre chi ignora il peso dell’ecosistema esistente. C’è sempre chi proclama la morte di JSON con la stessa sicurezza con cui nel 1998 si proclamava la morte di Java. La tecnologia ama i ritorni di fiamma. L’industria, meno. Le aziende cercano stabilità, compatibilità, prevedibilità. Cercano standard solidi che sopravvivano alle mode da social network. E nei sistemi basati su agenti la stabilità del formato di scambio dati è un vantaggio competitivo, non un dettaglio opzionale.
Il paradosso è che ogni innovazione davvero utile nasce quando la comunità decide di non farsi distrarre dall’hype. Le soluzioni migliori emergono da un approccio metodico, non da uno slogan. Ciò non significa che TOON non abbia potenziale. Qualunque idea che esplora nuove forme di rappresentazione dei dati merita un’analisi seria. Il problema non è la sperimentazione. Il problema è la narrativa che pretende di vendere un risultato prima ancora che l’esperimento sia stato completato. Una comunità matura dovrebbe essere capace di accogliere la sperimentazione senza confonderla con la produzione.
La tentazione di risparmiare token è comprensibile. I contesti crescono. Le interazioni con gli LLM diventano più dense. Gli agenti eseguono compiti più complessi. Ma la risposta non sta sempre in un nuovo formato. Sta spesso nel modo in cui si organizza l’informazione. L’ottimizzazione non richiede per forza di reinventare la ruota. Richiede di capire dove la ruota spreca energia. Lavorare su JSON in modo strategico permette di mantenere compatibilità totale e allo stesso tempo ridurre il carico. È una via meno glamour ma molto più pratica. In fondo, la vera innovazione raramente ha bisogno di fanfare. Ha bisogno di ingegneria.
La discussione attorno al formato TOON offre un piccolo specchio del nostro settore. Da un lato l’ingegno, dall’altro la tentazione di esagerare. Una citazione attribuita a Feynman dice che la tecnologia deve essere giudicata con severità, perché la natura non perdona le illusioni. Lo stesso vale nel software. Se un formato vuole cambiare davvero il modo in cui interagiamo con gli LLM, deve mostrare risultati chiari. Deve offrire un guadagno tangibile in termini di compressione senza penalizzare l’apprendimento. Deve inserirsi in un ecosistema complesso senza aumentare gli attriti. Deve convincere non con i thread virali, ma con i benchmark. Finché questo non accade, il formato resta un esercizio interessante, non una rivoluzione.
Il dibattito continuerà, com’è naturale che sia. La comunità ama sperimentare, testare, confrontare. Ma in mezzo al rumore conviene ricordare un principio semplice: risparmiare token è utile, perdere compatibilità è disastroso. L’innovazione ha bisogno di rigore più che di slogan. Il resto è rumore di fondo che accompagna ogni ciclo tecnologico.