Atvērtā koda pasaules Opus brīdis: vai GLM-5 spēs pārņemt Agentic Coding stafeti?

Ja jūs jautātu izstrādātājam, kas ir visvairāk nomācošais brīdis AI programmēšanā?

Viņš, visticamāk, atbildētu ar mehānisku "Atvainojiet, es nepareizi sapratu" kļūdas priekšā, un pēc tam atkārtotu to pašu kļūdaino kodu.

Iepriekšējā gadā Coding lielo modeļu progress vairāk atspoguļojās "ģenerēšanas spējā": viena teikuma ģenerēta tīmekļa lapa, komponenti, mazas spēles - 15 sekunžu laikā izveidojot pikseļu stila tīmekļa lapu, foršu SVG ikonu vai darbojošu čūsku. Šie Demo ir pietiekami pārsteidzoši, bet arī pietiekami "viegls", tie ir nedaudz līdzīgi augstākās klases rotaļlietām, kas radušās Vibe Coding (atmosfēras programmēšanas) laikmetā. Bet, kad runa ir par augstas vienlaicīguma arhitektūru, zemāka līmeņa draiveru pielāgošanu vai sarežģītu sistēmas pārstrukturēšanu, tie kļūst par "siltumnīcas ziediem".

Tāpēc Silīcija ielejas vējš pēdējā laikā ir mainījies.

Neatkarīgi no tā, vai tas ir Claude Opus 4.6 vai GPT-5.3, šie labākie lielie modeļi sāk uzsvērt Agentic Coding: nemeklējiet "sekundes rezultātus", bet gan pabeidziet sistēmas līmeņa uzdevumus, plānojot, sadalot un atkārtoti palaižot.

Šī paradigmas maiņa no "front-end estētikas" uz "sistēmu inženieriju" agrāk tika uzskatīta par slēgta koda gigantu monopolzonu. Tikai pēc GLM-5 testēšanas es sapratu, ka atvērtā koda kopienas "arhitektu laikmets" ir sācies agrāk.

01

No "front-end" uz "sistēmu inženieriju"

Iepriekš, runājot par AI Coding, lielākā daļa domāja par pazīstamu stāstījumu - viena teikuma ģenerēta tīmekļa lapa, maza spēle minūtes laikā, foršs kustību efekts desmit sekundēs. Tie uzsver "vizuālo patīkamību": pogas kustas, lapa ir skaista, efekti ir bagātīgi.

Bet tie, kas patiešām iekļūst inženierijas vietā, zina, ka Demo ģenerēšana nenozīmē, ka var atbalstīt sistēmu.

Sarežģītu uzdevumu grūtības nav "koda rakstīšanā", bet gan tajā, kā moduļi tiek sadalīti, kā tiek pārvaldīti stāvokļi, kā tiek nodrošināta izņēmumu apstrāde, kā tiek optimizēta veiktspēja un vai sistēma joprojām var uzturēt struktūras stabilitāti, kad tā kļūst sarežģītāka.

Tas ir arī iemesls, kāpēc mēs izvēlējāmies sarežģītus uzdevumus kā reālus testēšanas objektus.

GLM-5 pozicionēšana atšķiras no daudziem konkurentiem.

Ja lielākā daļa modeļu ir vairāk kā "izcils front-end" - prasmīgi ātri ģenerēt interaktīvas saskarnes un vizuālos efektus, tad GLM-5 ir vairāk vērsts uz "sistēmu inženierijas lomu". Tas uzsver vairāku moduļu sadarbību, garas ķēdes uzdevumus un strukturālo stabilitāti, kas darbojas ražošanas vidē.

Lai to pārbaudītu, mēs izstrādājām divus pilnīgi atšķirīgu dimensiju reālus testēšanas gadījumus.

Pirmais tests ir šķietami viegls, bet ļoti sistemātisks uzdevums - balstoties uz pārlūkprogrammu un kameru, realizēt "AI vizuāli kontrolētu uguņošanu" pavasara festivāla tēmas interaktīvu spēli.

Reālajā testēšanas video var redzēt, ka lietotājs stāv kameras priekšā un ar žestiem kontrolē uguņošanas virzienu un ritmu; uguņošana zied gaisā, ko pavada daļiņu efekti un dinamiskas gaismas efektu atsauksmes, un kopējā mijiedarbība ir vienmērīga un dabiska.

Bet tas nav vienkāršs front-end kustību efektu projekts. Tajā ir vismaz šādi galvenie moduļi: žestu atpazīšana un vizuālās ievades apstrāde; žestu koordinātu kartēšana uz palaišanas loģiku; uguņošanas daļiņu sistēma un ziedēšanas efekti; reāllaika renderēšana un kadru ātruma kontrole; pārlūkprogrammas saderība un kameras atļauju izņēmumu apstrāde; mijiedarbības stāvokļa pārvaldība un lietotāju atsauksmes

Var teikt, ka tā ir maza interaktīva sistēma ar pilnīgu struktūru un vienmērīgu pieredzi. No reālā testēšanas procesa GLM-5 neiekļuva tieši kodēšanā, bet vispirms plānoja kopējo arhitektūru: kā atdalīt vizuālās ievades moduli, vadības loģikas slāni, renderēšanas slāni un efektu slāni; kā tiek pārsūtīta datu plūsma; kuras daļas var kļūt par veiktspējas vājām vietām.

Pēc tam tas pakāpeniski realizēja loģiku, sākot ar žestu atpazīšanas datu apstrādi, līdz palaišanas trajektorijas aprēķināšanai un pēc tam daļiņu sprādziena efekta parametru optimizācijai.

Kad renderēšana iestrēgst, tas aktīvi iesaka samazināt daļiņu skaitu un optimizēt cikla struktūru; kad žestu atpazīšana ir nepareiza, tas pielāgo sliekšņus un filtrēšanas stratēģijas.

Video redzamais efekts ir "šķietami dabiska mijiedarbība". Bet aiz tā atspoguļojas pilnīga inženierijas ķēde: plānošana → rakstīšana → atkļūdošana → veiktspējas optimizācija → mijiedarbības korekcija.

Beigās ģenerēto kodu var palaist tieši, mijiedarbība ir stabila, kadru ātrums ir vienmērīgs un var apstrādāt izņēmuma gadījumus. Vēl svarīgāk ir tas, ka tā darba veids parāda skaidru sistēmas domāšanu: moduļu robežas ir skaidras, loģiskā slāņošana ir saprātīga, nevis visas funkcijas ir sakrautas vienā failā.

Otrais gadījums pārbauda strukturālās sistēmas spējas. Šo scenāriju var teikt par mediju darba ikdienu - importēt intervijas stenogrammu, apkopot saturu, izvadīt tēmu leņķus un idejas.

Reālajā testā var redzēt, ka darbības process ir ļoti tiešs: es ielīmēju intervijas stenogrammas saturu no iepriekšējā laika posma, modelis sāka analizēt un pēc tam izvadīja satura kopsavilkumu un tēmu leņķus. No rezultātiem var redzēt, ka tā ģenerētie tēmu leņķi joprojām ir ļoti praktiski.

Salīdzinot ar vizuālās mijiedarbības sistēmu, ierakstu sakārtošana šķiet vienkārša, bet patiesībā tā pārbauda modeļa "struktūras abstrakcijas spēju". Īsts intervijas ieraksts bieži vien ir ļoti nestrukturēts: viedokļu lēcieni, informācijas atkārtošanās, galvenās un papildu līnijas ir savstarpēji saistītas. Tāpēc šajā gadījumā GLM-5 parādītā spēja ir sistēmas līmenī.

Pirmkārt, tēmas atpazīšana un galvenās līnijas ieguves spēja. Modelis neģenerēja kopsavilkumu pēc sākotnējā teksta secības, bet vispirms noteica, kāds ir galvenais jautājums, un pēc tam reorganizēja saturu ap šo jautājumu. Tas nozīmē, ka tas iekšēji pabeidza skenēšanu, lai noteiktu, kura informācija pieder galvenajai līnijai un kura pieder papildinājumam vai troksnim. Šī spēja būtībā ir plānošanas spēja, tas ir, pirms izvades izveidot abstraktu struktūras ietvaru.

Otrkārt, modularizācijas pārstrukturēšanas spēja. Tas klasificēs saistītos viedokļus, kas izkaisīti dažādās rindkopās, vienā modulī. Šī spēja integrēt dažādas rindkopas norāda, ka modelim ir globāla konsekvence, apstrādājot garus tekstus.

Treškārt, loģiskās secības aktīva pielāgošanas spēja. Faktiskā izvades skice bieži atšķiras no sākotnējā ieraksta secības. Var redzēt, ka GLM-5 pārkārto līmeņus atbilstoši cēloņsakarībām vai argumentācijas loģikai. Tas atspoguļo spriedumu, ka "loģikai ir prioritāte pār sākotnējo ievades secību". Šis "vispirms struktūra, pēc tam izvade" modelis ir sistēmu inženierijas domāšanas pamatā.

Šie divi gadījumi, viens ir reāllaika vizuālās mijiedarbības sistēma, bet otrs ir mediju informācijas struktūras apstrādes sistēma, šķiet pilnīgi atšķirīgi. Bet tie pārbauda vienu un to pašu lietu - GLM-5 ir pilnīga uzdevumu slēgta cikla spēja: plānošana → izpilde → atkļūdošana → optimizācija.

Uguņošanas spēlē tas atspoguļojas moduļu slāņošanā, veiktspējas optimizācijā un izņēmumu apstrādē; ierakstu procesorā tas atspoguļojas tēmas spriedumā, struktūras sadalīšanā un loģiskajā pārstrukturēšanā. To kopīgais punkts ir tas, ka modelis neapstājas pie "rezultātu ģenerēšanas", bet gan uztur ilgtspējīgu attīstības struktūru.

Es turpināju mēģināt salīdzinoši sarežģītu uzdevumu, "izveidot minimālu operētājsistēmas kodolu". Šajā reālajā testā patiešām ir vērts pievērst uzmanību nevis tam, ka video kods beidzot darbojas, bet gan GLM-5 uzvedībai visā procesā.

Tas nevis uzreiz iekļuva ģenerēšanas stāvoklī pēc uzdevuma saņemšanas, bet vispirms noskaidroja uzdevuma robežas, aktīvi sadalīja moduļus, plānoja sistēmas struktūru un pēc tam iekļuva realizācijas posmā. Šis "struktūras prioritātes" ceļš būtībā ir iepriekš minētā inženierijas domāšana - vispirms definēt, kā sistēma ir veidota, un pēc tam apspriest konkrētas ieviešanas detaļas, nevis rakstīt un salikt.

Vairāku rakstīšanas, palaišanas, kļūdu un labošanas ciklos GLM-5 neparādījās arī struktūras sabrukums. Katrs labojums tika veikts ap noteikto arhitektūru, nevis apgāzts vai daļēji ielāpīts. Tas norāda, ka tas iekšēji uztur pilnīgu sistēmas modeli un var saglabāt konsekvenci garos ķēdes uzdevumos. Daudzi modeļi ir pakļauti pretrunām pēc konteksta pagarināšanas, un video redzamais sniegums atspoguļo tā nepārtraukto atmiņas spēju par kopējo struktūru.

Ir arī veids, kā tas apstrādā kļūdas. Kad parādās kļūda, tas neapstājas pie virspusējiem minējumiem, ka "varētu būt problēma ar kādu koda rindu", bet vispirms nosaka kļūdas veidu, atšķir loģikas problēmas, vides problēmas vai atkarību konfliktus un pēc tam plāno izmeklēšanas ceļu. Šī ir stratēģijas līmeņa atkļūdošana, kuras mērķis ir novērst problēmas ceļu.

Ja to apvieno ar rīku izsaukšanu, šī spēja būs vēl acīmredzamāka. Tas ne tikai sniedz komandu ieteikumus, bet arī apvieno aktīvu termināļa plānošanu, žurnālu analīzi, vides labošanu un turpina virzīt uzdevumu. Šī uzvedība jau ir nedaudz tuvu "autopilota" tipa inženierijas virzībai. Mērķis nav pabeigts, tas turpina atkārtot.

Vispirms plānot un pēc tam izpildīt, uzturēt struktūras stabilitāti garā ķēdē, stratēģiski pārbaudīt problēmas un turpināt virzīties uz mērķi - tieši četru galveno spēju pārklāšanās, kas nepieciešamas sistēmu inženierijai, ļauj GLM-5 sākt parādīt uzvedības modeli, kas ir tuvs inženiera darba veidam.

Kāpēc GLM-5 var pārņemt "arhitekta" stafeti?

Ja pirmā daļa pierāda, ka GLM-5 "var veikt sarežģītu darbu", tad nākamais jautājums ir: kā tas var? Atbilde slēpjas visā "inženierijas līmeņa uzvedības modeļu" komplektā, kas ir paslēpts aiz izvades.

Galvenais punkts ir tas, ka GLM-5 acīmredzami ir ieviesis tādu pašu domāšanas ķēdes pašpārbaudes mehānismu kā Claude Opus 4.6.

Praktiskā lietošanā var sajust, ka tas nevis uzreiz sāk "aizpildīt kodu" pēc uzdevuma saņemšanas, bet gan veic vairākas loģiskas dedukcijas aizkulisēs: iepriekš paredz moduļu savstarpējo saistību, aktīvi izvairās no bezgalīgu ciklu ceļiem, iepriekš atklāj resursu konfliktus un robežnosacījumu problēmas. Tiešās izmaiņas, ko rada šī uzvedība, ir - lai nodrošinātu, ka risinājums ir inženiertehniski pamatots, tas ir gatavs palēnināt tempu un pilnībā pārdomāt problēmu.

Sarežģītos uzdevumos GLM-5 vispirms sniegs skaidru moduļu sadalījumu: no kādiem apakšmoduļiem sastāv sistēma, kāda ir katra moduļa ievade un izvade, kuras daļas var virzīt paralēli un kuras jāpabeidz secīgi. Pēc tam tos atrisināt pa vienam, nevis rakstīt un domāt. Tas padara tā darba veidu līdzīgāku īstam inženierim: vispirms uzzīmēt arhitektūras diagrammu un pēc tam rakstīt ieviešanas detaļas. Acīmredzami var sajust, ka tam ir "izturība neapstāties, kamēr problēma nav pilnībā atrisināta", nevis steigties pabeigt šķietami pareizu daļu.

Šī atšķirība ir īpaši acīmredzama salīdzinājumā ar tradicionālajiem Coding modeļiem. Iepriekš daudzi modeļi, saskaroties ar kļūdām, ātri iegrimst pazīstamā režīmā: atvainojas, atkārto kļūdas informāciju, sniedz nepārbaudītu labošanas ieteikumu; ja atkal neizdodas, tas sāk atkārtoti izvadīt aptuvenas atbildes. GLM-5 apstrādes metode ir tuvāka vecāka gadagājuma arhitektam. Reālajā testā, kad projekts nevarēja darboties vides atkarības problēmu dēļ, tas neapstājās pie virspusējas kļūdas informācijas, bet aktīvi analizēja atkarību koku (Dependency Tree), noteica konflikta avotu un turpināja vadīt OpenClaw, lai labotu vidi.

Visā procesā tas vairāk līdzinās "autopilota" tipa izvietošanai: modelis nereaģē pasīvi, bet gan nepārtraukti lasa žurnālus, labo ceļus un pārbauda rezultātus.

Cita spēja, kas bieži tiek ignorēta, bet ir ārkārtīgi svarīga sistēmu inženierijā, ir konteksta pilnīgums.

GLM-5 miljona līmeņa Token logs ļauj tam vienā kontekstā saprast visa projekta koda struktūru, vēsturiskās izmaiņas, konfigurācijas failus un darbības žurnālus. Tas nozīmē, ka tas jau var spriest no globāla viedokļa, kādas ķēdes reakcijas radīs viena izmaiņa dažādiem moduļiem. Garos ķēdes uzdevumos šī spēja tieši nosaka, vai modelis ir "gudrs, bet tuvredzīgs" vai "stabils un kontrolējams".

Kopumā GLM-5 patiešām pārņem "arhitekta" lomu, galvenokārt tāpēc, ka sāk domāt par problēmām kā arhitekts: vispirms plānot un pēc tam izpildīt; nepārtraukti pārbaudīt un nepārtraukti labot; koncentrēties uz visu sistēmu, nevis uz viena punkta panākumiem.

Tas ir arī galvenais iemesls, kāpēc tas var pabeigt sistēmas līmeņa reālos testēšanas uzdevumus pirmajā daļā.

03

Atvērtā koda pasaules Opus?

Skatoties uz GLM-5 vērtību 2026. gada lielo modeļu ekosistēmā, tā vairāk slēpjas tajā, ka tas pārkāpj lietu, kas iepriekš tika gandrīz pieņemta pēc noklusējuma: sistēmas līmeņa inteliģence, šķiet, var pastāvēt tikai slēgta koda modeļos.

Iepriekš Claude Opus 4.6 un GPT-5.3 patiešām ir izgājuši "Agentic Coding" ceļu - modelis vairs necenšas iegūt tūlītēju atgriezenisko saiti, bet gan pabeidz patiesi sarežģītus inženierijas uzdevumus, plānojot, sadalot un atkārtoti palaižot. Bet cena ir arī ļoti augsta: augstas intensitātes uzdevumu Token patēriņš ir ārkārtīgi augsts, un viens pilnīgs sistēmas līmeņa mēģinājums bieži vien nozīmē ievērojamas izmaksas.

GLM-5 šeit piedāvā atšķirīgu risinājumu. Kā atvērtā koda modelis tas atgriež "sistēmas arhitekta līmeņa AI" no mākoņa un rēķiniem atpakaļ izstrādātāju vidē. Jūs varat to izvietot lokāli, ļaujot tam pavadīt laiku, lai atrisinātu tos netīros, nogurdinošos un lielos darbus: pielāgot žurnālus, pārbaudīt atkarības, mainīt veco kodu un papildināt robežnosacījumus.

To var uzskatīt par strukturālu izmaiņu ar izmaksu efektivitāti - arhitekta līmeņa inteliģence vairs nav dažu komandu privilēģija.

Ja šo atšķirību saprot ar profesionālu metaforu, tā būs vēl intuitīvāka. Tādi modeļi kā Kimi 2.5 vairāk līdzinās izciliem front-end inženieriem ar tiešsaistes estētiku un ārkārtīgi spēcīgu mijiedarbības sajūtu, kas ir prasmīgi One-shot ģenerēšanā, vizuālajā prezentācijā un ātrā atgriezeniskajā saitē; bet GLM-5 stils ir acīmredzami atšķirīgs, tas vairāk līdzinās pieredzējušam sistēmu arhitektam, kas ievēro pamatprincipus un uzsver loģiku: koncentrējas uz moduļu attiecībām, izņēmumu ceļiem, uzturējamību un ilgtermiņa stabilu darbību.

Aiz tā patiesībā ir skaidrs programmēšanas AI profesionālais progress - no tieksmes pēc "šķietami ļoti patīkama" Vibe Coding līdz uzsvaram uz robustumu un inženierijas disciplīnu Engineering.

Vēl svarīgāk ir tas, ka GLM-5 parādīšanās padara viena cilvēka uzņēmuma koncepciju vēl reālāku.Kad izstrādātājam lokāli ir AI partneris, kurš saprot sistēmu dizainu, var darboties ilgtermiņā un var sevi labot, daudzi inženiertehniskie darbi, kuriem sākotnēji bija nepieciešama komanda, sāk tikt saspiesti līdz indivīda kontrolējamam apjomam. Nākotnē GLM-5 varētu kļūt par "digitālo partneri", kas atbild par galveno inženiertehnisko ieviešanu vienas personas uzņēmumā.