Come l’architettura del pensiero umano diventa il collo di bottiglia dell’intelligenza artificiale
L’arrivo di CodeSpeak — progetto guidato da Andrey Breslav, creatore di Kotlin — riaccende un dibattito che nel settore IT ribolle da mesi: il modo in cui comunichiamo con i Large Language Model è davvero efficiente? Questo articolo sostiene che né il linguaggio naturale né i linguaggi di programmazione tradizionali sono strumenti ottimali per istruire un LLM. Entrambi nascono per essere letti e scritti da esseri umani, e portano con sé un bagaglio strutturale — ambiguità semantica, ridondanza sintattica, overhead di token — che trasforma ogni interazione con un modello linguistico in un dispendio di risorse evitabile. CodeSpeak è un passo nella direzione giusta, ma pone domande nuove più di quante ne risolva. La vera sfida non è trovare un linguaggio migliore: è ripensare l’intera architettura della comunicazione uomo-macchina.
1. Introduzione
L’altro giorno, mentre lavoravo su un progetto Azure con Copilot integrato nell’IDE, ho avuto una di quelle illuminazioni fastidiose — quelle che arrivano nel momento sbagliato e non te ne vanno più. Stavo correggendo per la terza volta lo stesso prompt per ottenere una funzione Python decente, riscrivendo la richiesta in modo sempre più esplicito, sempre più dettagliato, sempre più… verboso. Ad un certo punto mi sono fermato e mi sono chiesto: ma con chi sto davvero parlando?
Con un sistema che non capisce le parole come le capisco io. Con un motore statistico straordinariamente potente che opera su token, probabilità e co-occorrenze. E io, veterano del settore dai tempi del dial-up, stavo usando il linguaggio di Shakespeare per parlare con una macchina di Von Neumann potenziata da trasformatori.
È allora che la notizia di CodeSpeak — il nuovo progetto di Andrey Breslav, lo stesso che ci ha dato Kotlin — mi ha colpito in pieno. Non perché sia la soluzione. Ma perché dimostra che anche i migliori ingegneri del pianeta stanno cercando di uscire dalla stessa trappola in cui mi trovo io ogni giorno.
La domanda che voglio esplorare in questo articolo è scomoda: il linguaggio con cui parliamo agli LLM è fondamentalmente sbagliato?
2. Background: Trent’anni di Astrazione, e Siamo Ancora Qui
Cosa si intende per “inefficienza del linguaggio” in ambito LLM?
Per rispondere, bisogna fare un passo indietro. La storia dell’ingegneria del software è, in sostanza, la storia di un tentativo continuo di allontanarsi dall’hardware senza perdere il controllo del comportamento del sistema. Dal linguaggio macchina all’assembly, dall’assembly al C, dal C agli ambienti orientati agli oggetti, fino ai DSL (Domain Specific Language) e agli strumenti di modellazione UML: ogni generazione ha spostato il livello di astrazione un po’ più in alto.
Dal linguaggio C agli strumenti di modellazione UML, la storia dell’ingegneria del software è attraversata da tentativi di spostare il livello di astrazione sempre più lontano dall’hardware. L’interesse verso questa direzione si è riacceso con l’arrivo degli LLM, che mostrano capacità sorprendenti nella generazione di codice in più linguaggi.
Il punto critico è questo: ogni linguaggio di programmazione che conosciamo — Python, JavaScript, Go, Rust, Kotlin — è stato progettato per essere leggibile dagli esseri umani. La sintassi, le parole chiave in inglese, la struttura a blocchi indentati: tutto serve alla mente umana, non alla macchina. Il compilatore o l’interprete traducono comunque tutto in qualcosa di radicalmente diverso.
Nella mia esperienza di oltre trent’anni in ambito IT — ho visto nascere e morire linguaggi interi — posso affermare con una certa serenità che nessun linguaggio di programmazione esistente è stato progettato avendo in mente un Large Language Model come interlocutore primario. Ed è proprio qui che nasce il problema.
3. Analisi Scientifica
3.1 Il problema dei token: quando il codice “pesa” troppo
Perché i linguaggi di programmazione tradizionali sono inefficienti per un LLM?
Un LLM non vede righe di codice. Vede token. Quando si usa un modello linguistico di grandi dimensioni (LLM), il testo viene prima suddiviso in unità denominate token, ovvero parole, set di caratteri o combinazioni di parole e punteggiatura, da un tokenizer. L’LLM analizza le relazioni semantiche tra i token, ad esempio la frequenza con cui vengono usate insieme o se vengono usate in contesti simili.
Il problema è che il codice sorgente scritto per gli umani — con i suoi commenti, i suoi nomi di variabile descrittivi, le sue strutture ripetitive di boilerplate — genera un numero di token sproporzionato rispetto all’informazione semantica effettiva che veicola.
I servizi di intelligenza artificiale generativi spesso usano prezzi basati su token: il costo di ogni richiesta dipende dal numero di token di input e output. Questo significa che ogni token di ridondanza sintattica è un token pagato — in denaro, in latenza, in qualità della risposta.
Il fenomeno ha persino un nome tecnico: token fertility. I ricercatori Moroni et al. (arXiv:2504.17025, aprile 2025) hanno dimostrato come la “token fertility” — il numero di token necessari per codificare lo stesso contenuto — sia un problema strutturale degli LLM non ottimizzati per un certo dominio linguistico. Applicando tecniche di vocabulary adaptation su Mistral-7b, sono riusciti a ridurre la token fertility del 25%.
Se questo vale per le lingue naturali, vale ancora di più per i linguaggi di programmazione: sintassi verbose come Java o C# generano quantità enormi di token per esprimere concetti relativamente semplici.
3.2 Il problema semantico: gli LLM non “capiscono” il codice
Gli LLM comprendono davvero il codice che leggono e generano?
Qui arriviamo al nucleo più critico della questione. Il Prof. Roberto Navigli (Sapienza Università di Roma) afferma esplicitamente che “gli LLM non ragionano davvero sul linguaggio: assemblano frasi basandosi su probabilità, non su una reale comprensione”. La comprensione del linguaggio da parte degli LLM è “molto più fragile di quanto sembri”: gli LLM si basano su un’immensa quantità di dati testuali e su sofisticati meccanismi di previsione delle parole, ma il loro modo di “comprendere” il linguaggio è essenzialmente statistico.
Questo vale doppiamente per il codice. Un LLM che genera una funzione Python non “comprende” la logica algoritmica nel senso umano: riconosce pattern statistici nel corpus di addestramento e li ricombina. La struttura sintattica del linguaggio di programmazione è pensata per guidare il compilatore e la mente dello sviluppatore — non per comunicare intento a un sistema probabilistico.
Di fatto, la scrittura di codice di programmazione mette in crisi una nozione debole di plausibilità linguistica, che invece è strettamente legata sia alla forma induttiva dei modelli, sia alla variabilità in cui si esprimono i significati nel linguaggio naturale.
In altre parole: il codice è troppo rigido per essere linguaggio naturale, ma troppo semanticamente ambiguo per essere un linguaggio formale che un LLM possa trattare con affidabilità assoluta.
3.3 Il problema del context window: il codice affoga
Cosa succede quando un progetto software reale entra nel context window di un LLM?
Una delle sfide più sottovalutate nella costruzione di applicazioni LLM è la gestione del context window. Ogni LLM ha un limite su quanto testo può elaborare in una singola richiesta. Una gestione inefficiente del contesto porta a: risposte irrilevanti o errate, costi di token aumentati, tempi di risposta più lenti, perdita di informazioni importanti. In sistemi in produzione, questo impatta direttamente user experience, costi infrastrutturali e affidabilità del sistema.
Un repository reale di medie dimensioni — diciamo 50.000 righe di Python con commenti, docstring e test — occupa un context window enorme. La maggior parte di quel testo è rumore sintattico dal punto di vista del modello: parentesi, indentazioni, dichiarazioni di import, nomi di variabile verbose che servono alla leggibilità umana ma aggiungono token senza aggiungere semantica.
Piccole ottimizzazioni nel prompt possono ridurre i costi del 30-50%. Sistemi ben ottimizzati possono arrivare a risparmiare fino al 70% mantenendo la qualità delle risposte. Questo dato da solo dovrebbe far riflettere: se il 70% dei token che inviamo a un LLM è eliminabile senza perdita di qualità, vuol dire che stiamo comunicando in modo strutturalmente inefficiente.
3.4 CodeSpeak: la risposta di Breslav
Cos’è CodeSpeak e perché nasce?
CodeSpeak è un’iniziativa guidata da Andrey Breslav, noto per aver creato il linguaggio Kotlin. L’obiettivo dichiarato consiste nel costruire un ambiente di sviluppo in cui il vero artefatto di progetto non sia il codice sorgente ma una descrizione strutturata del comportamento del sistema. A partire da tali specifiche, un modello linguistico produce e aggiorna automaticamente le implementazioni in linguaggi tradizionali come Python, Go e JavaScript.
CodeSpeak si definisce un linguaggio di programmazione di nuova generazione alimentato da LLM. Compila verso codice in linguaggi tradizionali come Python, Go, JS/TS (fonte: codespeak.dev).
Il meccanismo è elegante: lo sviluppatore scrive file di descrizione in linguaggio naturale strutturato, spesso in formato Markdown o simili, nei quali definisce il comportamento atteso. Il sistema di generazione analizza tali documenti e li trasforma in codice eseguibile utilizzando modelli linguistici. Quando una specifica cambia, lo strumento calcola le differenze (diff) tra le versioni del documento e produce una modifica corrispondente nell’implementazione.
I dati dichiarati dal progetto sono ambiziosi: CodeSpeak può ridurre le codebase di 5-10 volte sostituendo il codice sorgente con “specifiche”.
Devo ammettere che, leggendo di CodeSpeak per la prima volta, ho avuto un momento di genuino entusiasmo. Poi — come mi accade spesso dopo trent’anni di hype tecnologici — sono arrivate le domande.
3.5 I limiti di CodeSpeak: risolve il problema o lo sposta?
Il progetto di Breslav affronta un sintomo reale, ma rischia di non toccare la causa profonda. Il “linguaggio naturale strutturato” con cui si scrivono le specifiche in CodeSpeak è comunque un linguaggio progettato per gli umani — Markdown, frasi in inglese, descrizioni comportamentali. L’LLM che le elabora si trova nella stessa situazione di prima: deve inferire intento semantico da testo ambiguo, con tutti i rischi che ne derivano.
Il meccanismo alla base di CodeSpeak differisce da molti sistemi di generazione di codice basati su prompt. In quei casi la richiesta inviata al modello rimane spesso temporanea e difficilmente tracciabile. L’uso di file di specifica persistenti consente invece di mantenere uno storico delle istruzioni che hanno portato alla creazione del software, facilitando audit e revisione del processo di sviluppo.
Questo è un valore reale — la tracciabilità delle specifiche è un problema serio nell’ingegneria del software. Ma non risolve il problema fondamentale: il linguaggio rimane umano, quindi ambiguo, ridondante e semanticamente pesante per il modello.
Un vero linguaggio ottimizzato per LLM dovrebbe avere caratteristiche opposte a quelle dei linguaggi umani: massima densità semantica per token, assenza di ambiguità contestuale, struttura formale verificabile. Qualcosa che si avvicina molto di più a un linguaggio logico formale — o a una rappresentazione intermedia vicina all’ontologia — che al Markdown.
4. Implicazioni Pratiche
Cosa significa tutto questo per chi lavora oggi con gli LLM?
Nella mia pratica quotidiana con Azure AI e i vari Copilot integrati negli strumenti di sviluppo, vedo ogni giorno le conseguenze concrete di questa inefficienza. Il tempo speso a prompt-engineering — a riscrivere, affinare, ristrutturare le richieste — è di fatto il tempo che pago per colmare il gap tra il mio linguaggio e quello che il modello sa elaborare efficacemente.
Le implicazioni sono almeno tre:
1. Costo computazionale ed economico. Ogni token in eccesso è costo diretto. In scenari enterprise con migliaia di chiamate API giornaliere, l’inefficienza comunicativa si traduce in fatture significative. Non è un problema accademico: è un problema di P&L.
2. Qualità e affidabilità dei risultati. La performance di un LLM dipende dalla densità e dalla posizione delle informazioni chiave nel prompt. Strumenti come LinguaShrink (IEEE, 2024) sfruttano principi psicolinguistici per comprimere i prompt in modo task-agnostico, migliorando la qualità delle risposte riducendo il rumore. In altre parole: meno ridondanza, migliori risposte.
3. Scalabilità dei sistemi agentici. Gli agenti AI che operano in autonomia su codebase reali si trovano di fronte a context window che si saturano rapidamente. Senza un linguaggio di comunicazione più efficiente, la scalabilità degli agenti è strutturalmente limitata dal peso sintattico del codice che devono elaborare.
CodeSpeak può ridurre il volume del codice da mantenere. Ma finché la specifica rimane scritta in linguaggio umano, il bottleneck semantico non scompare — si sposta semplicemente un livello più in alto.
5. Conclusioni
La vera sfida non è tecnica. È concettuale.
Stiamo cercando di usare strumenti nati per la comunicazione tra esseri umani — i linguaggi di programmazione, il linguaggio naturale — per istruire sistemi che non funzionano come esseri umani. CodeSpeak è un segnale importante: anche i migliori ingegneri del settore sentono l’esigenza di un cambio di paradigma. Ma un “linguaggio naturale strutturato” rimane, fondamentalmente, naturale.
I dati suggeriscono che fino al 70% dei token che inviamo agli LLM potrebbe essere eliminato senza perdita di significato. Questo non è un margine di ottimizzazione: è un’indictment del modo in cui stiamo comunicando con questi sistemi.
La prossima frontiera non è un linguaggio migliore per gli umani. È progettare la comunicazione uomo-LLM partendo dai vincoli del modello, non da quelli dell’utente. Un’impresa che richiederà non solo ingegneri come Breslav, ma anche linguisti, logici e — perché no — qualche veterano IT con abbastanza cicatrici per sapere dove guarda il lupo.
Riferimenti
- Moroni, L., Puccetti, G., Huguet Cabot, P. L., et al. (2025). Optimizing LLMs for Italian: Reducing Token Fertility and Enhancing Efficiency Through Vocabulary Adaptation. arXiv:2504.17025 [cs.CL]. https://doi.org/10.48550/arXiv.2504.17025
- LinguaShrink: Reducing Token Overhead With Psycholinguistics. (2024). IEEE Xplore. DOI: 10.1109/10699333
- Navigli, R. (intervista). (2025, maggio). LLM e semantica: il grande inganno dell’intelligenza artificiale. Rivista AI / aihub.org.
- Nasi, M. (2026, 13 marzo). CodeSpeak, il creatore di Kotlin presenta un linguaggio per parlare con le AI. ilsoftware.it.
- Breslav, A. et al. (2026). CodeSpeak: Software Engineering with AI. https://codespeak.dev/
- Microsoft Learn. (2026). Informazioni sui token. https://learn.microsoft.com/it-it/dotnet/ai/conceptual/understanding-tokens
Rispondi