Open source-verdenens Opus-øjeblik: Kan GLM-5 gribe stafetten fra Agentic Coding?

Hvis du spørger en udvikler, hvad der er det mest frustrerende øjeblik ved AI-programmering,

vil svaret sandsynligvis være den mekaniske "Beklager, jeg misforstod" foran en fejlmeddelelse, efterfulgt af en gentagelse af den samme forkerte kode.

I løbet af det seneste år har fremskridtene inden for Coding-modeller primært været inden for "genereringsevne": generering af websider, komponenter og små spil med en enkelt sætning - skab en pixel-stil webside, et cool SVG-ikon eller et kørende Snake-spil på 15 sekunder. Disse demoer er imponerende nok, men også "lette" nok, og de minder om avanceret legetøj produceret i Vibe Coding-æraen. Men når det kommer til højkonkurrencearkitektur, tilpasning af underliggende drivere eller kompleks systemomstrukturering, bliver de til "drivhusblomster".

Så for nylig har vinden skiftet i Silicon Valley.

Uanset om det er Claude Opus 4.6 eller GPT-5.3, begynder disse topmodeller at understrege Agentic Coding: ikke at stræbe efter "øjeblikkelige resultater", men at fuldføre systemniveauopgaver gennem planlægning, dekonstruktion og gentagen kørsel.

Dette paradigmeskift fra "frontend-æstetik" til "systemteknik" blev engang betragtet som et monopolområde for lukkede kilder. Det var først, da jeg testede GLM-5, at jeg indså, at open source-fællesskabets "arkitektæra" var startet tidligt.

01

**Fra "frontend" til "systemteknik" **

Tidligere, når man talte om AI Coding, tænkte de fleste på en velkendt fortælling - generering af en webside med en enkelt sætning, et lille spil på et minut og en cool effekt på ti sekunder. De understreger "visuel spænding": knapper bevæger sig, sider er smukke, og effekter er rige.

Men alle, der virkelig er kommet ind i ingeniørscenen, ved, at det at kunne generere en demo ikke er det samme som at kunne understøtte et system.

Sværhedsgraden af komplekse opgaver ligger ikke i "at skrive kode", men i hvordan man dekomponerer moduler, hvordan man administrerer tilstande, hvordan man håndterer undtagelser, hvordan man optimerer ydeevnen, og om man kan opretholde strukturel stabilitet, når systemet begynder at blive komplekst.

Dette er også grunden til, at vi vælger komplekse opgaver som testobjekter.

GLM-5's positionering er forskellig fra mange konkurrenters.

Hvis de fleste modeller er mere som en "fremragende frontend" - dygtige til hurtigt at generere interaktive grænseflader og visuelle effekter, så er GLM-5 mere orienteret mod en "systemteknisk rolle". Den understreger samarbejde mellem flere moduler, lange kædeopgaver og strukturel stabilitet, der kan køre i et produktionsmiljø.

For at verificere dette designede vi to testcases med helt forskellige dimensioner.

Den første test er en tilsyneladende let, men meget systematisk opgave - at implementere et interaktivt nytårstema-spil med "AI-visuel fjernstyring af fyrværker" baseret på en browser og et kamera.

I testvideoen kan du se, at brugeren står foran kameraet og styrer fyrværkeriets affyringsretning og rytme med håndbevægelser; fyrværkeriet blomstrer i luften, ledsaget af partikeleffekter og dynamisk lyseffektfeedback, og den overordnede interaktion er jævn og naturlig.

Men dette er ikke et simpelt frontend-effektprojekt. Det omfatter mindst følgende kernemoduler: håndbevægelsesgenkendelse og visuel inputbehandling; kortlægning af håndbevægelseskoordinater til affyringslogik; fyrværkeripartikelsystem og blomstringseffekter; realtidsgengivelse og billedhastighedskontrol; browserkompatibilitet og unormal kameratilladelseshåndtering; interaktionsstatushåndtering og brugerfeedbackmekanismer.

Det kan siges at være et lille interaktivt system med en komplet struktur og en jævn oplevelse. Fra testprocessen kan det ses, at GLM-5 ikke gik direkte ind i kodningen, men først planlagde den overordnede arkitektur: hvordan man adskiller det visuelle inputmodul, det logiske kontrollag, gengivelseslaget og effektlaget; hvordan man overfører datastrømmen; hvilke dele der kan blive flaskehalse for ydeevnen.

Efterfølgende implementerede den logikken lag for lag, startende med databehandlingen af håndbevægelsesgenkendelse, til beregningen af affyringsbanen og derefter til parameterjusteringen af partikeleksplosionseffekten.

Når gengivelsen er langsom, foreslår den proaktivt at reducere antallet af partikler og optimere løkkestrukturen; når håndbevægelsesgenkendelsen er fejlagtig, justerer den tærskelværdien og filtreringsstrategien.

Effekten, der præsenteres i videoen, er "en interaktion, der ser meget naturlig ud". Men bag den afspejles en komplet ingeniørkæde: planlægning → skrivning → debugging → ydeevneoptimering → interaktionskorrektion.

Den endelige genererede kode kan køres direkte, interaktionen er stabil, billedhastigheden er jævn, og unormale situationer kan håndteres. Endnu vigtigere er det, at dens arbejdsmetode præsenterer en klar systemtænkning: modulgrænser er klare, logisk lagdeling er rimelig, i stedet for at stable alle funktioner i en enkelt fil.

Den anden case tester strukturelle systemfunktioner. Dette scenarie kan siges at være rutine i mediearbejde - importere en transskription af et interview, opsummere indholdet og output emnevinkler og ideer.

I testningen kan du se, at driftsprocessen er meget direkte: Jeg indsatte en transskription af et interview fra for nylig, modellen begyndte at analysere, og derefter output indholdsoversigten og emnevinklerne. Ud fra resultaterne er de emnevinkler, den genererede, stadig meget operationelle.

Sammenlignet med visuelle interaktionssystemer ser lydoptagelse enkel ud, men den tester faktisk modellens "strukturelle abstraktionsevne". En ægte interviewoptagelse er ofte meget ustruktureret: synspunkter hopper, information gentages, og hovedlinjer og sidelinjer er sammenvævet. Så i dette tilfælde er den evne, som GLM-5 viser, på systemniveau.

For det første er det evnen til at identificere temaer og udtrække hovedlinjer. Modellen genererer ikke et resumé i rækkefølgen af den originale tekst, men vurderer først, hvad kerneemnet er, og omorganiserer derefter indholdet omkring dette emne. Det betyder, at den har gennemført en scanning internt for at identificere, hvilke oplysninger der hører til hovedlinjen, og hvilke der er supplementer eller støj. Denne evne er i det væsentlige planlægningsevne, det vil sige at etablere en abstrakt strukturramme, før der outputtes.

For det andet er det evnen til at omstrukturere moduler. Den vil kategorisere relaterede synspunkter spredt i forskellige afsnit i det samme modul. Denne evne til at integrere på tværs af afsnit indikerer, at modellen har global konsistens, når den behandler lange tekster.

For det tredje er det den aktive justeringsevne af logisk rækkefølge. Den faktiske output-oversigt er ofte forskellig fra den originale optagelsesrækkefølge. Det kan ses, at GLM-5 har omarrangeret niveauerne i henhold til årsagssammenhæng eller argumentationslogik. Dette afspejler en dømmekraft, der "prioriterer logik frem for den originale inputrækkefølge". Denne "struktur først, output bagefter"-tilstand er kernen i systemteknisk tænkning.

Disse to cases, den ene er et visuelt interaktivt realtidssystem, og den anden er et medieinformationsstruktureringssystem, ser helt forskellige ud. Men de verificerer den samme ting - GLM-5 har en komplet opgaveafslutningsevne: planlægning → udførelse → debugging → optimering.

I fyrværkerispillet afspejles dette i modulopdeling, ydeevneoptimering og undtagelseshåndtering; i lydoptageren afspejles dette i temaidentifikation, strukturdekonstruktion og logisk omstrukturering. Fælles for dem er, at modellen ikke stopper ved "generering af resultater", men opretholder en struktur, der kan udvikle sig bæredygtigt.

Jeg fortsatte med at prøve en relativt kompleks opgave, "opbygning af en minimalistisk operativsystemkerne". I denne test er det, der virkelig er værd at bemærke, ikke at koden i videoen til sidst kører igennem, men GLM-5's adfærd i hele processen.

Den gik ikke straks i gang med at generere, da den modtog opgaven, men afklarede først opgavegrænserne, dekonstruerede aktivt moduler, planlagde systemstrukturen og gik derefter ind i implementeringsfasen. Denne "struktur først"-sti er i det væsentlige den ingeniørtænkning, der blev nævnt tidligere - først definere, hvordan systemet er sammensat, og derefter diskutere specifikke implementeringsdetaljer, i stedet for at skrive og sammensætte.

I cyklussen med gentagen skrivning, kørsel, fejlrapportering og rettelse optrådte der heller ingen strukturkollaps i GLM-5. Hver ændring er centreret omkring den etablerede arkitektur i stedet for at omstøde og starte forfra eller lappe lokalt. Dette indikerer, at den opretholder en komplet systemmodel internt og kan opretholde konsistens i lange kædeopgaver. Mange modeller er tilbøjelige til at modsige sig selv, når konteksten forlænges, men ydeevnen i videoen afspejler netop dens evne til løbende at huske den overordnede struktur.

Der er også den måde, den håndterer fejl på. Når der opstår en fejl, stopper den ikke ved den overfladiske gætning om, at "det kan være et problem med en bestemt kodelinje", men vurderer først fejlens type, skelner mellem logiske problemer, miljøproblemer eller afhængighedskonflikter og planlægger derefter en fejlfindingssti. Dette er en strategisk debugging, der har til formål at reparere problemstien.

Hvis det kombineres med værktøjsopkald, vil denne evne være mere tydelig. Den giver ikke kun kommandoforslag, men kombinerer også aktiv planlægning af terminaludførelse, analyse af logfiler, reparation af miljøet og fortsætter derefter med at fremme opgaven. Denne adfærd er allerede tæt på en "selvkørende" ingeniørfremgang. Hvis målet ikke er nået, vil det fortsætte med at iterere.

Planlæg først og udfør derefter, oprethold strukturel stabilitet i lange kæder, undersøg problemer strategisk og fortsæt med at fremme omkring målet - det er kombinationen af de fire kernekompetencer, der kræves af systemteknik, der gør, at GLM-5 begynder at udvise en adfærdsmønster, der ligner en ingeniørs arbejdsmetode.

Hvorfor kan GLM-5 gribe stafetten fra "arkitekten"?

Hvis den første del af testen beviser, at GLM-5 "kan udføre komplekse opgaver", så er det næste spørgsmål: Hvorfor kan den det? Svaret ligger i dens komplette sæt af "ingeniørmæssige adfærdsmønstre" skjult bag outputtet.

Et vigtigt punkt er, at GLM-5 tydeligvis har introduceret en kæde af tænkning-selvkontrolmekanisme svarende til Claude Opus 4.6.

I praktisk brug kan du mærke, at den ikke straks begynder at "fylde kode", når den modtager en opgave, men udfører flere runder af logisk deduktion i baggrunden: forudser koblingsforholdet mellem moduler, undgår aktivt dødløbsstier og opdager ressourcekonflikter og grænsebetingelsesproblemer på forhånd. Den direkte ændring, som denne adfærd bringer, er - for at sikre, at planen kan stå på egne ben ingeniørmæssigt, er den villig til at sætte farten ned og tænke problemet igennem fuldt ud.

I komplekse opgaver vil GLM-5 først give en klar moduldekonstruktion: hvilke undermoduler systemet består af, hvad input og output er for hvert modul, hvilke dele der kan fremmes parallelt, og hvilke der skal udføres serielt. Derefter vil den overvinde dem en efter en i stedet for at skrive og tænke på samme tid. Dette gør dens arbejdsmetode mere som en rigtig ingeniør: tegne en arkitektur først og derefter skrive implementeringsdetaljer. Det er tydeligt, at den har en slags "vedholdenhed til ikke at stoppe, før problemet er løst fuldstændigt" i stedet for at afslutte overfladisk efter at have fuldført en tilsyneladende korrekt lokal del.

Denne forskel er især tydelig i sammenligningen med traditionelle Coding-modeller. Tidligere ville mange modeller hurtigt glide ind i et velkendt mønster, når de stødte på en fejl: undskylde, gentage fejlinformationen og give et ubekræftet reparationsforslag; hvis det mislykkes igen, vil det begynde at outputte omtrentlige svar i en cyklus. GLM-5's håndteringsmetode er tættere på en gammel arkitekt. I testningen, når projektet ikke kunne køre på grund af miljøafhængighedsproblemer, stoppede den ikke ved den overfladiske fejlmeddelelse, men analyserede aktivt afhængighedstræet (Dependency Tree), vurderede konfliktkilden og instruerede yderligere OpenClaw til at reparere miljøet.

Hele processen er mere som en "selvkørende" implementering: modellen reagerer ikke passivt, men læser løbende logfiler, retter stier og verificerer resultater.

En anden evne, der ofte overses, men er ekstremt vigtig i systemteknik, er kontekstuel integritet.

GLM-5's vindue på millioner af tokens gør det i stand til at forstå hele projektets kodestruktur, historiske ændringer, konfigurationsfiler og kørselslogfiler i den samme kontekst. Det betyder, at den allerede er i stand til at vurdere, hvilke moduler en ændring vil have en kædereaktion på fra et globalt perspektiv. I lange kædeopgaver afgør denne evne direkte, om modellen er "smart, men nærsynet" eller "stabil og kontrollerbar".

Samlet set er GLM-5's evne til virkelig at gribe "arkitekt"-rollen primært, fordi den begynder at tænke på problemer som en arkitekt: planlæg først, og udfør derefter; løbende verificere og løbende rette; fokusere på systemet som helhed i stedet for enkeltpunkts succes.

Dette er også den grundlæggende årsag til, at den er i stand til at fuldføre de systemniveau-testopgaver i den første del.

03

**Open source-verdenens Opus? **

Set i 2026's store modeløkosystem ligger GLM-5's værdi mere i, at den bryder en ting, der tidligere næsten var blevet accepteret som standard: intelligens på systemniveau ser ud til kun at eksistere i lukkede kildemodeller.

Tidligere har Claude Opus 4.6 og GPT-5.3 virkelig kørt stien til "Agentic Coding" igennem - modellen stræber ikke længere efter øjeblikkelig feedback, men fuldfører virkelig komplekse ingeniøropgaver gennem planlægning, dekonstruktion og gentagen kørsel. Men prisen er også høj: Token-forbruget af højintensitetsopgaver er ekstremt højt, og et komplet forsøg på systemniveau betyder ofte betydelige opkaldsomkostninger.

GLM-5 giver her en anden løsning. Som en open source-model bringer den "AI på systemarkitektniveau" tilbage fra skyen og regningerne til udviklernes eget miljø. Du kan implementere den lokalt og lade den bruge tid på at gnave i de beskidte, kedelige og store opgaver: justere logfiler, kontrollere afhængigheder, ændre gammel kode og supplere grænsebetingelser.

Dette kan ses som en strukturel ændring af omkostningseffektivitet - intelligens på arkitektniveau er ikke længere et privilegium for et fåtal af teams.

Hvis du forstår denne forskel med en professionel metafor, vil den være mere intuitiv. Modeller som Kimi 2.5 er mere som fremragende frontend-ingeniører med æstetik online og stærk interaktion, dygtige til One-shot-generering, visuel præsentation og hurtig feedback; og GLM-5's stil er markant anderledes, den er mere som en senior systemarkitekt, der holder sig til bundlinjen og vægter logik: fokus på modulforhold, unormale stier, vedligeholdelighed og langsigtet stabil drift.

Bag dette ligger faktisk et klart professionelt fremskridt inden for programmerings-AI - fra at forfølge "ser godt ud" Vibe Coding til at understrege robusthed og ingeniørdisciplin Engineering.

Vigtigere er det, at fremkomsten af GLM-5 gør konceptet med en enmandshær mere realiserbart.Når en udvikler lokalt kan have en AI-partner, der forstår systemdesign, kan køre langsigtet og kan selvkorrigere, begynder mange ingeniøropgaver, der oprindeligt krævede et team, at blive komprimeret til et omfang, der kan kontrolleres af en enkelt person. Herefter har GLM-5 potentiale til at blive den "digitale partner", der er ansvarlig for den centrale ingeniørimplementering i en enkeltmandsvirksomhed.