Non vi preoccupate: non sono impazzito, il titolo è sarcastico ma l’articolo cerca di discutere su un punto “cruciale” (metto parole stile chatGPT a caso, così non potrete mai capire se sono io o lui che scriviamo determinate frasi). Il punto è: per un modello AI, non sarebbe meglio programmare in un linguaggio meno umano e più vicino alla sua logica e comprensione?

L’intelligenza artificiale sta imparando a scrivere codice talmente bene che potrebbe iniziare a farlo in una lingua comprensibile solo a lei stessa. Non è fantascienza, ma il risultato di una nuova ricerca intitolata “AI Coders Are Among Us” (letteralmente, “I programmatori AI sono tra di noi”) che propone di ottimizzare la grammatica dei linguaggi di programmazione per le esigenze delle AI. In altre parole, dato che i modelli di intelligenza artificiale possono ormai programmare quasi come (e a volte meglio di) un essere umano, perché dovrebbero sottostare ai nostri standard di sintassi e leggibilità?

Gli autori sottolineano che oggi la grammatica e la formattazione del codice sorgente sono pensate per i programmatori umani, e questo introduce molti token superflui dal punto di vista di un modello di AI, cioè simboli e spazi che servono solo a migliorare la leggibilità per noi ma appesantiscono l’elaborazione per loro. D’altronde le AI “sviluppatrici” sono già una realtà: sistemi come AlphaCode hanno dimostrato di saper risolvere problemi di programmazione meglio del 85% dei partecipanti umani a competizioni di coding. Se le AI sono diventate dei coder a tutti gli effetti, è lecito chiedersi: ha ancora senso che il codice sia scritto a misura di essere umano?

La grammatica umana è un peso per l’AI?

Chiunque abbia programmato conosce l’importanza di scrivere codice pulito e leggibile. Linguaggi come Python sono stati progettati con il mantra “leggibilità prima di tutto” (“readability counts” è uno dei motti del Zen of Python), inserendo spazi, identazioni, parentesi e delimitatori proprio per rendere il codice chiaro agli umani. Ma tutte queste finezze stilistiche sono completamente perdite di tempo per un modello di AI. Un Large Language Model (LLM) quando genera o analizza codice lo fa token dopo token, carattere dopo carattere, e ogni elemento aggiuntivo (che a noi serve per estetica o chiarezza) per il modello è solo rumore da macinare consumando cicli di calcolo. Studi citati dai ricercatori confermano che i modelli di coding ignorano in gran parte gli aspetti di formattazione: ad esempio simboli di pura sintassi come i due punti “:” ricevono molta meno attenzione nei modelli rispetto a elementi significativi come i nomi delle variabili. Quindi, dal punto di vista di un’AI, tutti quegli spazi e abbellimenti che rendono felice il lavoro agli ingegneri umani non sono altro che zavorra.

Questa “zavorra” comporta anche un costo economico ed energetico non indifferente. I modelli LLM attuali sono assetati di calcolo, e ridurre il numero di token da generare o analizzare può far risparmiare tempo ed energia in proporzione. In un’epoca in cui eseguire modelli come GPT-4 costa moltissimo e mette in crisi i provider di AI sul fronte dei profitti, trovare modi per snellire i processi è fondamentale. E allora, perché non ripensare la grammatica dei linguaggi di programmazione da zero, eliminando tutto ciò che serve solo agli umani? È esattamente la domanda posta dagli autori: qual è una grammatica adatta ai modelli di AI?

La risposta proposta è radicale: creare una AI-Oriented Grammar, ovvero una grammatica pensata per le AI invece che per gli umani.

Nasce SimPy: Python a misura di intelligenza artificiale

Per dimostrare che non si tratta solo di teoria, i ricercatori hanno realizzato un prototipo concreto di linguaggio “a misura di AI”: una variante di Python battezzata SimPy (abbreviazione di Simple Python). SimPy è sostanzialmente Python senza fronzoli, in cui la sintassi è stata modificata per minimizzare i token necessari a esprimere un algoritmo. Come funziona in pratica? In breve, niente spazi o newline significativi e meno simboli. Dal punto di vista formale, gli autori hanno rivisto le regole grammaticali di Python 3.12 applicando varie semplificazioni:

• Via gli spazi e le indentazioni: in SimPy non esistono caratteri di whitespace significativi né cambi di linea a separare le istruzioni. Ad esempio, invece di usare l’indentazione per definire i blocchi di codice (come in Python normale), si può usare un token speciale di inizio/fine blocco o altra notazione compatta. Il codice può teoricamente stare tutto su una riga senza ambiguità di parsing.
• Parole chiave e simboli compressi: molte keyword e operatori vengono rimpiazzati da token unici. Ad esempio, il simbolo di confronto >= potrebbe diventare un singolo token placeholder eliminando così la necessità di avere spazi attorno. Allo stesso modo, parole riservate come if, for, while sono incorporate in token speciali che fanno anche da delimitatori di blocco, rimuovendo la necessità di scrivere : a fine riga. Il risultato è una sintassi più compatta ma equivalente come semantica.
• Delimitatori essenziali soltanto: sono stati eliminati o accorpati i delimitatori testuali considerati ridondanti. Un esempio citato è la parentesi attorno ai parametri di funzione: in SimPy non servono, perché la struttura può essere capita dal parser senza quei caratteri. Anche i due punti che seguono l’if o altri costrutti vengono omessi, sostituiti da token di inizio blocco implicito. Ogni elemento della grammatica è stato valutato e snellito, fin dove possibile senza introdurre ambiguità.

Il bello è che, nonostante queste drastische potature, un programma scritto in SimPy fa esattamente le stesse cose del corrispondente Python. La Abstract Syntax Tree (AST) risultante è identica a quella del codice Python originale. In altre parole, SimPy è solo una diversa veste sintattica: sotto il cofano, la logica e gli elementi semantici restano quelli di Python. Ciò significa che è possibile convertire automaticamente qualsiasi codice Python in SimPy e viceversa senza perdita di informazione, grazie a un convertitore sviluppato ad hoc. Gli autori hanno infatti creato un parser dedicato in grado di tradurre il sorgente SimPy direttamente in un AST Python standard, e un tool per la trasformazione inversa. Questo garantisce che gli sviluppatori umani possano continuare a scrivere in Python normale, mentre l’AI usa SimPy, senza che nessuno dei due “soffra” la differenza.

E i benefici promessi? Meno token da elaborare = meno fatica per la macchina. I test mostrano che, rispetto al Python tradizionale, SimPy riduce il numero di token di circa il 10-13% per modelli come GPT-4 e CodeLlama. In certi casi specifici la riduzione può arrivare fino al 30% dei token!. Meno token significa risposte generate più velocemente e minor consumo computazionale. Ancora più interessante, usare il codice in formato SimPy non peggiora affatto le prestazioni dei modelli nei compiti di coding, anzi in alcuni test le migliora leggermente. Per esempio, un modello CodeGen allenato in Python ottiene un certo punteggio in un benchmark di esercizi (HumanEval), ma se viene ri-addestrato in SimPy ottiene un punteggio superiore negli stessi task. Insomma, meno caratteri, più efficienza, senza perdere accuratezza. Missione compiuta? Sembrerebbe di sì, almeno in questo esperimento iniziale.

DualCode: il trucco per non far arrabbiare gli umani

Arrivati a questo punto, qualcuno potrebbe obiettare: “Benissimo l’ottimizzazione, ma poi questo SimPy chi lo legge? Noi umani di certo no!”. Infatti, un codice senza indentazioni, senza righe nuove, pieno di simboli strani al posto delle parole chiave, per un programmatore umano è indecifrabile o quasi (provate voi a leggere un programma tutto attaccato…).

I ricercatori sono ben consapevoli di questo problema di leggibilità e di accettazione da parte dei developers in carne e ossa. La soluzione proposta è una sorta di bilinguismo controllato, che chiamano DualCode. In pratica, l’idea è che l’AI e gli umani possano lavorare ognuno nel “dialetto” a loro più congeniale, grazie a un convertitore automatico rapido e invisibile.

Immaginiamo uno scenario con DualCode: il programmatore umano scrive codice in Python classico, con tutti i suoi bravi spazi, andate a capo e nomi comprensibili. Appena il codice deve essere passato al modello di AI (ad esempio ChatGPT o un’altra LLM integrata nell’IDE), entra in gioco il convertitore DualCode che traduce al volo quel sorgente in SimPy, cioè nella forma ultra-compatta che piace all’AI. L’AI elabora, genera magari ulteriori porzioni di codice (in formato SimPy), e prima di mostrarle all’umano il sistema le riconverte al volo in Python normale. Il risultato: l’AI dietro le quinte “parla” SimPy, ma il programmatore umano vede e tocca solo codice Python pulito. Tutti contenti 😇.

Gli esperimenti mostrano che questo approccio non introduce latenze significative: la conversione da Python a SimPy e viceversa è pressoché istantanea (meno di 1 millisecondo per poche centinaia di token), quindi non si percepisce rallentamento nell’interazione. In altre parole, il workflow potrebbe rimanere quello abituale (con l’IDE, i tool, etc.), ma sottobanco il codice viene continuamente “interpretato” e ri-formattato per compiacere l’AI. Questo è il trucco per rendere applicabile l’AI-oriented grammar anche fuori dai laboratori, nel mondo reale dove gli umani devono poter leggere e controllare il codice. È un po’ come avere un compagno di lavoro alieno che parla un suo gergo: invece di costringerci a imparare la sua lingua, usiamo un traduttore universale istantaneo così ognuno parla come gli è più comodo.

I programmatori saranno tagliati fuori dal loro stesso codice?

Tutto bene quindi? L’AI ottiene il suo linguaggio ottimizzato e i programmatori possono continuare a vivere felici nel loro Python vanilla, con un traduttore a fare da ponte. Fine della storia? Non proprio. Questa innovazione porta con sé alcuni interrogativi inquietanti sul futuro del rapporto tra umani, codice e AI.

C’è chi ipotizza che potremmo essere all’inizio di un percorso che renderà i linguaggi di programmazione umani obsoleti. Se le AI diventeranno i principali produttori e manutentori di software, che motivo ci sarà di mantenere sintassi verbose e “umane”?

Un commentatore azzarda un paragone storico: mantenere i linguaggi attuali per farli leggere agli umani potrebbe diventare come tenere in vita le carrozze dopo l’avvento delle automobili, una stranezza nostalgica per pochi appassionati. Il succo di questa provocazione è: l’AI non ha bisogno che il codice sia human-friendly, può lavorare con formati ottimizzati per sé stessa, e alla lunga mantenere due versioni (una per le macchine e una per gli umani) potrebbe risultare economicamente insensato. In scenari estremi, il codice potrebbe iniziare ad assomigliare a un “gibberish” illeggibile per noi, e la capacità di leggere il vecchio codice umano diventerebbe un’abilità di nicchia, un po’ come oggi saper programmare in COBOL è un talento da specialisti vintage. Fantascienza? Forse, ma è un ragionamento che dal punto di vista pratico/industriale qualche scomoda logica la fila.

D’altra parte, c’è anche la questione della fiducia e sicurezza. Se l’AI comincia a sfornare codice in una forma che gli umani non capiscono immediatamente, come facciamo a fidarci? Un conto è “minificare” il JavaScript in produzione (cosa già comune), un altro è che l’intera logica di un sistema sia comprensibile solo a un’AI. Alcuni esperti mettono in guardia: è importante che il codice rimanga ispezionabile e verificabile dagli umani, altrimenti rischiamo di introdurre falle o comportamenti indesiderati senza accorgercene. Insomma, un’AI che scrive programmi segreti potrebbe, magari non per cattiveria, sfuggire al nostro controllo più facilmente. Nel mondo della sicurezza informatica si insiste da anni sul principio che i sistemi automatici debbano produrre output interpretabile dall’uomo. Perciò, anche se tecnicamente l’AI-oriented grammar funziona, bisogna vedere se socialmente e professionalmente verrà accettata: i programmatori saranno disposti ad affidarsi a uno “stregone automatico” che incanta il codice in un lingua arcana?

Evoluzione o eresia del coding?

La proposta di SimPy e dell’AI-oriented programming è al tempo stesso affascinante e un po’ inquietante. Da un lato c’è un indubbio vantaggio pratico: tagliare del 10% i token significa risparmiare tempo e denaro su larga scala, e in un settore dove i modelli linguistici costano milioni di dollari di calcolo, ogni ottimizzazione conta. Inoltre, vedere l’AI che plasma i linguaggi di programmazione a sua misura è un segnale che siamo davvero entrati in una nuova era, in cui l’AI non è più solo uno strumento, ma quasi un collega sviluppatore con proprie esigenze. Come nota qualcuno, probabilmente vedremo sempre più strumenti e linguaggi riadattati per lavorare meglio con le AI man mano che queste diventano parte integrante dello sviluppo software.

Dall’altro lato, c’è un che di ironico (e di provocatorio) in questa storia: per anni abbiamo insegnato ai programmatori umani a scrivere codice pensando ai futuri lettori umani, e ora arriva la macchina e ci dice che di tutta questa gentilezza non sa che farsene, anzi le dà fastidio.

Il titolo “AI Coders Are Among Us” suona quasi come un avvertimento da film di fantascienza. I programmatori AI sono tra noi, e parlano in una lingua segreta. Starà a noi decidere se imparare questa lingua, fidarci dei traduttori automatici, oppure insistere che anche le AI si adattino un po’ al nostro modo di programmare per il bene comune. Di certo, la conversazione è aperta. Oggi SimPy è solo un esperimento accademico, ma pone questioni reali su efficienza vs. controllo, macchine vs. umani nel campo del software. La rivoluzione dei coder artificiali è appena iniziata, teniamoli d’occhio, perché potrebbero già essere in mezzo a noi travestiti da innocue linee di codice 😉.

Fonti: La storia è basata sul lavoro di Zhensu Sun et al., “AI Coders Are Among Us: Rethinking Programming Language Grammar Towards Efficient Code Generation”, presentato a ISSTA 2024 (premiato come Distinguished Paper).