GLOSSOPETRAE: linguaggi artificiali per far programmare meglio gli LLM
Il progetto open source GLOSSOPETRAE genera linguaggi artificiali che alcuni modelli usano meglio dell'inglese per scrivere codice.
GLOSSOPETRAE e i linguaggi artificiali per il codice
GLOSSOPETRAE è interessante perché mette in discussione un’abitudine ormai consolidata: chiedere ai grandi modelli linguistici di programmare usando soprattutto inglese, linguaggi di programmazione tradizionali e prompt descrittivi. Il progetto propone invece di generare lingue artificiali pensate per essere più adatte al modo in cui GPT, Claude e modelli simili rappresentano istruzioni, vincoli e strutture di codice.
Il punto non è creare una curiosità linguistica, ma capire se un sistema di notazione più compatto e regolare possa ridurre ambiguità, errori di interpretazione e passaggi inutili. Per chi lavora con agenti di programmazione, la domanda pratica è semplice: conviene descrivere un compito in linguaggio naturale, oppure conviene passare da un formato intermedio costruito apposta per i modelli?
Perché la notizia conta per gli agenti di programmazione
Molti errori degli agenti non nascono dalla mancanza di capacità grezza, ma dalla distanza tra richiesta umana e rappresentazione operativa. Un prompt in italiano o in inglese può essere chiaro per una persona, ma contenere impliciti, eccezioni e priorità che il modello deve ricostruire. Un linguaggio artificiale può provare a rendere questi elementi più espliciti.
Se GLOSSOPETRAE o approcci simili dimostrano vantaggi replicabili, il lavoro sugli agenti potrebbe spostarsi da prompt sempre più lunghi a protocolli più controllati. Questo sarebbe utile soprattutto nei flussi ripetitivi: generazione di patch, trasformazioni di codice, validazione di vincoli, descrizione di interfacce e passaggio di stato tra più agenti.
Impatto pratico per sviluppatori e team
L’uso più realistico non è sostituire i linguaggi di programmazione. È inserire una rappresentazione intermedia tra richiesta e modifica del codice. Un team potrebbe usare un linguaggio artificiale per descrivere intenzioni, dipendenze, invarianti e limiti, lasciando poi al modello la traduzione nel codice finale.
Possibili applicazioni:
- specificare modifiche ripetitive con meno ambiguità;
- ridurre prompt lunghi e fragili nei sistemi agentici;
- confrontare lo stesso compito scritto in inglese e in notazione artificiale;
- creare benchmark interni su refactoring, test e correzione di bug;
- verificare se il formato migliora anche modelli più piccoli.
Il beneficio va misurato con attenzione. Un linguaggio artificiale utile deve ridurre errori, non aggiungere un livello opaco che solo pochi sanno leggere.
Confronto tra prompt naturale e linguaggio artificiale
| Aspetto | Prompt in linguaggio naturale | Linguaggio artificiale |
|---|---|---|
| Leggibilità umana | Alta, soprattutto per richieste semplici | Più bassa senza strumenti di supporto |
| Ambiguità | Può crescere con compiti lunghi | Può diminuire se la grammatica è stabile |
| Integrazione | Immediata negli strumenti esistenti | Richiede traduttori, esempi e convenzioni |
| Controllo | Dipende dalla disciplina del prompt | Più adatto a vincoli formalizzati |
| Rischio | Istruzioni implicite o contraddittorie | Formato difficile da auditare se mal progettato |
La tabella chiarisce il compromesso: l’inglese resta più accessibile, ma una notazione dedicata può essere più precisa nei processi ripetibili. Il valore sta nella misura, non nell’originalità del formato.
Rischi e limiti da non ignorare
Il rischio principale è scambiare un miglioramento su esempi selezionati per una superiorità generale. Un linguaggio artificiale può funzionare bene su un insieme ristretto di compiti e poi fallire quando cambiano repository, stile di codice o modello. Serve quindi una prova su casi reali, con errori classificati e confronti ripetibili.
C’è anche un problema di manutenzione. Se il formato diventa troppo distante dal modo in cui ragionano gli sviluppatori, il team rischia di non capire più le istruzioni inviate agli agenti. In un contesto professionale, auditabilità e responsabilità contano quanto la prestazione.
Come valutarlo senza creare complessità
La prova migliore parte da un compito piccolo: una trasformazione di API, la scrittura di test o la correzione di una classe di errori già nota. Bisogna preparare lo stesso incarico in linguaggio naturale e nel formato artificiale, poi confrontare tempo, numero di tentativi, errori residui e facilità di revisione.
Se il formato migliora solo la velocità ma peggiora la comprensione del risultato, il vantaggio è debole. Se invece riduce errori ripetuti e rende più stabile il comportamento del modello, può diventare un componente utile nei flussi agentici.
Cosa monitorare nei prossimi mesi
Da seguire ci sono benchmark indipendenti, esempi su repository reali, supporto da parte di strumenti di sviluppo e compatibilità con modelli diversi. Un risultato convincente dovrebbe funzionare non solo con un modello di frontiera, ma anche con modelli più piccoli o locali.
Va monitorata anche la qualità degli strumenti intorno al progetto: convertitori, validatori, documentazione e casi d’uso. Senza questi elementi, un linguaggio artificiale resta un esperimento interessante ma difficile da adottare.
FAQ
GLOSSOPETRAE sostituisce i linguaggi di programmazione?
No. È più utile pensarlo come un formato intermedio per comunicare meglio con i modelli, non come un sostituto di Python, JavaScript o altri linguaggi.
Perché un modello dovrebbe programmare meglio in una lingua artificiale?
Perché una grammatica più regolare può ridurre ambiguità e rendere più espliciti vincoli, sequenze e relazioni tra parti del codice.
Conviene provarlo subito in produzione?
No, conviene prima provarlo su un flusso isolato, con confronto diretto rispetto a prompt normali e revisione umana dei risultati.