Åpen kildekodes Opus-øyeblikk: Kan GLM-5 ta over stafettpinnen for Agentic Coding?

Hvis du spør en utvikler, hva er det mest frustrerende øyeblikket med AI-programmering?

Svaret vil sannsynligvis være den mekaniske «Beklager, jeg misforsto» foran en feilmelding, og deretter gjenta en like feilaktig kode.

I løpet av det siste året har fremskrittene innen Coding-modeller hovedsakelig vært reflektert i «genereringsevne»: generere nettsider, komponenter og små spill med én setning – lage en pikselert nettside, et kult SVG-ikon eller et kjørbart Snake-spill på 15 sekunder. Disse demoene er imponerende nok, men også «lette» nok. De er litt som avanserte leker produsert i Vibe Coding-æraen (stemningsprogrammering). Men når det gjelder høykonkurrerende arkitektur, tilpasning av underliggende drivere eller komplekse systemomstruktureringer, blir de «drivhusblomster».

Så nylig har vinden snudd i Silicon Valley.

Enten det er Claude Opus 4.6 eller GPT-5.3, begynner disse toppmodellene å understreke Agentic Coding: ikke strebe etter «raske resultater», men fullføre systemoppgaver gjennom planlegging, dekomponering og gjentatt kjøring.

Dette paradigmeskiftet fra «frontend-estetikk» til «systemteknikk» ble tidligere ansett som et monopolområde for lukkede kjemper. Først etter at jeg testet GLM-5, innså jeg at åpen kildekode-fellesskapets «arkitekt-æra» har startet tidligere enn forventet.

01

**Fra «frontend» til «systemteknikk» **

Tidligere, når man snakket om AI Coding, tenkte man ofte på en kjent fortelling – generere en nettside med én setning, lage et lite spill på ett minutt, sette opp en kul animasjonseffekt på ti sekunder. De understreker «visuell爽感» (visuell爽感): knapper beveger seg, siden er vakker, effektene er rike.

Men de som virkelig er involvert i ingeniørarbeid vet at å generere en demo ikke betyr at man kan støtte et system.

Vanskeligheten med komplekse oppgaver ligger ikke i «å skrive kode», men i hvordan modulene skal deles, hvordan tilstander skal administreres, hvordan unntak skal håndteres, hvordan ytelsen skal optimaliseres, og om strukturen kan opprettholdes når systemet begynner å bli komplekst.

Dette er også grunnen til at vi valgte komplekse oppgaver som testobjekter.

GLM-5s posisjonering er forskjellig fra mange konkurrenter.

Hvis de fleste modeller er mer som en «utmerket frontend» – flinke til å raskt generere interaktive grensesnitt og visuelle effekter, er GLM-5 mer som en «systemteknisk rolle». Den understreker samarbeid mellom flere moduler, lange oppgaver og strukturell stabilitet som kan kjøres i et produksjonsmiljø.

For å bekrefte dette designet vi to testtilfeller med helt forskjellige dimensjoner.

Den første testen er en tilsynelatende enkel, men svært systematisert oppgave – basert på nettleseren og kameraet, implementere et interaktivt nyttårsspill med «AI visuell fjernkontroll av fyrverkeri».

I testvideoen kan du se at brukeren står foran kameraet og styrer fyrverkeriets skyteretning og rytme med gester; fyrverkeriet blomstrer i luften, akkompagnert av partikkeleffekter og dynamiske lyseffekter, og den generelle interaksjonen er jevn og naturlig.

Men dette er ikke et enkelt frontend-animasjonsprosjekt. Det inkluderer minst følgende kjernekomponenter: gjenkjenning av gester og visuell inndatabehandling; kartlegging av gestkoordinater til skyte logikk; fyrverkeri partikkelsystem og blomstringseffekter; sanntidsgjengivelse og bildefrekvenskontroll; nettleserkompatibilitet og unntakshåndtering av kameratillatelser; interaksjonsstatusadministrasjon og tilbakemeldingsmekanisme for brukere

Det kan sies å være et lite interaktivt system med en komplett struktur og jevn opplevelse. Fra testprosessen gikk ikke GLM-5 direkte inn i koding, men planla først den generelle arkitekturen: hvordan visuell inndatamodul, kontrolllogikklag, gjengivelseslag og spesialeffektlag skal skilles; hvordan dataflyten skal overføres; hvilke deler som kan bli ytelsesflaskehalser.

Deretter implementerte den logikken lag for lag, fra databehandlingen av gjenkjenning av gester, til beregningen av skytebanen, og deretter til parameterjusteringen av partikkeleksplosjonseffekten.

Når gjengivelsen henger, foreslår den aktivt å redusere antall partikler og optimalisere løkkestrukturen; når gjenkjenningen av gester er feil, justerer den terskelen og filtreringsstrategien.

Effekten som presenteres i videoen er «en interaksjon som ser veldig naturlig ut». Men det som gjenspeiles bak er en komplett ingeniørkjede: planlegging → skriving → feilsøking → ytelsesoptimalisering → interaksjonskorreksjon.

Den endelige genererte koden kan kjøres direkte, interaksjonen er stabil, bildefrekvensen er jevn og unntak kan håndteres. Enda viktigere er at arbeidsmåten viser en klar systemtenkning: modulære grenser er klare, logisk lagdeling er rimelig, i stedet for å stable alle funksjoner i en fil.

Den andre saken tester strukturelle systemevner. Dette scenariet kan sies å være det daglige arbeidet i mediearbeid – importere et intervjuutskrift, oppsummere innholdet og gi forslag til emnevinkler og ideer.

Som du kan se i testvideoen, er driftsprosessen veldig direkte: Jeg limte inn et intervjuutskrift for en stund siden, modellen begynte å analysere, og deretter ga den en oppsummering av innholdet og emnevinkler. Fra resultatene er emnevinklene den genererte er fortsatt veldig operasjonelle.

Sammenlignet med visuelle interaktive systemer virker lydsortering enkelt, men det tester faktisk modellens «strukturelle abstraksjonsevne». Et ekte intervjuopptak er ofte svært ustrukturert: synspunkter hopper, informasjon gjentas, hovedlinjer og sidelinjer er sammenvevd. Så i dette tilfellet er evnen som GLM-5 viser, på systemnivå.

Først av alt er evnen til å identifisere temaer og trekke ut hovedlinjer. Modellen genererer ikke et sammendrag i rekkefølgen av den originale teksten, men bedømmer først hva kjernetemaet er, og organiserer deretter innholdet på nytt rundt dette temaet. Dette betyr at den fullfører en skanning internt for å identifisere hvilken informasjon som tilhører hovedlinjen og hvilken som er et supplement eller støy. Denne evnen er i hovedsak planleggingsevne, det vil si å etablere et abstrakt strukturrammeverk før utdata.

For det andre er det evnen til å modulært omorganisere. Den vil kategorisere relaterte synspunkter spredt i forskjellige avsnitt i samme modul. Denne evnen til å integrere på tvers av avsnitt indikerer at modellen har global konsistens når den behandler lange tekster.

For det tredje er evnen til å aktivt justere den logiske rekkefølgen. Den faktiske utgangen er ofte forskjellig fra den opprinnelige opptaksrekkefølgen. Det kan sees at GLM-5 har omorganisert nivåene i henhold til årsak og virkning eller argumentasjonslogikk. Dette gjenspeiler en dømmekraft som «logikk prioriteres fremfor den opprinnelige inndatarekkefølgen». Denne «struktur først, utgang etterpå»-modusen er kjernen i systemteknisk tenkning.

Disse to sakene, den ene er et visuelt interaktivt sanntidssystem, og den andre er et system for behandling av mediainformasjon, virker helt forskjellige. Men de bekrefter det samme – GLM-5 har en komplett oppgavesløyfeevne: planlegging → utførelse → feilsøking → optimalisering.

I fyrverkerispillet gjenspeiles dette i modulær lagdeling, ytelsesoptimalisering og unntakshåndtering; i lydprosessoren gjenspeiles dette i temabedømmelse, strukturell dekomponering og logisk omorganisering. Felles for dem er at modellen ikke stopper ved «generering av resultater», men opprettholder en struktur som kan utvikles bærekraftig.

Jeg fortsatte å prøve en relativt kompleks oppgave, «bygge en minimalistisk operativsystemkjerne». I denne testen er det som virkelig er verdt å merke seg, ikke at koden i videoen til slutt kjører, men GLM-5s oppførsel gjennom hele prosessen.

Den gikk ikke umiddelbart inn i genereringstilstand etter å ha mottatt oppgaven, men avklarte først oppgavegrensene, dekomponerte aktivt moduler, planla systemstrukturen og gikk deretter inn i implementeringsfasen. Denne «struktur først»-banen er i hovedsak den ingeniørtenkningen som er nevnt tidligere – definer først hvordan systemet skal komponeres, og diskuter deretter de spesifikke implementeringsdetaljene, i stedet for å skrive og sette sammen samtidig.

I syklusen med flere runder med skriving, kjøring, feilrapportering og korrigering, dukket det heller ikke opp noen strukturell kollaps i GLM-5. Hver modifikasjon er sentrert rundt den etablerte arkitekturen, i stedet for å velte den og starte på nytt eller lappe den lokalt. Dette indikerer at den opprettholder en komplett systemmodell internt og kan opprettholde konsistens i lange oppgaver. Mange modeller har en tendens til å være selvmotsigende etter at konteksten er utvidet, mens ytelsen i videoen gjenspeiler dens evne til å kontinuerlig huske den generelle strukturen.

Det er også måten den håndterer feil på. Når en feil oppstår, stopper den ikke ved den overfladiske gjetningen om at «det kan være et problem med en linje med kode», men bedømmer først feiltypen, skiller mellom logiske problemer, miljøproblemer eller avhengighetskonflikter, og planlegger deretter feilsøkingsbanen. Dette er en strategisk feilsøking som tar sikte på å fikse problembanen.

Hvis det kombineres med verktøyoppkall, vil denne evnen være enda tydeligere. Den gir ikke bare kommandoforslag, men kombinerer også aktiv planlegging av terminalutførelse, analyse av logger, reparasjon av miljøet og fortsetter deretter å fremme oppgaven. Denne oppførselen nærmer seg allerede en «selvkjørende» ingeniørfremdrift. Hvis målet ikke er fullført, vil det fortsette å iterere.

Planlegg først og utfør deretter, oppretthold strukturell stabilitet i lange lenker, feilsøk problemer strategisk og fortsett å fremme rundt målet – kombinasjonen av de fire kjernekompetansene som kreves av systemteknikk, gjør at GLM-5 begynner å vise en atferdsmønster som nærmer seg ingeniørens arbeidsmåte.

Hvorfor kan GLM-5 ta over stafettpinnen til «arkitekten»?

Hvis den første delen av testen beviste at GLM-5 «kan gjøre komplekse jobber», er det neste spørsmålet: Hvorfor kan den det? Svaret ligger i et helt sett med «ingeniørnivå atferdsmønstre» skjult bak utgangen.

Et viktig poeng er at GLM-5 åpenbart har introdusert en selvinspeksjonsmekanisme for tankekjeder som ligner Claude Opus 4.6.

I faktisk bruk kan du føle at den ikke begynner å «fylle ut kode» umiddelbart etter å ha mottatt oppgaven, men utfører flere runder med logisk deduksjon i bakgrunnen: forutsi koblingsforholdet mellom moduler, aktivt unngå dødløpsbaner og oppdage ressurskonflikter og grensebetingelsesproblemer på forhånd. Den direkte endringen som denne oppførselen bringer er – for å sikre at planen er ingeniørmessig forsvarlig, er den villig til å bremse ned og tenke fullstendig gjennom problemet.

I komplekse oppgaver vil GLM-5 først gi en klar modulær dekomponering: hvilke undermoduler systemet består av, hva er inngangen og utgangen til hver modul, hvilke deler kan fremmes parallelt, og hvilke som må fullføres sekvensielt. Deretter vil den overvinne dem en etter en, i stedet for å skrive og tenke samtidig. Dette gjør at arbeidsmåten ligner mer på en ekte ingeniør: tegn først arkitekturdiagrammet, og skriv deretter implementeringsdetaljene. Det er tydelig at den har en slags «seighet til ikke å stoppe før problemet er løst rent», i stedet for å avslutte raskt etter å ha fullført en tilsynelatende korrekt lokal del.

Denne forskjellen er spesielt tydelig i sammenligning med tradisjonelle Coding-modeller. Tidligere ville mange modeller raskt gli inn i et kjent mønster når de støter på feil: beklage, gjenta feilinformasjonen og gi et ubekreftet reparasjonsforslag; hvis det mislykkes igjen, vil det begynne å sende ut omtrentlige svar i en sløyfe. GLM-5s håndteringsmetode er nærmere en gammel arkitekt. I testen, når prosjektet ikke kunne kjøre på grunn av miljøavhengighetsproblemer, stoppet det ikke ved den overfladiske feilinformasjonen, men analyserte aktivt avhengighetstreet (Dependency Tree), bedømte kilden til konflikten og dirigerte OpenClaw til å reparere miljøet ytterligere.

Hele prosessen er mer som en «selvkjørende» distribusjon: modellen reagerer ikke passivt, men leser kontinuerlig logger, korrigerer baner og verifiserer resultater.

En annen evne som ofte overses, men som er ekstremt viktig i systemteknikk, er kontekstuell integritet.

GLM-5s vindu på millioner av Token gjør det i stand til å forstå hele prosjektets kodestruktur, historiske modifikasjoner, konfigurasjonsfiler og kjørelogger i samme kontekst. Dette betyr at den allerede kan bedømme hvilke moduler en modifikasjon vil ha en kjedereaksjon på fra et globalt perspektiv. I lange oppgaver bestemmer denne evnen direkte om modellen er «smart, men kortsynt» eller «stabil og kontrollerbar».

Samlet sett er hovedårsaken til at GLM-5 virkelig tar over rollen som «arkitekt» at den begynner å tenke på problemer som en arkitekt: planlegg først, utfør deretter; kontinuerlig verifiser, kontinuerlig korriger; fokuser på systemet som helhet, i stedet for enkeltsuksess.

Dette er også den grunnleggende årsaken til at den kan fullføre de systemnivåtestoppgavene i første del.

03

**Åpen kildekodes Opus? **

Sett i sammenheng med økosystemet for store modeller i 2026, ligger verdien av GLM-5 mer i at den bryter et faktum som tidligere nesten ble akseptert som standard: intelligens på systemnivå ser ut til å bare eksistere i lukkede modeller.

Tidligere har Claude Opus 4.6 og GPT-5.3 virkelig kjørt gjennom veien til «Agentic Coding» – modellen streber ikke lenger etter umiddelbar tilbakemelding, men fullfører virkelig komplekse ingeniøroppgaver gjennom planlegging, dekomponering og gjentatt kjøring. Men prisen er også høy: Token-forbruket for oppgaver med høy intensitet er ekstremt høyt, og et komplett forsøk på systemnivå betyr ofte betydelige kostnader for oppkall.

GLM-5 gir her en annen løsning. Som en åpen kildekode-modell bringer den «AI på systemarkitektnivå» tilbake til utviklernes eget miljø fra skyen og regningene. Du kan distribuere den lokalt og la den bruke tid på å tygge de skitne, slitsomme og store jobbene: justere logger, sjekke avhengigheter, endre gammel kode og fylle ut grensebetingelser.

Dette kan sees på som en strukturell endring i kostnadseffektivitet – intelligens på arkitektnivå er ikke lenger et privilegium for et fåtall team.

Hvis du forstår denne forskjellen med en yrkesmetafor, vil det være mer intuitivt. Modeller som Kimi 2.5 er mer som utmerkede frontend-ingeniører med estetikk på nett og sterk interaksjonsfølelse, flinke til One-shot-generering, visuell presentasjon og rask tilbakemelding; mens stilen til GLM-5 er åpenbart forskjellig, er den mer som en erfaren systemarkitekt som holder seg til bunnlinjen og vektlegger logikk: fokuserer på modulære forhold, unntaksbaner, vedlikeholdsevne og langsiktig stabil drift.

Bak dette ligger faktisk et tydelig yrkesmessig fremskritt for programmerings-AI – fra å forfølge «ser veldig爽» (ser veldig爽) Vibe Coding til å understreke robusthet og ingeniørdisiplin.

Enda viktigere er at fremveksten av GLM-5 gjør konseptet med en enmannsbedrift mer gjennomførbart. Når en utvikler lokalt kan ha en AI-partner som forstår systemdesign, kan kjøre over lang tid og kan korrigere seg selv, begynner mye ingeniørarbeid som opprinnelig krevde et team, å bli komprimert til et omfang som kan kontrolleres av enkeltpersoner. Deretter har GLM-5 potensial til å bli den «digitale partneren» som er ansvarlig for kjerneingeniørimplementering i et enmannsselskap.