Il linguaggio non è un dettaglio da lasciare all’agente

Un agente AI riceve una richiesta, legge il repository, propone una soluzione e, se nessuno gli ha dato un vincolo preciso, sceglie anche come implementarla. Un file TypeScript qui, un piccolo servizio Node.js là, una dipendenza che sembra innocua perché la conosce bene. Il codice funziona nella demo. Poi arriva il momento di mantenerlo, distribuirlo, aggiornarlo, monitorarlo e spiegare perché un sistema che prima aveva due componenti adesso ne ha tre.

Non è una crociata contro TypeScript, né una gara tra linguaggi. È una domanda molto meno comoda: chi ha autorizzato quella scelta architetturale? Perché scrivere una funzione e introdurre un nuovo runtime non sono la stessa operazione, anche quando l’agente le presenta nella stessa pull request.

Il numero di GitHub che si presta a una lettura sbagliata

Nell’Octoverse 2026 pubblicato da GitHub il 28 ottobre compare un dato interessante: fra i repository creati nel 2026, TypeScript è il linguaggio principale nel 35% di quelli con un segnale osservato di utilizzo di agenti, contro il 24% dei repository senza quel segnale. Anche nei repository creati prima del 2026 la differenza esiste: 27% contro 17%.

Sono numeri utili. Ma non dimostrano che un agente, lasciato libero, scelga TypeScript nel 35% dei casi. GitHub osserva repository e segnali di coinvolgimento agentico, non un esperimento controllato in cui si assegna lo stesso problema a un modello e gli si chiede di scegliere il linguaggio. È perfettamente possibile che progetti già orientati a TypeScript adottino più spesso questi strumenti, che gli agenti funzionino meglio in determinati ecosistemi o che entrambe le cose accadano insieme.

La distinzione conta perché una correlazione trasformata in causalità diventa rapidamente una cattiva decisione di progetto. Se il report fosse una classifica dei linguaggi che l’AI “preferisce”, avremmo già perso l’informazione più importante: la scelta dello stack è una decisione umana che può essere resa esplicita oppure lasciata scivolare dentro l’implementazione.

Il linguaggio porta con sé molto più della sintassi

Quando si introduce un linguaggio in un progetto, non si aggiunge soltanto un compilatore. Si introduce una catena di build, un runtime, una politica sulle dipendenze, una superficie di aggiornamento, convenzioni per gli errori, strumenti di osservabilità, test, responsabilità operative e persone capaci di intervenire quando qualcosa smette di funzionare. In un software che vive per anni, sono queste le cose che continuano a presentare il conto.

Un agente può proporre una libreria brillante e perfettamente funzionante. Ma se per usarla devi aprire un nuovo servizio, duplicare l’autenticazione e inventare un secondo modo per leggere il database, il costo non è più quello della funzione. È quello della nuova architettura che hai appena accettato, magari senza nemmeno accorgertene.

La qualità della risposta del modello non basta a stabilire se la modifica appartenga al sistema. Lo si vede bene anche nel caso raccontato in Meta, 14 agenti e una lezione sui contratti: distribuire responsabilità e imporre confini espliciti è più importante che affidare tutto a un componente capace di generare codice plausibile.

Un esempio: la feature funziona, il sistema peggiora

Immaginiamo un gestionale costruito con Laravel e SQL Server. Esistono già servizi di dominio, regole di autorizzazione, un repository dati e test d’integrazione. La richiesta è semplice: aggiungere un’esportazione periodica dei dati degli ordini. Se il brief dice soltanto “crea un export schedulato”, un agente potrebbe proporre un piccolo worker Node.js, un collegamento diretto al database e una nuova libreria per produrre il file.

La dimostrazione è convincente: l’export esce, i dati sembrano corretti, il job parte. Ma ora bisogna rispondere a domande che non compaiono nello screenshot. Chi gestisce le credenziali del nuovo processo? Le autorizzazioni sono le stesse del gestionale? Cosa succede se il job parte due volte? Come vengono registrati i fallimenti? Dove si applica una modifica alla regola fiscale? Chi aggiorna il runtime e le dipendenze fra sei mesi?

Non è detto che la soluzione Node.js sia sbagliata. Potrebbe persino essere la migliore, se esiste un motivo tecnico misurabile. Il problema nasce quando la scelta viene fatta come effetto collaterale della generazione, invece che come decisione esplicita, verificata e assegnata a qualcuno.

Il contratto prima del prompt

Un buon brief per un agente non deve descrivere ogni riga di codice. Deve invece stabilire ciò che l’agente non può decidere da solo. È la differenza tra delegare l’implementazione e delegare l’architettura senza accorgersene.

• Perimetro tecnologico. Linguaggi, framework, versioni e runtime ammessi; nuove dipendenze solo se motivate.
• Confini del dominio. Servizi e repository da riutilizzare, regole che non devono essere duplicate, API e dati che non possono essere aggirati.
• Vincoli operativi. Deployment, gestione dei segreti, logging, retry, idempotenza e responsabilità di manutenzione.
• Prove richieste. Test automatici, casi limite, migrazioni, benchmark quando servono e una spiegazione del comportamento in errore.
• Eccezioni dichiarate. Se l’agente propone un nuovo linguaggio o servizio, deve presentarlo come decisione da approvare, non nasconderlo in un diff di cento file.

Queste regole non rendono l’agente meno utile. Lo rendono più utilizzabile. Quando il perimetro è chiaro, il modello può spendere capacità su ciò che davvero gli viene chiesto: esplorare alternative, implementare, testare, correggere. Non deve reinventare il progetto ogni volta che riceve una richiesta.

TypeScript non è il colpevole, e le classifiche non sono un progetto

GitHub segnala TypeScript al primo posto per contributori mensili sulla propria piattaforma nel 2026, seguito da Python e JavaScript. La Developer Survey 2026 di Stack Overflow, che misura invece le tecnologie dichiarate dai rispondenti, vede JavaScript al 62% e TypeScript al 43,8%. Non c’è una contraddizione da risolvere: sono popolazioni, domande e metriche differenti. Usarle come se fossero lo stesso termometro sarebbe un ottimo modo per fare una slide e un pessimo modo per prendere una decisione tecnica.

TypeScript può essere la scelta corretta per un frontend, per una piattaforma già costruita su Node.js o per un team che dispone di competenze e pipeline adeguate. PHP, C#, Go, Rust o Python possono essere altrettanto corretti in contesti diversi. Il linguaggio non si sceglie per appartenenza a una tifoseria e nemmeno perché l’ultimo modello genera più volentieri un certo tipo di file.

L’Octoverse mostra anche che, a settembre, più del 40% delle pull request su GitHub partiva da una prima bozza di un agente, contro il 17% di marzo. Non è la percentuale di software consegnato né una misura della sua qualità. È il segnale che sempre più decisioni iniziali passano attraverso strumenti capaci di produrre modifiche molto rapidamente. Proprio per questo conviene rendere esplicite le decisioni che devono rimanere a monte del codice.

Il codice si genera. Le conseguenze restano

In un articolo precedente sul divario tra codice prodotto e software consegnato il problema era la capacità di verificare e integrare ciò che gli agenti generano. Qui il problema arriva ancora prima: una modifica può essere formalmente corretta e contemporaneamente peggiorare la struttura del sistema che la dovrà ospitare.

Un agente può scrivere la funzione in pochi minuti. Il runtime in più che dovrai mantenere per anni non sparisce insieme alla finestra della chat.

Per questo il controllo non comincia quando si apre la pull request. Comincia quando si definiscono i confini della richiesta: cosa può cambiare, cosa deve essere riusato, quali prove servono e chi si assume la responsabilità di una nuova dipendenza. È un lavoro meno spettacolare della demo, ma è quello che permette alla demo di diventare software.

L’AI può aiutare a scrivere più codice, in più linguaggi, con meno attrito. Benissimo. Ma se la scelta del linguaggio diventa un default invisibile del modello, non stiamo accelerando soltanto lo sviluppo: stiamo lasciando che una scorciatoia locale decida il costo futuro del sistema. E quel costo, a differenza del prompt, non si cancella premendo Invio.