GLM migliora l’inferenza. Gli ingegneri decidono gli obiettivi

Z.ai riferisce che un agente di programmazione basato su GLM-5.3 ha contribuito a ottimizzare il software che esegue GLM-5.3-Flash, raggiungendo un throughput circa tre volte superiore a quello iniziale. Il resoconto del 17 settembre 2026 descrive un lavoro guidato dagli ingegneri, che revisionavano le modifiche critiche. Ne ricavo una lezione pratica: a un agente servono misurazioni che spieghino gli insuccessi e qualcuno che decida quali risultati accettare. [1]

Che cosa ha costruito davvero GLM?

Il lavoro riguardava il software di inferenza, che esegue un modello già addestrato per rispondere alle richieste. La documentazione di Z.ai descrive un motore basato su SGLang, con worker separati per elaborare gli input multimodali, leggere i prompt e generare i token. L’agente dedicato all’infrastruttura ha aiutato gli ingegneri a migliorare i kernel e a individuare i colli di bottiglia. [2]

Secondo le note di rilascio di Z.ai, GLM-5.3-Flash è stato pubblicato il 26 agosto 2026. Il resoconto di settembre spiega il lavoro alla base di quella messa in produzione; non annuncia un nuovo modello. Distinguere le due date conta quando un resoconto tecnico appena pubblicato comincia a circolare come notizia di un nuovo modello. [4]

Il software doveva sostenere un carico di lavoro considerevole. Z.ai documenta il supporto nativo per immagini e video oltre al testo, una finestra di contesto da un milione di token e un’architettura di attenzione ibrida. Il sistema di inferenza separa le fasi che richiedono risorse diverse. Il lavoro sull’infrastruttura rispondeva quindi alle capacità effettive del prodotto, senza limitarsi a un esercizio isolato di generazione di codice. [2]

Eviterei anche di fondere i nomi dei due modelli nella formula «GLM ha costruito sé stesso». Un agente che migliora il software di esecuzione e un sistema che sviluppa il proprio successore sono due risultati tecnici diversi. La distinzione cambia le prove che voglio vedere.

Che cosa significa il throughput triplicato dichiarato da Z.ai?

Z.ai dichiara un throughput tre volte superiore a quello del sistema di inferenza iniziale, sullo stesso hardware. Il dato sostiene una conclusione sul lavoro di ottimizzazione nel suo insieme. Non isola quanto più velocemente abbia lavorato l’agente rispetto a un gruppo equivalente di ingegneri. [2]

Il dettaglio più utile è un caso concreto di debug. Z.ai spiega che, in alcuni scenari, il divario di prestazioni fra l’elaborazione dei prompt con trasferimento della cache e la sola elaborazione dei prompt superava il 20%. Una correzione nella gestione della concorrenza tra Python e C++ ha portato il divario sotto l’1%, nelle stesse condizioni di test. [1]

Quelle percentuali misurano il sovraccarico osservato in quel confronto. Non sono un ulteriore incremento di velocità da moltiplicare per il 3× messo in evidenza. Terrei ogni risultato legato al suo riferimento iniziale, proprio come faccio quando esamino che cosa misurano davvero i punteggi dei benchmark di IA. Senza questa disciplina, più misurazioni valide possono portare a una conclusione sbagliata.

Mi resta una domanda: quale parte del risultato è attribuibile all’agente? Un confronto utile manterrebbe costanti il compito e il codice di partenza, registrando poi il tempo trascorso, gli interventi degli ingegneri e le modifiche accettate. Il resoconto tecnico mi dà un motivo per approfondire il metodo di lavoro, ma non trasformerei il dato sul throughput nell’affermazione che gli sviluppatori siano diventati tre volte più produttivi.

Si tratta di automiglioramento ricorsivo?

Z.ai afferma di non aver raggiunto l’automiglioramento ricorsivo. Nel suo resoconto gli ingegneri decidono obiettivi e vincoli e revisionano le modifiche critiche, mentre l’agente propone modifiche ed esegue esperimenti. [1]

Un post pubblicato su r/AIGuild il 18 settembre ha presentato il lavoro come un primo esempio di automiglioramento ricorsivo, riconoscendo poi lo stesso limite posto dal controllo umano. È un’interpretazione interessante, ma il post commenta il resoconto di Z.ai e non riproduce i risultati in modo indipendente. [3]

Per accettare l’affermazione più forte chiederei prove più impegnative: quali decisioni sul sistema successivo ha preso l’IA, quali evidenze hanno giustificato la loro approvazione e il processo potrebbe continuare senza che una persona fornisca l’obiettivo seguente? Migliorare il software che esegue un modello risponde a una domanda più circoscritta.

Il risultato merita comunque attenzione. Prima dell’etichetta, mi interessa capire se un agente sa svolgere lavoro utile nella ricerca e nell’ingegneria. La stessa distinzione guida la mia lettura dei resoconti su Claude alla guida della ricerca in IA: sapere quale lavoro è stato delegato e come viene revisionato mi dice più di una generica affermazione sull’autonomia.

Che cosa riprenderei per lavorare con un agente di programmazione

Riprenderei l’impostazione degli esperimenti: scegliere un’azione lenta compiuta dall’utente, conservare l’implementazione di partenza e definire sia come misurare i tempi sia quale comportamento deve restare corretto. Così l’agente ha un problema preciso da indagare prima di iniziare a modificare il codice.

Per una pagina che rallenta dopo aver caricato un dataset di grandi dimensioni, includerei nelle istruzioni quel dataset e un’azione ripetibile da cronometrare. Se l’agente propone una cache, il suo test deve rilevare anche eventuali risultati non aggiornati. Un risultato più veloce ma basato su dati vecchi non soddisferebbe la mia condizione di accettazione.

Deciderei se tenere la patch verificando l’intero flusso d’uso. Una misurazione locale promettente è un motivo per proseguire i test, ma non basta per accettare la modifica. Confronterei entrambe le versioni con gli stessi input e annoterei il motivo dell’accettazione o del rifiuto.

Queste annotazioni vanno conservate insieme alle informazioni sul progetto di cui parlo nella mia guida alla gestione del contesto. All’agente successivo servono il comando usato per la misurazione iniziale e i risultati ottenuti, compresi gli approcci falliti, per poter proseguire l’indagine.

Per il lavoro in parallelo, la lezione degli agenti che comunicano attraverso una bacheca condivisa è rendere esplicito chi è responsabile di ogni esperimento. Qualcuno deve decidere da quale risultato partirà la modifica successiva. Come primo risultato concreto vorrei una diagnosi riproducibile di un’operazione lenta in un’applicazione che conosco già.