L'attimo Opus nel mondo dell'open source: GLM-5 riuscirà a raccogliere il testimone dell'Agentic Coding?

Se chiedi a uno sviluppatore qual è il momento più frustrante della programmazione con l'intelligenza artificiale,

la risposta molto probabilmente sarà la frase meccanica "Mi dispiace, ho capito male" di fronte a un errore, per poi ripetere un codice altrettanto errato.

Nell'ultimo anno, i progressi dei modelli di coding si sono manifestati maggiormente nella "capacità di generazione": generare pagine web, componenti, piccoli giochi con una sola frase: creare una pagina web in stile pixel, un'icona SVG fantastica o un gioco del serpente funzionante in 15 secondi. Queste demo sono abbastanza sorprendenti, ma anche abbastanza "leggere", un po' come giocattoli di lusso prodotti nell'era del Vibe Coding (programmazione d'atmosfera). Ma quando si tratta di architetture ad alta concorrenza, adattamento di driver di basso livello o complesse ristrutturazioni di sistemi, diventano "fiori in serra".

Quindi, di recente, la direzione nella Silicon Valley è cambiata.

Che si tratti di Claude Opus 4.6 o GPT-5.3, questi modelli di punta iniziano a enfatizzare l'Agentic Coding: non si cerca di "ottenere risultati in un secondo", ma di completare attività a livello di sistema attraverso la pianificazione, la scomposizione e l'esecuzione ripetuta.

Questo passaggio di paradigma dall'"estetica front-end" all'"ingegneria dei sistemi" era considerato un'area di monopolio dei giganti closed source. Solo dopo aver testato GLM-5 mi sono reso conto che l'"era degli architetti" della comunità open source è iniziata prima del previsto.

01

Dal "front-end" all'"ingegneria dei sistemi"

Prima, quando si parlava di AI Coding, si pensava per lo più a una narrazione familiare: generare una pagina web con una frase, creare un piccolo gioco in un minuto, realizzare un effetto dinamico fantastico in dieci secondi. Si enfatizzava la "piacevolezza visiva": pulsanti che si muovono, pagine belle, effetti speciali ricchi.

Ma chi è veramente sul campo sa che essere in grado di generare una demo non significa essere in grado di sostenere un sistema.

La difficoltà di compiti complessi non sta nello "scrivere codice", ma nel modo in cui i moduli vengono scomposti, gli stati gestiti, le eccezioni gestite, le prestazioni ottimizzate e se la struttura può essere mantenuta stabile quando il sistema diventa complesso.

Questo è anche il motivo per cui abbiamo scelto compiti complessi come oggetto di test pratico.

Il posizionamento di GLM-5 è diverso da molti prodotti concorrenti.

Se la maggior parte dei modelli assomiglia più a un "eccellente front-end" - abile nel generare rapidamente interfacce interattive ed effetti visivi - GLM-5 è più orientato al "ruolo di ingegneria dei sistemi". Enfatizza la collaborazione tra più moduli, le attività a lunga catena e la stabilità strutturale eseguibile in ambienti di produzione.

Per verificarlo, abbiamo progettato due casi di test pratici con dimensioni completamente diverse.

Il primo test è un compito apparentemente facile, ma in realtà altamente sistematico: basato su browser e fotocamera, realizzare un gioco interattivo a tema Capodanno con "fuochi d'artificio controllati a distanza tramite visione artificiale".

Nel video del test pratico, si può vedere che l'utente si trova di fronte alla fotocamera e controlla la direzione e il ritmo del lancio dei fuochi d'artificio tramite gesti; i fuochi d'artificio sbocciano in aria, accompagnati da effetti particellari e feedback di effetti di luce dinamici, e l'interazione complessiva è fluida e naturale.

Ma questo non è un semplice progetto di effetti dinamici front-end. Include almeno i seguenti moduli principali: riconoscimento dei gesti ed elaborazione dell'input visivo; mappatura delle coordinate dei gesti alla logica di lancio; sistema di particelle di fuochi d'artificio ed effetti di sbocciatura; rendering in tempo reale e controllo del frame rate; compatibilità del browser e gestione anomala delle autorizzazioni della fotocamera; gestione dello stato dell'interazione e meccanismo di feedback dell'utente.

Si può dire che sia un piccolo sistema interattivo con una struttura completa e un'esperienza fluida. Dal processo di test pratico, si può vedere che GLM-5 non è entrato direttamente nella codifica, ma ha prima pianificato l'architettura generale: come separare i moduli di input visivo, il livello di logica di controllo, il livello di rendering e il livello di effetti speciali; come trasmettere il flusso di dati; quali parti potrebbero diventare colli di bottiglia delle prestazioni.

Successivamente, ha implementato la logica strato per strato, a partire dall'elaborazione dei dati del riconoscimento dei gesti, passando al calcolo della traiettoria di lancio e all'ottimizzazione dei parametri dell'effetto di esplosione delle particelle.

Quando il rendering si bloccava, suggeriva attivamente di ridurre il numero di particelle e ottimizzare la struttura del ciclo; quando il riconoscimento dei gesti era errato, regolava le soglie e le strategie di filtraggio.

L'effetto presentato nel video è "un'interazione che sembra molto naturale". Ma ciò che si riflette dietro è una catena di ingegneria completa: pianificazione → scrittura → debug → ottimizzazione delle prestazioni → correzione dell'interazione.

Il codice generato finale può essere eseguito direttamente, l'interazione è stabile, il frame rate è fluido e le situazioni anomale possono essere gestite. Ancora più importante, il suo modo di lavorare presenta un chiaro pensiero sistemico: i confini dei moduli sono chiari, la stratificazione logica è ragionevole, invece di impilare tutte le funzioni in un unico file.

Il secondo caso di test è la capacità del sistema strutturale. Questo scenario può essere considerato il lavoro quotidiano dei media: importare una trascrizione di un'intervista, riassumere il contenuto e fornire angolazioni e idee per gli argomenti.

Nel test pratico, si può vedere che il processo operativo è molto diretto: ho incollato una trascrizione di un'intervista di qualche tempo fa, il modello ha iniziato ad analizzare e poi ha fornito un riassunto del contenuto e angolazioni per gli argomenti. Dai risultati, le angolazioni degli argomenti che ha generato sono ancora molto operative.

Rispetto al sistema di interazione visiva, l'organizzazione della registrazione sembra semplice, ma in realtà mette alla prova la "capacità di astrazione strutturale" del modello. Una registrazione di un'intervista reale è spesso altamente non strutturata: punti di vista che saltano, informazioni ripetute, intreccio di linee principali e secondarie. Quindi, in questo caso, la capacità mostrata da GLM-5 è a livello di sistema.

Innanzitutto, la capacità di identificazione del tema e di estrazione della linea principale. Il modello non ha generato un riassunto nell'ordine del testo originale, ma ha prima giudicato qual è l'argomento principale e poi ha riorganizzato il contenuto attorno a questo argomento. Ciò significa che ha completato una scansione internamente, identificando quali informazioni appartengono alla linea principale e quali sono supplementari o rumore. Questa capacità è essenzialmente una capacità di pianificazione, ovvero stabilire prima una struttura astratta prima di produrre l'output.

In secondo luogo, la capacità di riassemblaggio modulare. Classificherà i punti di vista correlati sparsi in diversi paragrafi nello stesso modulo. Questa capacità di integrazione tra paragrafi indica che il modello ha una coerenza globale quando elabora testi lunghi.

In terzo luogo, la capacità di regolazione attiva dell'ordine logico. L'output effettivo dello schema è spesso diverso dall'ordine di registrazione originale. Si può vedere che GLM-5 sta riorganizzando i livelli in base alle relazioni causali o alla logica di argomentazione. Ciò riflette un giudizio di "logica prioritaria rispetto all'ordine di input originale". Questa modalità di "prima struttura, poi output" è il fulcro del pensiero di ingegneria dei sistemi.

Questi due casi, uno è un sistema di interazione visiva in tempo reale e l'altro è un sistema di elaborazione della struttura delle informazioni dei media, sembrano completamente diversi. Ma ciò che verificano è la stessa cosa: GLM-5 ha una completa capacità di ciclo chiuso dell'attività: pianificazione → esecuzione → debug → ottimizzazione.

Nel gioco dei fuochi d'artificio, ciò si riflette nella stratificazione dei moduli, nell'ottimizzazione delle prestazioni e nella gestione delle eccezioni; nel processore di registrazione, ciò si riflette nella determinazione del tema, nella scomposizione della struttura e nella riorganizzazione logica. Il loro punto in comune è che il modello non si è fermato alla "generazione di risultati", ma ha mantenuto una struttura sostenibile in evoluzione.

Ho continuato a provare un compito relativamente complesso, "costruire un kernel di sistema operativo minimalista". In questo test pratico, ciò che è veramente degno di nota non è che il codice nel video alla fine funzioni, ma il modo in cui GLM-5 si comporta durante l'intero processo.

Non appena ha ricevuto il compito, non è entrato immediatamente nello stato di generazione, ma ha prima chiarito i confini del compito, scomposto attivamente i moduli, pianificato la struttura del sistema e poi è entrato nella fase di implementazione. Questo percorso di "prima struttura" è essenzialmente il pensiero ingegneristico di cui si è parlato prima: definire prima come è composto il sistema, poi discutere i dettagli specifici dell'implementazione, invece di scrivere e assemblare contemporaneamente.

Nel ciclo di scrittura, esecuzione, errore e correzione a più turni, GLM-5 non ha mostrato alcun collasso strutturale. Ogni modifica è stata eseguita attorno all'architettura stabilita, invece di ribaltare tutto o applicare patch locali. Ciò indica che internamente mantiene un modello di sistema completo, in grado di mantenere la coerenza nelle attività a lunga catena. Molti modelli sono inclini a contraddizioni dopo che il contesto è stato allungato, mentre le prestazioni nel video riflettono proprio la sua capacità di memoria continua della struttura generale.

C'è anche il modo in cui gestisce gli errori. Quando si verifica un errore, non si ferma alla speculazione superficiale di "potrebbe essere un problema con una riga di codice", ma prima giudica il tipo di errore, distingue tra problemi logici, problemi ambientali o conflitti di dipendenza e poi pianifica il percorso di risoluzione dei problemi. Questo è un Debug a livello di strategia, volto a riparare il percorso del problema.

Se combinato con la chiamata di strumenti, questa capacità sarà più evidente. Non si limita a fornire suggerimenti di comando, ma combina anche la pianificazione attiva dell'esecuzione del terminale, l'analisi dei log, la riparazione dell'ambiente e poi continua a far avanzare il compito. Questo comportamento è già un po' simile a un avanzamento ingegneristico in stile "guida autonoma". Se l'obiettivo non è completato, continua a iterare.

Pianificare prima di eseguire, mantenere la stabilità strutturale nelle catene lunghe, risolvere i problemi in modo strategico e continuare a far avanzare l'obiettivo: è la sovrapposizione delle quattro capacità principali richieste dall'ingegneria dei sistemi che consente a GLM-5 di iniziare a presentare modelli di comportamento simili al modo di lavorare di un ingegnere.

Perché GLM-5 può raccogliere il testimone dell'"architetto"?

Se la prima parte del test pratico ha dimostrato che GLM-5 "può fare lavori complessi", allora la domanda successiva è: perché può farlo? La risposta sta in una serie completa di "modelli di comportamento a livello ingegneristico" nascosti dietro l'output.

Un punto chiave è che GLM-5 ha chiaramente introdotto un meccanismo di auto-controllo della catena di pensiero simile a Claude Opus 4.6.

Nell'uso pratico, si può sentire che non inizia immediatamente a "riempire il codice" non appena riceve un compito, ma esegue più turni di deduzione logica in background: prevede la relazione di accoppiamento tra i moduli, evita attivamente i percorsi di ciclo infinito, scopre in anticipo i conflitti di risorse e i problemi di condizioni al contorno. Il cambiamento diretto portato da questo comportamento è che, per garantire che la soluzione sia ingegneristicamente valida, è disposto a rallentare e pensare al problema in modo completo.

In compiti complessi, GLM-5 fornirà prima una chiara scomposizione dei moduli: da quali sottomoduli è composto il sistema, quali sono gli input e gli output di ciascun modulo, quali parti possono essere avanzate in parallelo e quali devono essere completate in serie. Quindi li affronta uno per uno, invece di scrivere e pensare contemporaneamente. Ciò rende il suo modo di lavorare più simile a un vero ingegnere: prima disegna il diagramma dell'architettura, poi scrive i dettagli dell'implementazione. Si sente chiaramente che ha una sorta di "tenacia di non fermarsi finché il problema non è risolto completamente", invece di finire frettolosamente dopo aver completato una parte apparentemente corretta.

Questa differenza è particolarmente evidente nel confronto con i modelli di coding tradizionali. In passato, molti modelli, quando incontravano un errore, scivolavano rapidamente in una modalità familiare: scusarsi, ripetere le informazioni sull'errore, fornire un suggerimento di correzione non verificato; se fallivano di nuovo, iniziavano a produrre ciclicamente risposte approssimative. Il modo in cui GLM-5 gestisce la situazione è più simile a un architetto esperto. Nel test pratico, quando il progetto non poteva essere eseguito a causa di problemi di dipendenza ambientale, non si è fermato alle informazioni sull'errore superficiale, ma ha analizzato attivamente l'albero delle dipendenze (Dependency Tree), ha giudicato l'origine del conflitto e ha ulteriormente diretto OpenClaw per riparare l'ambiente.

L'intero processo è più simile a una distribuzione in stile "guida autonoma": il modello non risponde passivamente, ma legge continuamente i log, corregge i percorsi e verifica i risultati.

Un'altra capacità spesso trascurata, ma estremamente importante nell'ingegneria dei sistemi, è l'integrità del contesto.

La finestra di Token a livello di milioni di GLM-5 gli consente di comprendere l'intera struttura del codice, le modifiche storiche, i file di configurazione e i log di esecuzione del progetto nello stesso contesto. Ciò significa che è già in grado di giudicare da una prospettiva globale quali moduli saranno influenzati a catena da una modifica. In compiti a lunga catena, questa capacità determina direttamente se il modello è "intelligente ma miope" o "stabile e controllabile".

Nel complesso, GLM-5 ha veramente raccolto il ruolo di "architetto" principalmente perché ha iniziato a pensare ai problemi come un architetto: pianificare prima, poi eseguire; convalidare continuamente, correggere costantemente; concentrarsi sull'intero sistema, invece che sul successo di un singolo punto.

Questo è anche il motivo fondamentale per cui è in grado di completare i compiti di test pratici a livello di sistema nella prima parte.

03

L'Opus del mondo open source?

Se visto nell'ecosistema dei modelli di grandi dimensioni del 2026, il valore di GLM-5 risiede maggiormente nel fatto che ha infranto una cosa che prima era quasi data per scontata: l'intelligenza a livello di sistema sembra esistere solo nei modelli closed source.

In precedenza, Claude Opus 4.6 e GPT-5.3 avevano effettivamente aperto la strada all'"Agentic Coding": il modello non cerca più il feedback immediato, ma completa compiti ingegneristici veramente complessi attraverso la pianificazione, la scomposizione e l'esecuzione ripetuta. Ma il costo è anche molto alto: il consumo di Token per compiti ad alta intensità è estremamente elevato e un tentativo completo a livello di sistema spesso significa costi di chiamata considerevoli.

GLM-5 fornisce qui una soluzione diversa. Come modello open source, riporta l'"AI a livello di architetto di sistema" dal cloud e dalle fatture all'ambiente degli sviluppatori. Puoi distribuirlo localmente, lasciandogli il tempo di affrontare i lavori sporchi, faticosi e grandi: regolare i log, controllare le dipendenze, modificare il vecchio codice, integrare le condizioni al contorno.

Questo può essere visto come un cambiamento strutturale in termini di rapporto costo-efficacia: l'intelligenza a livello di architetto non è più un privilegio di pochi team.

Se si comprende questa differenza usando una metafora professionale, sarà più intuitivo. Modelli come Kimi 2.5 sono più simili a eccellenti ingegneri front-end con un'estetica online e un forte senso di interazione, abili nella generazione One-shot, nella presentazione visiva e nel feedback rapido; mentre lo stile di GLM-5 è ovviamente diverso, è più simile a un architetto di sistema esperto che rispetta i limiti, dà importanza alla logica: si concentra sulle relazioni tra i moduli, sui percorsi anomali, sulla manutenibilità e sul funzionamento stabile a lungo termine.

Dietro questo, in realtà, c'è una chiara progressione professionale della programmazione AI: dal perseguimento del Vibe Coding "che sembra molto piacevole" all'enfasi sulla robustezza e sulla disciplina ingegneristica dell'Engineering.

Ancora più importante, l'emergere di GLM-5 rende il concetto di azienda unipersonale più realizzabile.Quando uno sviluppatore può avere localmente un partner AI che comprende la progettazione del sistema, può operare a lungo termine e auto-correggersi, molti lavori di ingegneria che originariamente richiedevano un team di persone possono essere compressi in un ambito controllabile da un singolo individuo. In futuro, GLM-5 ha il potenziale per diventare quel "partner digitale" responsabile dell'implementazione ingegneristica principale in una società unipersonale.