Atvirojo kodo „Opus“ momentas: ar GLM-5 gali perimti estafetę iš Agentic Coding?

Jei paklaustumėte kūrėjo, kuris AI programavimo momentas labiausiai vargina?

Atsakymas greičiausiai būtų mechaniškas „Atsiprašau, aš neteisingai supratau“ priešais klaidą, o tada pakartojamas tas pats klaidingas kodas.

Per pastaruosius metus „Coding“ didelių modelių pažanga labiau atsispindėjo „generavimo galimybėse“: vienu sakiniu generuojamas tinklalapis, komponentas, mažas žaidimas – per 15 sekundžių sukuriamas pikselių stiliaus tinklalapis, šauni SVG piktograma arba paleidžiamas gyvatės žaidimas. Šie demonstraciniai įrašai yra pakankamai nuostabūs, bet ir pakankamai „lengvi“, jie šiek tiek panašūs į aukštos klasės žaislus, sukurtus „Vibe Coding“ (atmosferinio programavimo) eroje. Tačiau, kai kalbama apie didelio lygiagretaus apdorojimo architektūrą, pagrindinio lygmens tvarkyklių pritaikymą ar sudėtingą sistemos pertvarkymą, jie tampa „šiltnamio gėlėmis“.

Taigi pastaruoju metu Silicio slėnio vėjas pasikeitė.

Nesvarbu, ar tai būtų „Claude Opus 4.6“, ar „GPT-5.3“, šie aukščiausio lygio dideli modeliai pradeda pabrėžti „Agentic Coding“: nesiekiama „greitų rezultatų“, o planuojant, išskaidant, pakartotinai vykdant, atliekamos sistemos lygmens užduotys.

Šis paradigmos poslinkis nuo „priekinės dalies estetikos“ prie „sistemų inžinerijos“ anksčiau buvo laikomas uždarų šaltinių milžinų monopolija. Tik išbandęs GLM-5 supratau, kad atvirojo kodo bendruomenės „architektų era“ prasidėjo anksčiau laiko.

01

**Nuo „priekinės dalies“ iki „sistemų inžinerijos“ **

Anksčiau, kalbant apie AI programavimą, dažniausiai galvojama apie pažįstamą pasakojimą – vienu sakiniu sugeneruojamas tinklalapis, per minutę sukuriamas mažas žaidimas, per dešimt sekundžių sukuriamas šaunus dinaminis efektas. Jie pabrėžia „vizualinį malonumą“: mygtukai juda, puslapis gražus, efektų daug.

Tačiau tie, kurie iš tikrųjų patenka į inžinerijos vietą, žino, kad sugeneruoti demonstracinį įrašą nereiškia, kad galima palaikyti sistemą.

Sudėtingų užduočių sunkumas slypi ne „kodo rašyme“, o tame, kaip išskaidyti modulius, kaip valdyti būsenas, kaip užtikrinti išimčių valdymą, kaip optimizuoti našumą ir ar sistema, kai ji tampa sudėtinga, vis dar gali išlaikyti struktūros stabilumą.

Štai kodėl pasirinkome sudėtingas užduotis kaip realaus pasaulio bandymo objektus.

GLM-5 pozicionavimas skiriasi nuo daugelio konkurentų.

Jei dauguma modelių labiau panašūs į „puikią priekinę dalį“ – jie gerai greitai generuoja sąsajas ir vaizdo efektus, tai GLM-5 labiau linkęs į „sistemų inžinerijos vaidmenį“. Jis pabrėžia kelių modulių bendradarbiavimą, ilgos grandinės užduotis ir struktūrinį stabilumą, kuris gali būti vykdomas gamybos aplinkoje.

Norėdami tai patvirtinti, sukūrėme du visiškai skirtingų dimensijų realaus pasaulio bandymų atvejus.

Pirmasis testas – atrodytų lengva, bet iš tikrųjų labai sisteminga užduotis – sukurti „AI vizualiai valdomų fejerverkų“ pavasario šventės teminį interaktyvų žaidimą, pagrįstą naršykle ir kamera.

Realaus pasaulio bandymo vaizdo įraše matyti, kad vartotojas stovi priešais kamerą ir gestais valdo fejerverkų paleidimo kryptį ir ritmą; fejerverkai žydi ore, lydimi dalelių efektų ir dinaminės šviesos efektų grįžtamojo ryšio, o bendras sąveika yra sklandi ir natūrali.

Tačiau tai nėra paprastas priekinės dalies dinaminis efektų projektas. Jame yra bent keli pagrindiniai moduliai: gestų atpažinimas ir vaizdo įvesties apdorojimas; gestų koordinačių atvaizdavimas į paleidimo logiką; fejerverkų dalelių sistema ir žydėjimo efektas; realaus laiko atvaizdavimas ir kadrų dažnio valdymas; naršyklės suderinamumas ir kameros leidimų išimčių valdymas; sąveikos būsenos valdymas ir vartotojo grįžtamojo ryšio mechanizmas

Galima sakyti, kad tai yra maža interaktyvi sistema su pilna struktūra ir sklandžia patirtimi. Žvelgiant iš realaus pasaulio bandymo proceso, GLM-5 ne iš karto pradėjo koduoti, o pirmiausia suplanavo bendrą architektūrą: kaip atskirti vaizdo įvesties modulį, valdymo logikos sluoksnį, atvaizdavimo sluoksnį ir specialiųjų efektų sluoksnį; kaip perduoti duomenų srautą; kurios dalys gali tapti našumo kliūtimis.

Vėliau jis palaipsniui įgyvendino logiką, pradedant nuo gestų atpažinimo duomenų apdorojimo, baigiant paleidimo trajektorijos skaičiavimu ir dalelių sprogimo efekto parametrų optimizavimu.

Kai atvaizdavimas užstringa, jis aktyviai siūlo sumažinti dalelių skaičių ir optimizuoti ciklo struktūrą; kai gestų atpažinimas klaidingai įvertina, jis koreguoja slenkstį ir filtravimo strategiją.

Vaizdo įraše pateiktas efektas yra „atrodytų natūrali sąveika“. Tačiau už jo slypi visa inžinerinė grandinė: planavimas → rašymas → derinimas → našumo optimizavimas → sąveikos koregavimas.

Galiausiai sugeneruotas kodas gali būti tiesiogiai paleistas, sąveika yra stabili, kadrų dažnis sklandus, o išimtis galima apdoroti. Dar svarbiau, kad jo darbo būdas atspindi aiškų sisteminį mąstymą: modulio ribos yra aiškios, logikos sluoksniavimas pagrįstas, o ne visos funkcijos sukraunamos į vieną failą.

Antrasis atvejo testas yra struktūrinės sistemos galimybės. Šią sceną galima pavadinti įprastu žiniasklaidos darbo – importuoti interviu stenogramą, apibendrinti turinį, pateikti temos kampus ir idėjas.

Realaus pasaulio bandyme matyti, kad veikimo procesas yra labai tiesioginis: įklijavau neseniai daryto interviu stenogramos turinį, modelis pradėjo analizuoti, o vėliau pateikė turinio santrauką ir temos kampus. Žvelgiant iš rezultatų perspektyvos, jo sugeneruoti temos kampai vis dar yra labai praktiški.

Palyginti su vizualine sąveikos sistema, įrašų tvarkymas atrodo paprastas, tačiau iš tikrųjų jis išbando modelio „struktūros abstrakcijos galimybes“. Tikras interviu įrašas dažnai yra labai nestruktūrizuotas: nuomonės šokinėja, informacija kartojasi, pagrindinės ir šalutinės linijos susipynusios. Taigi šiame atveju GLM-5 parodė savo galimybes sistemos lygiu.

Pirma, temos atpažinimo ir pagrindinės linijos ištraukimo galimybės. Modelis nesugeneravo santraukos pagal pradinį teksto eiliškumą, o pirmiausia nustatė, koks yra pagrindinis klausimas, o tada pertvarkė turinį aplink šį klausimą. Tai reiškia, kad jis atliko nuskaitymą viduje, atpažindamas, kuri informacija priklauso pagrindinei linijai, o kuri yra papildoma ar triukšmas. Ši galimybė iš esmės yra planavimo galimybė, tai yra, prieš pateikiant išvestį, pirmiausia sukuriamas abstraktus struktūros karkasas.

Antra, modulinio pertvarkymo galimybės. Jis suskirstys susijusias nuomones, išsibarsčiusias skirtingose pastraipose, į tą patį modulį. Ši tarp pastraipų integravimo galimybė rodo, kad modelis, apdorodamas ilgą tekstą, turi visuotinį nuoseklumą.

Trečia, aktyvus logikos sekos koregavimo galimybės. Faktinė išvesties schema dažnai skiriasi nuo pradinio įrašo eiliškumo. Galima pastebėti, kad GLM-5 iš naujo išdėsto lygius pagal priežastinius ryšius arba argumentavimo logiką. Tai atspindi „logikos pirmenybę prieš pradinę įvesties seką“ sprendimą. Šis „pirmiausia struktūra, tada išvestis“ modelis yra sistemų inžinerijos mąstymo pagrindas.

Šie du atvejai, vienas yra realaus laiko vizualinė sąveikos sistema, o kitas – žiniasklaidos informacijos struktūros apdorojimo sistema, atrodo visiškai skirtingi. Tačiau jie patvirtina tą patį dalyką – GLM-5 turi visas užduoties užbaigimo galimybes: planavimas → vykdymas → derinimas → optimizavimas.

Fejerverkų žaidime tai atsispindi modulio sluoksniavime, našumo optimizavime ir išimčių tvarkyme; įrašų procesoriuje tai atsispindi temos nustatyme, struktūros išskaidyme ir logikos pertvarkyme. Jų bendras bruožas yra tas, kad modelis nesustoja ties „rezultatų generavimu“, o palaiko tvariai besivystančią struktūrą.

Toliau bandžiau palyginti sudėtingą užduotį – „sukurti minimalią operacinės sistemos branduolį“. Šiame realaus pasaulio bandyme iš tikrųjų verta atkreipti dėmesį ne į tai, kad vaizdo įraše kodas galiausiai paleidžiamas, o į GLM-5 elgesį viso proceso metu.

Gavęs užduotį, jis iš karto neįėjo į generavimo būseną, o pirmiausia išsiaiškino užduoties ribas, aktyviai išskaidė modulius, suplanavo sistemos struktūrą ir tada įėjo į įgyvendinimo etapą. Šis „struktūra pirmiausia“ kelias iš esmės yra anksčiau minėtas inžinerinis mąstymas – pirmiausia apibrėžti, kaip sistema sudaryta, tada aptarti konkrečias įgyvendinimo detales, o ne rašyti ir dėlioti.

Kelių rašymo, vykdymo, klaidų ir taisymo cikle GLM-5 taip pat neparodė struktūros žlugimo. Kiekvienas pakeitimas buvo atliktas aplink nustatytą architektūrą, o ne apverčiant ir pradedant iš naujo arba lokaliai pataisant. Tai rodo, kad jis viduje palaiko pilną sistemos modelį, kuris gali išlaikyti nuoseklumą ilgos grandinės užduotyse. Daugelis modelių, kai kontekstas pailgėja, lengvai prieštarauja vienas kitam, o vaizdo įraše rodomas veikimas atspindi jo nuolatinę atmintį apie bendrą struktūrą.

Taip pat yra jo klaidų tvarkymo būdas. Kai atsiranda klaida, jis nesustoja ties paviršutinišku spėjimu „galbūt tai yra eilutės kodo problema“, o pirmiausia nustato klaidos tipą, atskiria logikos problemas, aplinkos problemas ar priklausomybių konfliktus ir tada suplanuoja trikčių šalinimo kelią. Tai yra strategijos lygmens derinimas, skirtas pataisyti problemos kelią.

Jei tai derinama su įrankių iškvietimu, ši galimybė bus dar akivaizdesnė. Jis ne tik pateikia komandų pasiūlymus, bet ir derina aktyvų terminalo planavimą, žurnalų analizę, aplinkos taisymą ir toliau vykdo užduotį. Šis elgesys jau šiek tiek artimas „autopilotavimo“ inžinerijos pažangai. Jei tikslas nepasiektas, jis nuolat kartojasi.

Pirmiausia planuoti, tada vykdyti, išlaikyti struktūrą stabilią ilgoje grandinėje, strategiškai šalinti problemas ir nuolat siekti tikslo – būtent šių keturių pagrindinių galimybių, reikalingų sistemų inžinerijai, persidengimas leidžia GLM-5 pradėti rodyti elgesio modelį, artimą inžinieriaus darbo būdui.

Kodėl GLM-5 gali perimti „architekto“ estafetę?

Jei pirmoji dalis realaus pasaulio bandymų įrodo, kad GLM-5 „gali atlikti sudėtingą darbą“, tada kitas klausimas yra: kodėl jis gali? Atsakymas slypi visame „inžinerinio lygio elgesio modelyje“, paslėptame už išvesties.

Svarbiausias dalykas yra tai, kad GLM-5 akivaizdžiai įdiegė panašų į „Claude Opus 4.6“ mąstymo grandinės savikontrolės mechanizmą.

Praktiškai naudojant galima pajusti, kad jis ne iš karto pradeda „pildyti kodą“, gavęs užduotį, o fone atlieka kelis loginius išvedimus: numato modulių tarpusavio ryšius, aktyviai vengia aklaviečių ciklų kelių, iš anksto aptinka išteklių konfliktus ir ribines sąlygas. Tiesioginis šio elgesio pokytis yra tas, kad siekiant užtikrinti, jog sprendimas inžineriniu požiūriu yra pagrįstas, jis nori sulėtinti tempą ir išsamiai apgalvoti problemą.

Sudėtingose užduotyse GLM-5 pirmiausia pateiks aiškų modulio išskaidymą: iš kokių submodulių susideda sistema, kokia yra kiekvieno modulio įvestis ir išvestis, kurios dalys gali būti vykdomos lygiagrečiai, kurios turi būti atliekamos nuosekliai. Tada jis vieną po kito įveiks problemas, o ne rašys ir galvos. Tai daro jo darbo būdą panašesnį į tikro inžinieriaus: pirmiausia nupiešti architektūros diagramą, tada parašyti įgyvendinimo detales. Akivaizdžiai jaučiama, kad jis turi „atkaklumo, kad nesustotų, kol problema nebus išspręsta švariai“, o ne skubotai baigti, atlikus atrodytų teisingą vietą.

Šis skirtumas ypač akivaizdus lyginant su tradiciniais programavimo modeliais. Anksčiau daugelis modelių, susidūrę su klaidomis, greitai įslysdavo į pažįstamą modelį: atsiprašyti, pakartoti klaidos informaciją, pateikti nepatvirtintą taisymo pasiūlymą; jei vėl nepavyksta, pradėti cikliškai pateikti panašius atsakymus. GLM-5 tvarkymo būdas yra artimesnis senam architektui. Realaus pasaulio bandyme, kai projektas negalėjo būti paleistas dėl aplinkos priklausomybės problemų, jis nesustojo ties paviršutiniška klaidos informacija, o aktyviai analizavo priklausomybių medį (Dependency Tree), nustatė konflikto šaltinį ir toliau nurodė „OpenClaw“ atlikti aplinkos taisymą.

Visas procesas labiau panašus į „autopilotavimo“ diegimą: modelis nereaguoja pasyviai, o nuolat skaito žurnalus, taiso kelius ir tikrina rezultatus.

Kita dažnai ignoruojama, bet labai svarbi sistemų inžinerijoje galimybė yra konteksto vientisumas.

GLM-5 milijono lygio „Token“ langas leidžia jam suprasti viso projekto kodo struktūrą, istorijos pakeitimus, konfigūracijos failus ir vykdymo žurnalus tame pačiame kontekste. Tai reiškia, kad jis jau gali spręsti, kokias grandinines reakcijas sukels pakeitimas moduliams iš visuotinės perspektyvos. Ilgos grandinės užduotyse ši galimybė tiesiogiai lemia, ar modelis yra „protingas, bet trumparegis“, ar „stabilus ir valdomas“.

Apibendrinant, GLM-5 iš tikrųjų perima „architekto“ vaidmenį, daugiausia todėl, kad pradeda mąstyti apie problemas kaip architektas: pirmiausia planuoti, tada vykdyti; nuolat tikrinti, nuolat taisyti; atkreipti dėmesį į visą sistemą, o ne į vieną tašką.

Tai taip pat yra pagrindinė priežastis, kodėl jis gali atlikti tas sistemos lygmens realaus pasaulio bandymų užduotis pirmoje dalyje.

03

**Atvirojo kodo „Opus“? **

Žvelgiant į 2026 m. didelių modelių ekosistemą, GLM-5 vertė labiau slypi tame, kad jis sulaužė tai, kas anksčiau buvo beveik numatyta: sistemos lygmens intelektas, atrodo, gali egzistuoti tik uždaro kodo modeliuose.

Anksčiau „Claude Opus 4.6“ ir „GPT-5.3“ iš tikrųjų įveikė „Agentic Coding“ kelią – modelis nebesiekia tiesioginio grįžtamojo ryšio, o planuodamas, išskaidydamas, pakartotinai vykdydamas, atlieka tikrai sudėtingas inžinerines užduotis. Tačiau kaina taip pat didelė: didelio intensyvumo užduočių „Token“ sąnaudos yra labai didelės, o visas sistemos lygmens bandymas dažnai reiškia dideles iškvietimo išlaidas.

GLM-5 čia pateikia skirtingą sprendimą. Kaip atvirojo kodo modelis, jis „sistemos architekto lygio AI“ iš debesies ir sąskaitų grąžino į kūrėjų aplinką. Galite jį įdiegti vietoje, kad jis skirtų laiko kramtyti tuos nešvarius, sunkius ir didelius darbus: derinti žurnalus, tikrinti priklausomybes, keisti seną kodą, papildyti ribines sąlygas.

Tai galima laikyti struktūriniu sąnaudų efektyvumo pokyčiu – architekto lygio intelektas nebėra mažos komandos privilegija.

Jei šį skirtumą suprasite profesine metafora, jis bus dar intuityvesnis. Tokie modeliai kaip „Kimi 2.5“ labiau panašūs į puikius priekinės dalies inžinierius, turinčius estetinį pojūtį ir stiprų sąveikos jausmą, kurie gerai generuoja vienu šūviu, pateikia vaizdą ir greitai pateikia grįžtamąjį ryšį; o GLM-5 stilius akivaizdžiai skiriasi, jis labiau panašus į patyrusį sistemos architektą, kuris laikosi pagrindinių principų ir pabrėžia logiką: atkreipia dėmesį į modulių ryšius, išimčių kelius, prižiūrimumą ir ilgalaikį stabilų veikimą.

Už to iš tikrųjų slypi aiškus programavimo AI profesinis tobulėjimas – nuo siekio „atrodyti labai gerai“ „Vibe Coding“ iki pabrėžimo patikimumo ir inžinerinės drausmės inžinerijoje.

Dar svarbiau, kad GLM-5 atsiradimas leidžia vieno žmogaus įmonės koncepciją įgyvendinti labiau. Kai kūrėjas gali turėti vietinį AI partnerį, kuris supranta sistemų dizainą, gali veikti ilgą laiką ir gali pats save taisyti, daugelis inžinerinių darbų, kuriems anksčiau reikėjo komandos, pradedami suspausti į asmens kontroliuojamą sritį. Ateityje GLM-5 turi potencialo tapti „skaitmeniniu partneriu“, atsakingu už pagrindinį inžinerinį įgyvendinimą vieno žmogaus įmonėje.