Caveman: l'AI che parla come un cavernicolo conviene
Yabba-dabba-doo! Ricordate Fred Flintstone? Abitava a Bedrock, guidava un'auto spinta a piedi nudi, aveva un dinosauro come gru e uno pterodattilo come giradischi. Eppure, a guardarla bene, quella civiltà dell'età della pietra era già in possesso di tutto il necessario per una vita moderna confortevole, congegni funzionanti, tecnologia efficiente, soluzioni pratiche. Mancava solo la patina luccicante del progresso. Forse avremmo dovuto capire già allora che l'essenziale basta, e che aggiungere complessità non significa necessariamente aggiungere valore.
Julius Brussee, sviluppatore olandese, sembra aver riletto la lezione con occhi nuovi. Il suo progetto Caveman, disponibile su GitHub sotto licenza MIT, fa una cosa sola: costringe il modello a rispondere come un cavernicolo. Niente articoli, niente convenevoli, niente frasi di riscaldamento. Solo il nocciolo tecnico, espresso nel modo più diretto possibile.
Il problema che Caveman cerca di risolvere è reale, e chiunque lavori con modelli linguistici a pagamento lo conosce bene. Ogni risposta di un LLM ha un costo misurato in token, le unità elementari in cui il modello scompone e ricompone il linguaggio, qualcosa di intermedio tra sillaba e parola. Via API, i token di output sono generalmente più costosi di quelli di input, e i modelli moderni tendono a essere generosi con le parole: introducono ogni risposta con formule di cortesia, precisano l'ovvio, ripetono il contesto già noto, concludono con un riepilogo di ciò che hanno appena detto. È prolissità sistemica, addestrata per anni su feedback umani che spesso premiavano la completezza apparente sulla concisione reale.
Prendiamo un esempio concreto, lo stesso riportato nella documentazione ufficiale del progetto. La risposta standard di Claude a un problema di re-rendering in React suona più o meno così: "The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow comparison sees it as a different object every time, which triggers a re-render. I'd recommend using useMemo to memoize the object." Sessantanove token. In modalità Caveman la stessa informazione diventa: "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`." Diciannove token. Stessa diagnosi, stessa soluzione, tre volte e mezzo meno parole.
Come funziona
Tecnicamente, Caveman è un file.md da installare nell'ambiente dell'agente prescelto con un singolo comando.
Una volta installato, il tool si attiva su richiesta, tramite il comando /caveman o $caveman su Codex, e la frase "talk like caveman", "caveman mode" o semplicemente "less tokens please", e si disattiva con "stop caveman" o "normal mode". Si tratta di un insieme di istruzioni contestuali che modificano il comportamento del modello all'interno di una sessione, senza riaddestrarlo né modificarne i parametri interni.
A questo si affianca un secondo strumento, /caveman:compress, che agisce sul versante opposto: invece di comprimere le risposte del modello, comprime i file di contesto, ad esempio Claude lo carica ad ogni sessione, tipicamente CLAUDE.md e i file di note di progetto. Il comando riscrive questi file in stile cavernicolo e ne conserva automaticamente una copia leggibile come backup (CLAUDE.original.md). Tutto ciò che è tecnico, blocchi di codice, URL, percorsi di file, comandi, intestazioni, date, numeri di versione, passa invariato; solo la prosa descrittiva viene compressa. I benchmark del progetto su cinque tipi di file reali mostrano una riduzione media del 46% dei token di input per sessione, con un picco del 59,6% sui file di preferenze.
Il cuore del meccanismo è un insieme di vincoli grammaticali e stilistici che il commento di un utente su Hackaday ha riassunto in modo preciso: si eliminano gli articoli determinativi e indeterminativi, si sopprimono i riempitivi linguistici (just, really, basically, actually), si cancellano i convenevoli (sure, certainly, of course, happy to), si privilegiano sinonimi brevi (big invece di extensive, fix invece di implement a solution for), si vieta l'uso delle forme di esitazione (it might be worth considering). I frammenti di frase sono accettabili. Non serve il soggetto se è implicito. La terminologia tecnica, invece, rimane intatta: polymorphism resta polymorphism, i blocchi di codice sono scritti normalmente, i messaggi di errore vengono citati verbatim. Come recita il README del progetto con autoironia: "Caveman not dumb. Caveman efficient."
Questa distinzione è fondamentale per capire cosa Caveman fa davvero. Non è un compressore che tronca le risposte a metà, né uno strumento che semplifica i concetti per renderli più digeribili. È un filtro che elimina il surplus comunicativo, quelle frasi che i modelli producono non perché contengano informazione utile, ma perché il loro addestramento, basato su valutazioni umane che tendono a premiare risposte elaborate e cortesi, li ha spinti in quella direzione. Caveman si comporta come un editor severo che cancella tutto ciò che non aggiunge valore tecnico, lasciando sul foglio solo quello che serve.
Il progetto ha aggiunto nel frattempo una granularità che lo rende più adattabile di quanto la premessa cavernicola lasciasse intuire. Sono disponibili tre livelli di intensità selezionabili con trigger dedicati: /caveman lite mantiene la grammatica intatta ed elimina solo il riempitivo, restituendo un output professionale ma asciutto, adatto a contesti dove la forma conta ancora; /caveman full è la modalità predefinita, quella che rimuove articoli, accetta i frammenti di frase e punta al nocciolo tecnico senza mediazioni; /caveman ultra spinge al massimo la compressione, con uno stile telegrafico che abbrevia tutto il comprimibile.
Il livello selezionato persiste per l'intera sessione fino a cambio esplicito. Ma la sorpresa più inattesa è un'altra: il README del progetto documenta anche una modalità in cinese classico letterario, il wenyan (文言文), la lingua scritta usata in Cina per oltre duemila anni fino al Novecento, notoria per una densità semantica che non ha equivalenti nelle lingue moderne. L'idea non è folkloristica: il wenyan è oggettivamente uno dei sistemi di scrittura più token-efficienti mai inventati dall'umanità, e Brussee lo ha integrato con la stessa logica progressiva dei livelli latini, da /caveman wenyan-lite, che mantiene la grammatica ma elimina il superfluo, fino a /caveman wenyan-ultra, che il README descrive con una certa ironia come la modalità dell'antico studioso a corto di budget. Certo, con il wenyan, il risparmio è estremo, ma bisogna poi capire ciò che scrive...
I dati di benchmark riportati sulla pagina del progetto indicano riduzioni variabili a seconda del tipo di task: dall'87% sui problemi di re-rendering React all'83% sul debugging di middleware di autenticazione, all'81% su condizioni di race condition in PostgreSQL, fino al 58% per spiegazioni di git rebase vs merge e al 41% per revisioni di sicurezza su pull request. La media dichiarata si assesta intorno al 65% di riduzione dei token di output. È importante notare che questi numeri riguardano esclusivamente i token di output, non l'intera sessione: i token di input, quelli del contesto, delle istruzioni di sistema e delle chiamate agli strumenti rimangono invariati e possono rappresentare una quota significativa del costo complessivo, specie in sessioni lunghe o con molte chiamate a tool esterni.
La scienza del silenzio
Fin qui si potrebbe liquidare Caveman come un trucchetto simpatico, uno di quei micro-progetti che girano su GitHub per qualche giorno e poi scompaiono. Quello che lo rende interessante da un punto di vista più ampio è la sua connessione con una letteratura scientifica emergente che studia il rapporto tra brevità e prestazioni dei modelli linguistici, e i risultati di quella letteratura sono, per dirla con misura, controintuitivi.
Il paper di riferimento è "Brevity Constraints Reverse Performance Hierarchies in Language Models", pubblicato l'11 marzo 2026 da MD Azizul Hakim su arXiv. Lo studio parte da un'osservazione anomala: su un sottoinsieme pari al 7,7% dei problemi valutati, distribuiti su cinque dataset diversi, i modelli linguistici più grandi ottengono risultati peggiori dei modelli più piccoli di ben 28,4 punti percentuali, nonostante dispongano di un numero di parametri da 10 a 100 volte superiore.
Il meccanismo individuato come causa è quello che il paper chiama scale-dependent verbosity, una prolissità che cresce all'aumentare della dimensione del modello. I modelli più grandi tendono a sovraelaborare le risposte, aggiungendo passaggi di ragionamento, qualifiche e digressioni che non migliorano la risposta finale, spesso la peggiorano introducendo errori per eccesso di elaborazione. Imporre ai modelli grandi di rispondere in modo conciso migliora la loro accuratezza di 26,3 punti percentuali, riducendo il divario con i modelli piccoli del 67%, mentre i modelli piccoli, sottoposti allo stesso vincolo, subiscono un calo di soli 3,1 punti percentuali.
Il risultato più sorprendente riguarda specifici benchmark. Su GSM8K, il dataset di ragionamento matematico, e su MMLU-STEM, quello di conoscenza scientifica, i vincoli di brevità invertono completamente la gerarchia di prestazioni: i modelli grandi, che in condizioni normali si comportavano peggio dei piccoli, arrivano a superarli di 7,7-15,9 punti percentuali. In altri termini, la capacità superiore era già lì, ma veniva mascherata dalla tendenza a ragionare ad alta voce in modo eccessivo. La brevità non comprime il ragionamento, lo libera dall'involucro verboso che lo soffoca.
Va però registrata una nota di cautela che lo studio stesso introduce con onestà: su BoolQ, il dataset che richiede integrazione di informazioni distribuite su più frasi, i vincoli di brevità aumentano leggermente il divario invece di ridurlo, dal 23,5% al 24,3%. Su questo tipo di problemi l'elaborazione estesa è funzionale, non eccessiva: troncarla peggiora il risultato. Non si tratta di un risultato universale, ma contesto-dipendente, e questa sfumatura è cruciale per non fraintendere cosa il paper dimostra.
L'ipotesi proposta dagli autori per spiegare la tendenza alla prolissità nei modelli grandi è che il processo di allineamento tramite feedback umano (RLHF) abbia inavvertitamente addestrato questi modelli a sovra-elaborare, poiché i valutatori umani tendono a premiare risposte lunghe e apparentemente complete, creando un bias sistematico che scala con la dimensione del modello. È una spiegazione plausibile e coerente con altri fenomeni noti nell'addestramento dei modelli, anche se rimane un'ipotesi interpretativa da verificare ulteriormente.
Il mammut nella stanza
Dati alla mano, Caveman funziona, almeno in certi contesti. Il risparmio dichiarato è reale e misurabile, la base scientifica esiste e non è banale, il meccanismo tecnico è trasparente e verificabile da chiunque. Ma un'analisi onesta richiede di mettere sul tavolo anche le riserve, e ce ne sono diverse.
La prima riserva riguarda la qualità delle risposte su task complessi. Una risposta più corta è sempre una risposta migliore? Il paper di Hakim dice di no in modo esplicito per certi tipi di problemi, e l'intuizione è verificabile nella pratica quotidiana. Quando si lavora su un bug oscuro, su un problema di architettura con molte variabili, su codice legacy mal documentato, una risposta che spiega il ragionamento passo per passo ha un valore che va oltre la quantità di informazione strettamente necessaria: aiuta a capire, a verificare, a costruire un modello mentale. Tagliare quella spiegazione in nome dell'efficienza può costringere a più iterazioni, a più domande di chiarimento, a più tempo perso, vanificando il risparmio iniziale.
Questo porta alla seconda riserva, quella relativa all'esperienza utente differenziata. Per uno sviluppatore senior che usa un agente come acceleratore, che conosce il codice su cui lavora e ha bisogno di conferme rapide più che di spiegazioni, Caveman è probabilmente un guadagno netto. Per un junior che usa l'assistente anche per imparare, per qualcuno che affronta un dominio tecnico nuovo, o per chi usa agenti in contesti che esulano dal puro coding, come scrittura tecnica, analisi di sicurezza, assistenza a decisioni architetturali, la sintesi eccessiva può aumentare il carico cognitivo e generare più confusione che chiarezza.
Infine, vale la pena ricordare che le prove scientifiche disponibili sostengono il principio della brevità come vincolo utile, non validano specificamente Caveman come implementazione. Il paper di Hakim è stato pubblicato su arXiv, ancora in fase di pre-print al momento della scrittura di questo articolo, e non ha ancora ricevuto una revisione formale da parte della comunità accademica. Il tool di Brussee ha attirato l'attenzione della community tech con 33.5k stelle su GitHub in pochi giorni, e questo non può essere sottovalutato, ma non è stato oggetto di una valutazione indipendente e sistematica da parte di terzi. Sono segnali di interesse genuino, non di validazione certificata.
Pietra di volta o meteora?
La domanda più interessante che Caveman pone non è tecnica, è metodologica. Se i modelli linguistici più potenti tendono strutturalmente a rispondere in modo più prolisso, e se quella prolissità è spesso dannosa sia per i costi che, sorprendentemente, per la qualità delle risposte su certi tipi di problemi, allora il problema non è di Caveman: è del modo in cui questi modelli vengono addestrati e valutati.
Il paper di Hakim propone un approccio che chiama problem-aware routing: usare modelli piccoli per i task dove naturalmente eccellono o dove i vincoli di brevità non aiutano i modelli grandi, e usare modelli grandi con vincoli di brevità per i task dove possiedono capacità latenti superiori ma sono inclini alla sovra-elaborazione. Questo approccio, dicono gli autori, può migliorare simultaneamente accuratezza e costi. Non è fantascienza: è una forma di ingegneria del prompt consapevole della scala del modello, un'idea che potrebbe diventare pratica corrente nei flussi di lavoro agentici professionali.
In questo senso, Caveman non è semplicemente un trucco per risparmiare qualche centesimo sull'API. È una dimostrazione pratica di un principio che la ricerca sta iniziando a formalizzare: che le istruzioni di sistema non sono decorative, che il modo in cui un modello viene interrogato cambia non solo la forma ma la qualità della risposta, e che ottimizzare l'interfaccia uomo-macchina ha conseguenze misurabili sulle prestazioni del sistema complessivo.
Rimangono aperte domande legittime. Il pattern si trasferisce davvero a tutti i tipi di task o solo a quelli strutturati del coding? Come si misura il ROI netto quando si include nel calcolo il costo delle iterazioni aggiuntive che una risposta troppo sintetica può generare? Quanto incide la familiarità dell'utente con il dominio tecnico nel determinare se la brevità è un vantaggio o uno svantaggio? E, tornando alla grande domanda di fondo: se la brevità migliora le prestazioni, perché i modelli non vengono addestrati in modo nativo a rispondere in modo più conciso?
Quest'ultima è forse la più importante, e la risposta implicita nel paper di Hakim è scomoda: perché il feedback umano su cui si basa l'allineamento di questi modelli preferisce spesso la lunghezza alla precisione, la cortesia alla densità informativa. Siamo noi, come valutatori, come utenti, come committenti, ad aver addestrato i modelli alla prolissità. Caveman è, in fondo, un correttivo artigianale a un problema sistemico che nasce molto più a monte.
Fred Flintstone, probabilmente, aveva già capito tutto. Caverna piccola, strumenti essenziali, risultato grande. Il resto è solo pietra in più da trascinare.