Der Opus-Moment in der Open-Source-Welt: Kann GLM-5 den Stab des Agentic Coding übernehmen?

Wenn Sie einem Entwickler fragen, was die am meisten frustrierenden Momente beim Programmieren mit KI seien?

Seine Antwort wird wahrscheinlich die mechanische Äußerung „Entschuldigung, ich habe es falsch verstanden“ sein, wenn die KI einen Fehler meldet, und dann die wiederholte Ausgabe des gleichen fehlerhaften Codes.

Im vergangenen Jahr hat sich der Fortschritt von Coding-Großmodellen hauptsächlich in der „Generierungsfähigkeit“ gezeigt: Mit einem Satz kann man eine Webseite, Komponenten oder ein kleines Spiel generieren – binnen 15 Sekunden kann man eine Pixel-Webseite, ein cooles SVG-Icon oder ein funktionierendes Schlangenspiel erstellen. Diese Demos sind beeindruckend, aber auch recht „leichtgewichtig“. Sie ähneln eher den hochwertigen Spielzeugen aus der Zeit des Vibe Codings (Programmieren für die Atmosphäre). Wenn es jedoch um Hochlast-Architekturen, die Anpassung von Low-Level-Treibern oder die komplexe Systemumstrukturierung geht, sind sie wie „Blumen im Gewächshaus“.

Deshalb hat sich die Stimmung in Silicon Valley kürzlich gewandelt.

Ob es sich um Claude Opus 4.6 oder GPT-5.3 handelt, diese Spitzen-Großmodelle legen nun den Schwerpunkt auf Agentisches Coding: Sie streben nicht nach der „Sofortproduktion von Ergebnissen“, sondern bewältigen systemweite Aufgaben durch Planung, Aufteilung und wiederholtes Ausführen.

Diese Paradigmenverschiebung von der „Frontend-Ästhetik“ hin zur „Systemtechnik“ galt bisher als das Monopolgebiet der proprietären Riesenunternehmen. Erst als ich GLM-5 getestet habe, wurde mir klar, dass die Zeit der „Architekten“ in der Open-Source-Community früher als erwartet begonnen hat.

01 Von der „Frontend-Entwicklung“ zur „Systemtechnik“

Wenn man bisher über KI-Coding sprach, dachte man meist an ein bekanntes Szenario: Mit einem Satz eine Webseite generieren, in einer Minute ein kleines Spiel erstellen oder in zehn Sekunden ein cooles Animationseffekt gestalten. Hierbei wird der Schwerpunkt auf das „visuelle Wohlgefühl“ gelegt: Buttons bewegen sich, die Seite sieht gut aus und die Effekte sind reichhaltig.

Aber wer wirklich im Engineering-Bereich tätig ist, weiß, dass die Fähigkeit, eine Demo zu generieren, nicht gleichbedeutend mit der Fähigkeit ist, ein System aufzubauen.

Die Schwierigkeit bei komplexen Aufgaben liegt nicht darin, „Code zu schreiben“, sondern darin, wie die Module aufgeteilt werden, wie der Zustand verwaltet wird, wie Ausnahmen behandelt werden, wie die Leistung optimiert wird und ob die Systemstruktur stabil bleibt, wenn das System komplexer wird.

Deshalb haben wir komplexe Aufgaben als Testobjekte ausgewählt.

GLM-5 hat eine andere Ausrichtung als viele Konkurrenten.

Wenn man sagt, dass die meisten Modelle eher wie „ausgezeichnete Frontend-Entwickler“ sind – sie sind gut darin, schnell Interfaces und visuelle Effekte zu generieren – dann ist GLM-5 eher ein „Systemtechniker“. Es legt den Schwerpunkt auf die Zusammenarbeit mehrerer Module, langfristige Aufgaben und die strukturelle Stabilität in der Produktionsumgebung.

Um dies zu überprüfen, haben wir zwei völlig verschiedene Testfälle entworfen.

Der erste Test ist eine scheinbar einfache, aber in Wirklichkeit hochgradig systematische Aufgabe – die Entwicklung eines interaktiven Frühlingsfestspiels namens „KI-gesteuertes Feuerwerk per Gestensteuerung“ basierend auf Browser und Kamera.

Im Testvideo kann man sehen, dass der Benutzer vor der Kamera steht und die Richtung und das Tempo des Feuerwerks mit Gesten steuert; das Feuerwerk entfaltet sich am Himmel, begleitet von Partikeleffekten und dynamischen Lichteffekten, und die Interaktion ist flüssig und natürlich.

Aber dies ist kein einfaches Frontend-Animationsprojekt. Es umfasst mindestens die folgenden Kernmodule: Gestenerkennung und Verarbeitung der visuellen Eingabe; Abbildung von Geste-Koordinaten auf die Abfeuerlogik; Feuerwerkspartikelsystem und Entfaltungseffekte; Echtzeit-Rendering und Framerate-Steuerung; Browserkompatibilität und Behandlung von Kameraberechtigungsausnahmen; Verwaltung des Interaktionszustands und Benutzerfeedback-Mechanismus.

Es handelt sich um ein kleines interaktives System mit einer vollständigen Struktur und einem flüssigen Benutzererlebnis. Aus dem Testverlauf geht hervor, dass GLM-5 nicht direkt mit dem Codieren beginnt, sondern zuerst die Gesamtarchitektur plant: Wie die Module für visuelle Eingabe, Steuerlogik, Rendering und Effekte getrennt werden sollen; wie die Datenflüsse übertragen werden; welche Teile möglicherweise zu Leistungsproblemen führen könnten.

Anschließend implementiert es die Logik Schritt für Schritt, beginnend mit der Datenverarbeitung der Gestenerkennung, über die Berechnung der Abfeuerbahn bis hin zur Parameteroptimierung der Partikelexplosionseffekte.

Wenn das Rendering Stockungen aufweist, schlägt es vor, die Anzahl der Partikel zu reduzieren und die Schleifenstruktur zu optimieren; wenn die Gestenerkennung fehlerhaft ist, passt es die Schwellenwerte und das Filterverfahren an.

Das im Video gezeigte Ergebnis ist eine „natürliche Interaktion“. Dahinter verbirgt sich jedoch eine vollständige Ingenieurskette: Planung → Schreiben → Debugging → Leistungsoberflächen → Interaktionskorrektur.

Der generierte Code kann direkt ausgeführt werden, die Interaktion ist stabil, die Framerate ist gleichmäßig und Ausnahmen können behandelt werden. Wichtig ist, dass seine Arbeitsweise ein klares Systemdenken zeigt: Die Modulgrenzen sind klar definiert, die logische Schichtung ist sinnvoll, anstatt alle Funktionen in einer Datei zu stapeln.

Der zweite Testfall bezieht sich auf die Fähigkeit zur strukturellen Systemgestaltung. Dieser Szenario ist Teil des täglichen Arbeitsalltags von Medienarbeitern – das Importieren einer Interviewaufzeichnung, die Zusammenfassung des Inhalts und die Generierung von Themenideen.

Im Test kann man sehen, dass der Arbeitsablauf sehr direkt ist: Ich habe einen Interview-Transkripttext eingefügt, das Modell hat begonnen zu analysieren und anschließend eine Inhaltszusammenfassung und Themenideen ausgegeben. Die generierten Themenideen sind sehr praktikabel.

Im Vergleich zum visuellen Interaktionssystem scheint die Transkription von Audioaufzeichnungen einfach, aber es prüft die „strukturelle Abstraktionsfähigkeit“ des Modells. Eine echte Interviewaufzeichnung ist oft sehr unstrukturiert: Die Meinungen springen hin und her, die Informationen werden wiederholt und Haupt- und Nebengänge sind miteinander verflochten. In diesem Fall zeigt GLM-5 seine Fähigkeiten auf Systemebene.

Zunächst die Fähigkeit zur Themenerkennung und Extraktion der Hauptlinie. Das Modell generiert keine Zusammenfassung in der Reihenfolge des Originaltexts, sondern es ermittelt zuerst das Kernthema und organisiert dann den Inhalt um dieses Thema herum. Dies bedeutet, dass es intern eine Analyse durchgeführt hat, um zu erkennen, welche Informationen zur Hauptlinie gehören und welche ergänzend oder als Rauschen zu betrachten sind. Diese Fähigkeit ist im Wesentlichen eine Planungsfähigkeit, d. h. es wird vor der Ausgabe ein abstraktes Strukturmodell erstellt.

Zweitens die Fähigkeit zur modularen Neugruppierung. Es gruppiert verwandte Meinungen, die in verschiedenen Absätzen verteilt sind, in einem Modul zusammen. Diese Fähigkeit zur Integration über Absatzgrenzen hinweg zeigt, dass das Modell bei der Verarbeitung langer Texte eine globale Konsistenz aufweist.

Drittens die Fähigkeit zur aktiven Anpassung der logischen Reihenfolge. Das tatsächlich ausgegebene Gliederungsschema unterscheidet sich oft von der Reihenfolge der Originalaufzeichnung. Man kann sehen, dass GLM-5 die Hierarchie basierend auf kausalen Beziehungen oder der Argumentationslogik neu anordnet. Dies zeigt eine Urteilsfähigkeit, die die „Logik vor der ursprünglichen Eingabereihenfolge“ setzt. Dieses Muster von „erst Struktur, dann Ausgabe“ ist der Kern des Systemtechnik-Denkens.

Diese beiden Fälle, ein Echtzeit-visuelles Interaktionssystem und ein System zur Verarbeitung von Medieninformationen, scheinen völlig verschieden zu sein. Aber sie bestätigen dasselbe – GLM-5 verfügt über eine vollständige Fähigkeit zur Aufgabenabwicklung: Planung → Ausführung → Debugging → Optimierung.

Beim Feuerwerksspiel zeigt sich dies in der Modulschichtung, der Leistungsoberflächen und der Behandlung von Ausnahmen; bei der Audio-Transkription zeigt es sich in der Themenerkennung, der strukturellen Zerlegung und der logischen Neugruppierung. Gemeinsam ist beiden, dass das Modell nicht bei der „Generierung von Ergebnissen“ stehenbleibt, sondern eine nachhaltig entwickelbare Struktur aufrechterhält.

Ich habe weiterhin einen relativ komplexen Test durchgeführt, nämlich die „Erstellung eines minimalen Betriebssystemkerns“. In diesem Test ist nicht das wichtigste, dass der Code am Ende funktioniert, sondern die Arbeitsweise von GLM-5 während des gesamten Prozesses.

Es beginnt nicht sofort mit der Generierung, wenn es die Aufgabe erhält, sondern definiert zuerst die Aufgabengrenzen, teilt die Module auf, plant die Systemstruktur und beginnt dann mit der Implementierung. Dieser Ansatz von „Struktur zuerst“ ist im Wesentlichen das oben erwähnte Ingenieursdenken – zuerst definiert man, wie das System aufgebaut ist, und diskutiert dann die Implementierungsdetails, anstatt es im laufenden Prozess zusammenzustöpseln.

Im Laufe mehrerer Schreib-, Ausführungs-, Fehlerbehandlungs- und Korrekturzyklen hat es keine strukturellen Einbrüche gezeigt. Jede Korrektur basiert auf der vorgegebenen Architektur, anstatt die gesamte Arbeit neu zu beginnen oder nur lokale Reparaturen vorzunehmen. Dies zeigt, dass es intern ein vollständiges Systemmodell aufrechterhält und in der Lage ist, in langfristigen Aufgaben die Konsistenz zu wahren. Viele Modelle neigen dazu, widersprüchliche Ergebnisse zu liefern, wenn der Kontext länger wird, aber die Leistung in diesem Video zeigt seine Fähigkeit, die Gesamtstruktur dauerhaft im Gedächtnis zu behalten.

Auch seine Vorgehensweise bei der Fehlerbehandlung ist bemerkenswert. Wenn ein Fehler auftritt, beschränkt es sich nicht auf die oberflächliche Vermutung, dass es sich um ein Problem in einer bestimmten Codezeile handeln könnte, sondern es ermittelt zuerst den Fehlertyp, unterscheidet zwischen logischen Problemen, Umgebungsfragen oder Abhängigkeitskonflikten und plant dann den Untersuchungsweg. Dies ist eine strategische Fehlerbehandlung, die darauf abzielt, den Problemweg zu beheben.

Wenn man die Tool-Integration betrachtet, wird diese Fähigkeit noch deutlicher. Es gibt nicht nur Befehlsvorschläge, sondern koordiniert auch die Ausführung im Terminal, die Analyse von Protokollen, die Reparatur der Umgebung und setzt dann die Aufgabe fort. Diese Vorgehensweise ähnelt bereits einer „Autonomfahrer-ähnlichen“ Ingenieursarbeit. Solange das Ziel nicht erreicht ist, wird es weiter iterieren.

Die vier Kernfähigkeiten, nämlich die Planung vor der Ausführung, die Aufrechterhaltung der strukturellen Stabilität in langfristigen Aufgaben, die strategische Fehlerbehandlung und die kontinuierliche Fortsetzung bis zum Erreichen des Ziels, lassen GLM-5 ein Verhaltensmuster annehmen, das dem eines echten Ingenieurs ähnelt.

02 Warum kann GLM-5 die Rolle des „Architekten“ übernehmen?

Wenn der erste Teil der Tests gezeigt hat, dass GLM-5 „komplexe Aufgaben bewältigen kann“, dann stellt sich die nächste Frage: Warum ist es in der Lage, dies zu tun? Die Antwort liegt in seinem gesamten „Ingenieur-Verhaltensmuster“, das hinter der Ausgabe verborgen ist.

Ein wichtiger Punkt ist, dass GLM-5 offensichtlich einen ähnlichen Selbstprüfungsmechanismus der Denkkette wie Claude Opus 4.6 implementiert hat.

Beim praktischen Einsatz kann man spüren, dass es nicht sofort beginnt, „Code zu füllen“, wenn es eine Aufgabe erhält, sondern es führt im Hintergrund mehrere logische Schritte durch: Es prognostiziert die Kopplungsbeziehungen zwischen den Modulen, vermeidet aktiv Deadlock-Pfade und erkennt frühzeitig Ressourcenkonflikte und Randbedingungen. Dies führt dazu, dass es sich Zeit nimmt, um die Probleme gründlich zu durchdenken, um sicherzustellen, dass das Lösungsansatz technisch tragfähig ist.

Bei komplexen Aufgaben gibt GLM-5 zuerst eine klare Modulzerlegung vor: Welche Teilmodule das System umfasst, was die Eingabe und Ausgabe jedes Moduls ist, welche Teile parallel und welche seriell durchgeführt werden können. Erst dann geht es an die einzelnen Probleme heran, anstatt im laufenden Prozess zu planen. Dies macht seine Arbeitsweise einem echten Ingenieur ähnlicher: Er zeichnet zuerst das Architekturdiagramm und schreibt dann die Implementierungsdetails. Man bemerkt deutlich, dass es eine „Zähigkeit“ hat, die Probleme nicht restlos zu lösen, bevor es aufhört, anstatt nach der Fertigstellung eines scheinbar richtigen Teils vorschnell zu beenden.

Dieser Unterschied wird besonders deutlich, wenn man es mit traditionellen Coding-Modellen vergleicht. Viele Modelle aus der Vergangenheit haben, wenn sie auf einen Fehler stoßen, ein bekanntes Muster: Sie entschuldigen sich, wiederholen die Fehlermeldung und geben einen ungetesteten Reparaturvorschlag; wenn dies erneut fehlschlägt, beginnen sie, ähnliche Antworten zu wiederholen. Die Vorgehensweise von GLM-5 ist eher der eines erfahrenden Architekten. Im Test, wenn das Projekt aufgrund von Abhängigkeiten in der Umgebung nicht ausgeführt werden konnte, hat es nicht auf die oberflächliche Fehlermeldung gestoppt, sondern es hat die Abhängigkeitsstruktur (Dependency Tree) analysiert, die Quelle des Konflikts ermittelt und OpenClaw angewiesen, die Umgebung zu reparieren.

Der gesamte Prozess ähnelt eher einer „Autonomfahrer-ähnlichen“ Bereitstellung: Das Modell reagiert nicht passiv, sondern liest kontinuierlich die Protokolle, korrigiert die Pfade und überprüft die Ergebnisse.

Eine andere oft übersehene, aber in der Systemtechnik extrem wichtige Fähigkeit ist die Vollständigkeit des Kontexts.

Das Millionentoken-Fenster von GLM-5 ermöglicht es, die gesamte Code-Struktur eines Projekts, die Änderungshistorie, die Konfigurationsdateien und die Ausführungs-Logs im gleichen Kontext zu verstehen. Dies bedeutet, dass es in der Lage ist, aus einer globalen Perspektive zu beurteilen, welche Auswirkungen eine Änderung auf die verschiedenen Module haben wird. In langfristigen Aufgaben bestimmt diese Fähigkeit direkt, ob das Modell „klug, aber kurzfristig“ oder „stabil und kontrollierbar“ ist.

Insgesamt kann GLM-5 die Rolle des „Architekten“ übernehmen, weil es wie ein Architekt denkt: Es plant zuerst, führt dann aus; es überprüft kontinuierlich und korrigiert ständig; es achtet auf das Gesamtsystem, anstatt nur auf den Erfolg einzelner Punkte.

Dies ist auch der Grund, warum es die in der ersten Hälfte beschriebenen systemweiten Tests bewältigen kann.

03 Der Opus der Open-Source-Welt?

Im Ökosystem der Großmodelle im Jahr 2026 hat GLM-5 seinen Wert darin, dass es etwas zerschlagen hat, was bisher fast als selbstverständlich akzeptiert wurde: Systemweite KI-Smartness scheint nur in proprietären Modellen möglich zu sein.

Bisher haben Claude Opus 4.6 und GPT-5.3 den Weg des „Agentischen Codings“ bahnbrechend gemacht – die Modelle streben nicht mehr nach sofortigen Ergebnissen, sondern bewältigen echte komplexe Ingenieuraufgaben durch Planung, Aufteilung und wiederholtes Ausführen. Aber der Preis dafür ist hoch: Die Token-Konsumtion bei Hochlastaufgaben ist enorm, und ein vollständiger systemweiter Test bedeutet oft hohe Kosten für den