Ang Opus Moment ng Open Source World: Kaya bang Sagutin ng GLM-5 ang Relay Baton ng Agentic Coding?

Kung tatanungin mo ang isang developer, ano ang pinakanakakabaliw na sandali sa AI programming?

Ang sagot niya sa iyo ay malamang na ang mekanikal na "Paumanhin, nagkamali ako ng pagkakaintindi" sa harap ng isang error, at pagkatapos ay ulitin ang parehong maling code.

Sa nakalipas na taon, ang pag-unlad ng Coding Large Model ay mas nakikita sa "generation ability": isang pangungusap upang bumuo ng mga webpage, component, maliliit na laro - gumawa ng isang pixel-style na webpage, isang cool na SVG icon, o isang tumatakbong Snake sa loob ng 15 segundo. Ang mga Demo na ito ay sapat na nakamamangha, ngunit sapat din na "magaan", medyo katulad sila ng mga advanced na laruan na ginawa sa panahon ng Vibe Coding. Ngunit pagdating sa high-concurrency architecture, bottom-level driver adaptation, o kumplikadong system restructuring, sila ay naging "mga bulaklak sa greenhouse".

Kaya kamakailan, nagbago na ang direksyon sa Silicon Valley.

Kung Claude Opus 4.6 man o GPT-5.3, ang mga nangungunang malalaking modelo na ito ay nagsimulang bigyang-diin ang Agentic Coding: hindi naghahangad ng "mabilis na resulta", ngunit sa pamamagitan ng pagpaplano, paghiwa-hiwalay, at paulit-ulit na pagpapatakbo, upang kumpletuhin ang mga gawain sa antas ng system.

Ang paglipat ng paradigm na ito mula sa "front-end aesthetics" patungo sa "system engineering" ay dating itinuturing na monopolyo ng mga saradong higante. Hanggang sa sinubukan ko ang GLM-5, napagtanto ko na ang "arkitekto era" ng open source community ay nagsimula nang mas maaga.

01

Mula sa "Front-end" hanggang sa "System Engineering"

Dati, kapag pinag-uusapan ang AI Coding, madalas na naiisip ng isa ang isang pamilyar na salaysay - isang pangungusap upang bumuo ng isang webpage, isang minuto upang gumawa ng isang maliit na laro, sampung segundo upang bumuo ng isang cool na dynamic effect. Binibigyang-diin nila ang "visual na kasiyahan": gumagalaw ang mga button, maganda ang mga pahina, at mayaman ang mga special effect.

Ngunit alam ng mga taong talagang pumapasok sa engineering site na ang paggawa ng isang Demo ay hindi nangangahulugan na kayang suportahan ang isang system.

Ang kahirapan ng mga kumplikadong gawain ay hindi sa "pagsulat ng code", ngunit sa kung paano hatiin ang mga module, kung paano pamahalaan ang mga estado, kung paano i-back up ang mga exception, kung paano i-optimize ang pagganap, at kung kaya pa ring mapanatili ang katatagan ng istruktura kapag nagsimulang maging kumplikado ang system.

Ito rin ang dahilan kung bakit pumili kami ng mga kumplikadong gawain bilang mga aktwal na bagay sa pagsubok.

Ang pagpoposisyon ng GLM-5 ay iba sa maraming katunggali.

Kung ang karamihan sa mga modelo ay mas katulad ng "mahusay na front-end" - mahusay sa mabilis na pagbuo ng mga interactive na interface at visual effect, kung gayon ang GLM-5 ay mas nakatuon sa "system engineering role". Binibigyang-diin nito ang multi-module collaboration, long-link na mga gawain, at ang katatagan ng istruktura na maaaring patakbuhin sa isang production environment.

Upang patunayan ito, nagdisenyo kami ng dalawang ganap na magkaibang dimensyon ng mga aktwal na kaso ng pagsubok.

Ang unang pagsubok ay isang tila madali, ngunit talagang mataas na sistematikong gawain - batay sa browser at camera, upang mapagtanto ang isang "AI visual air control fireworks" na interactive na laro na may temang Spring Festival.

Sa aktwal na video ng pagsubok, makikita na ang gumagamit ay nakatayo sa harap ng camera at kinokontrol ang direksyon at ritmo ng pagpapaputok ng mga paputok sa pamamagitan ng mga galaw; ang mga paputok ay namumulaklak sa hangin, sinamahan ng mga particle effect at dynamic na light effect feedback, at ang pangkalahatang interaksyon ay makinis at natural.

Ngunit hindi ito isang simpleng proyekto ng front-end dynamic effect. Naglalaman ito ng hindi bababa sa ilang pangunahing module: pagkilala sa galaw at pagproseso ng visual input; pagmamapa ng mga coordinate ng galaw sa logic ng pagpapaputok; particle system ng paputok at mga parameter ng pag-optimize ng blooming effect; real-time rendering at frame rate control; browser compatibility at camera permission exception handling; pamamahala ng interactive na estado at mekanismo ng feedback ng gumagamit.

Maaaring sabihin na ito ay isang maliit na interactive na sistema na may kumpletong istraktura at makinis na karanasan. Mula sa aktwal na proseso ng pagsubok, ang GLM-5 ay hindi direktang pumasok sa pag-encode, ngunit unang nagplano ng pangkalahatang arkitektura: kung paano paghiwalayin ang visual input module, control logic layer, rendering layer, at special effect layer; kung paano ipapasa ang data flow; at kung aling mga bahagi ang maaaring maging bottleneck ng pagganap.

Pagkatapos, unti-unti nitong ipinatupad ang logic, simula sa pagproseso ng data ng pagkilala sa galaw, hanggang sa pagkalkula ng trajectory ng pagpapaputok, at pagkatapos ay sa pag-tune ng parameter ng particle explosion effect.

Kapag may pagkaantala sa rendering, aktibo itong nagmumungkahi na bawasan ang bilang ng mga particle at i-optimize ang istraktura ng loop; kapag may maling paghuhusga sa pagkilala sa galaw, inaayos nito ang threshold at filtering strategy.

Ang epekto na ipinakita sa video ay isang "mukhang natural na interaksyon". Ngunit ang ipinapakita sa likod nito ay isang kumpletong engineering chain: pagpaplano → pagsulat → pag-debug → pag-optimize ng pagganap → pagwawasto ng interaksyon.

Ang huling nabuong code ay maaaring direktang patakbuhin, ang interaksyon ay matatag, ang frame rate ay makinis, at ang mga abnormal na sitwasyon ay maaaring pangasiwaan. Higit sa mahalaga, ang paraan ng pagtatrabaho nito ay nagpapakita ng isang malinaw na pag-iisip ng sistema: malinaw ang mga hangganan ng module, makatwiran ang paglalagay ng logic, sa halip na isalansan ang lahat ng mga function sa isang file.

Ang pangalawang kaso na sinubukan ay ang kakayahan ng istruktura ng sistema. Ang senaryong ito ay maaaring sabihin na ang pang-araw-araw na gawain ng media work - mag-import ng isang transcript ng panayam, ibuod ang nilalaman, at mag-output ng mga anggulo at ideya ng paksa.

Makikita sa aktwal na pagsubok na ang proseso ng pagpapatakbo ay napakadirekta: idinikit ko ang isang transcript ng panayam mula sa nakaraang panahon, nagsimulang mag-analisa ang modelo, at pagkatapos ay nag-output ng buod ng nilalaman at mga anggulo ng paksa. Mula sa mga resulta, ang mga anggulo ng paksa na nabuo nito ay napaka-operable pa rin.

Kung ikukumpara sa visual interactive system, ang pag-aayos ng recording ay tila simple, ngunit talagang sinusubok nito ang "kakayahan sa pag-abstract ng istruktura" ng modelo. Ang isang tunay na recording ng panayam ay madalas na lubos na hindi nakabalangkas: pagtalon ng mga pananaw, pag-uulit ng impormasyon, at paghabi ng pangunahing linya at mga sangay na linya. Kaya sa kasong ito, ang kakayahan na ipinakita ng GLM-5 ay nasa antas ng sistema.

Una, ang pagkilala sa tema at kakayahan sa pagkuha ng pangunahing linya. Ang modelo ay hindi bumuo ng isang buod ayon sa orihinal na pagkakasunud-sunod ng teksto, ngunit unang hinuhusgahan kung ano ang pangunahing isyu, at pagkatapos ay muling inorganisa ang nilalaman sa paligid ng isyung ito. Nangangahulugan ito na nakumpleto nito ang isang pag-scan sa loob, na kinikilala kung aling impormasyon ang kabilang sa pangunahing linya at kung alin ang pandagdag o ingay. Ang kakayahang ito ay mahalagang kakayahan sa pagpaplano, iyon ay, ang pagtatatag ng isang abstract na balangkas ng istraktura bago ang output.

Pangalawa, ang kakayahan sa modular na muling pagsasama. Ikakategorya nito ang mga kaugnay na pananaw na nakakalat sa iba't ibang talata sa parehong module. Ang kakayahang ito sa cross-segment integration ay nagpapahiwatig na ang modelo ay may pangkalahatang pagkakapare-pareho kapag nagpoproseso ng mahabang teksto.

Pangatlo, ang kakayahan sa aktibong pagsasaayos ng lohikal na pagkakasunud-sunod. Ang aktwal na output na balangkas ay madalas na naiiba sa orihinal na pagkakasunud-sunod ng pag-record. Makikita na ang GLM-5 ay muling inaayos ang mga antas ayon sa mga relasyon ng sanhi at epekto o lohika ng argumento. Ito ay nagpapakita ng isang paghuhusga na "ang lohika ay mas inuuna kaysa sa orihinal na pagkakasunud-sunod ng input". Ang modelong ito ng "unang istraktura, pagkatapos ay output" ay ang core ng pag-iisip ng system engineering.

Ang dalawang kasong ito, ang isa ay isang real-time visual interactive system, at ang isa ay isang media information structure processing system, ay tila ganap na magkaiba. Ngunit pinapatunayan nila ang parehong bagay - ang GLM-5 ay may kumpletong kakayahan sa pagsasara ng gawain: pagpaplano → pagpapatupad → pag-debug → pag-optimize.

Sa laro ng paputok, ito ay ipinapakita sa modular layering, pag-optimize ng pagganap at paghawak ng exception; sa recorder processor, ito ay ipinapakita sa paghuhusga ng tema, paghiwa-hiwalay ng istraktura at lohikal na muling pagsasama. Ang kanilang karaniwang punto ay ang modelo ay hindi nananatili sa "pagbuo ng mga resulta", ngunit pinapanatili ang isang istraktura na maaaring patuloy na umunlad.

Patuloy kong sinubukan ang isang medyo kumplikadong gawain, "bumuo ng isang minimalist na operating system kernel". Sa aktwal na pagsubok na ito. Ang talagang nararapat na pansin ay hindi ang code sa video na sa wakas ay tumatakbo, ngunit ang paraan ng pag-uugali ng GLM-5 sa buong proseso.

Hindi ito agad na pumasok sa estado ng pagbuo pagkatapos matanggap ang gawain, ngunit unang nilinaw ang mga hangganan ng gawain, aktibong hinati ang mga module, pinlano ang istraktura ng sistema, at pagkatapos ay pumasok sa yugto ng pagpapatupad. Ang ganitong "unang istraktura" na landas ay mahalagang ang pag-iisip ng engineering na nabanggit kanina - unang tukuyin kung paano binubuo ang sistema, at pagkatapos ay talakayin ang mga partikular na detalye ng pagpapatupad, sa halip na magsulat at mag-assemble habang nagpapatuloy.

Sa maraming round ng pagsulat, pagpapatakbo, pag-uulat ng error, at pagwawasto, ang GLM-5 ay hindi rin nagpakita ng pagbagsak ng istraktura. Ang bawat pagbabago ay umiikot sa itinatag na arkitektura, sa halip na ibagsak at muling gawin o lokal na mag-patch. Ipinapahiwatig nito na pinapanatili nito ang isang kumpletong modelo ng sistema sa loob, at maaaring mapanatili ang pagkakapare-pareho sa mga gawain sa mahabang link. Maraming mga modelo ang madaling maging magkasalungat pagkatapos na humaba ang konteksto, at ang pagganap sa video ay eksaktong nagpapakita ng patuloy na kakayahan nitong tandaan ang pangkalahatang istraktura.

Gayundin ang paraan nito ng paghawak ng mga error. Kapag lumitaw ang isang error, hindi ito nananatili sa mababaw na hula ng "maaaring isang problema sa isang linya ng code", ngunit unang hinuhusgahan ang uri ng error, tinutukoy ang mga problema sa lohika, mga problema sa kapaligiran o mga salungatan sa dependency, at pagkatapos ay nagpaplano ng landas ng pag-troubleshoot. Ito ay isang estratehikong antas ng Debug, na naglalayong ayusin ang landas ng problema.

Kung pinagsama sa pagtawag sa tool, ang kakayahang ito ay magiging mas halata. Hindi lamang ito nagbibigay ng mga mungkahi sa command, ngunit pinagsasama rin ang aktibong pag-iskedyul ng pagpapatupad ng terminal, pag-aaral ng mga log, pag-aayos ng kapaligiran, at pagkatapos ay patuloy na isulong ang gawain. Ang pag-uugaling ito ay medyo malapit na sa isang "self-driving" na engineering advancement. Kung hindi pa nakumpleto ang layunin, patuloy itong umuulit.

Unang magplano at pagkatapos ay ipatupad, panatilihin ang katatagan ng istraktura sa mahabang link, i-troubleshoot ang mga problema sa isang estratehikong paraan, at patuloy na isulong ang layunin - ang superposition ng apat na pangunahing kakayahan na kinakailangan ng system engineering ay nagpapahintulot sa GLM-5 na magsimulang magpakita ng isang pattern ng pag-uugali na malapit sa paraan ng pagtatrabaho ng isang engineer.

Bakit kayang sagutin ng GLM-5 ang relay baton ng "arkitekto"?

Kung ang aktwal na pagsubok sa unang bahagi ay nagpapatunay na ang GLM-5 ay "kayang gumawa ng kumplikadong trabaho", kung gayon ang susunod na tanong ay: Paano nito nagagawa? Ang sagot ay nakasalalay sa isang buong hanay ng "engineering-level na mga pattern ng pag-uugali" na nakatago sa likod ng output.

Ang isang mahalagang punto ay ang GLM-5 ay malinaw na nagpakilala ng isang mekanismo ng self-checking ng chain of thought na katulad ng Claude Opus 4.6.

Sa aktwal na paggamit, mararamdaman mo na hindi ito agad na nagsisimulang "punan ang code" pagkatapos matanggap ang gawain, ngunit nagsasagawa ng maraming round ng lohikal na pagbabawas sa background: inaasahan ang mga relasyon ng pagkabit sa pagitan ng mga module, aktibong iniiwasan ang mga landas ng dead loop, at natutuklasan ang mga salungatan sa mapagkukunan at mga problema sa kondisyon ng hangganan nang maaga. Ang direktang pagbabago na dulot ng pag-uugaling ito ay - upang matiyak na ang plano ay nakatayo sa engineering, handa itong magpabagal at isipin ang problema nang buo.

Sa mga kumplikadong gawain, ang GLM-5 ay unang magbibigay ng isang malinaw na paghiwa-hiwalay ng module: kung aling mga submodule ang binubuo ng sistema, kung ano ang input at output ng bawat module, kung aling mga bahagi ang maaaring isulong nang magkatulad, at kung alin ang dapat kumpletuhin nang sunud-sunod. Pagkatapos ay isa-isa itong sasakupin, sa halip na magsulat at mag-isip habang nagpapatuloy. Ginagawa nitong mas katulad ng isang tunay na engineer ang paraan ng pagtatrabaho nito: unang gumuhit ng diagram ng arkitektura, pagkatapos ay isulat ang mga detalye ng pagpapatupad. Malinaw na nararamdaman na mayroon itong isang uri ng "katigasan ng ulo na hindi titigil hanggang sa malinis na malutas ang problema", sa halip na tapusin nang madali pagkatapos kumpletuhin ang isang tila tamang lokal na bahagi.

Ang pagkakaibang ito ay lalong halata sa paghahambing sa mga tradisyonal na modelo ng Coding. Sa nakaraan, maraming mga modelo ang mabilis na dumulas sa isang pamilyar na pattern kapag nakatagpo ng mga error: humihingi ng paumanhin, inuulit ang impormasyon ng error, at nagbibigay ng isang hindi pa napatunayang mungkahi sa pag-aayos; kung nabigo muli, nagsisimula itong paulit-ulit na mag-output ng mga tinatayang sagot. Ang paraan ng paghawak ng GLM-5 ay mas malapit sa isang beteranong arkitekto. Sa aktwal na pagsubok, kapag ang proyekto ay hindi tumatakbo dahil sa mga problema sa dependency ng kapaligiran, hindi ito nanatili sa mababaw na impormasyon ng error, ngunit aktibong sinuri ang dependency tree (Dependency Tree), hinuhusgahan ang pinagmulan ng salungatan, at higit pang inutusan ang OpenClaw na ayusin ang kapaligiran.

Ang buong proseso ay mas katulad ng isang "self-driving" na pag-deploy: ang modelo ay hindi tumutugon nang pasibo, ngunit patuloy na nagbabasa ng mga log, nagwawasto ng mga landas, at nagpapatunay ng mga resulta.

Ang isa pang kakayahan na madalas na binabalewala, ngunit napakahalaga sa system engineering, ay ang pagkakumpleto ng konteksto.

Ang milyun-milyong Token window ng GLM-5 ay nagbibigay-daan dito na maunawaan ang buong istraktura ng code ng proyekto, kasaysayan ng pagbabago, mga configuration file at mga log ng pagpapatakbo sa parehong konteksto. Nangangahulugan ito na kaya na nitong husgahan ang mga kadena ng reaksyon na gagawin ng isang pagbabago sa kung aling mga module mula sa isang pandaigdigang pananaw. Sa mga gawain sa mahabang link, ang kakayahang ito ay direktang tumutukoy kung ang modelo ay "matalino ngunit malapit ang paningin" o "matatag at makokontrol".

Sa pangkalahatan, ang GLM-5 ay talagang sumasagot sa papel ng "arkitekto", pangunahin dahil nagsisimula itong mag-isip ng mga problema tulad ng isang arkitekto: unang magplano, pagkatapos ay ipatupad; patuloy na patunayan, patuloy na iwasto; bigyang-pansin ang pangkalahatang sistema, sa halip na ang tagumpay ng isang punto.

Ito rin ang pangunahing dahilan kung bakit nagagawa nitong kumpletuhin ang mga aktwal na gawain sa antas ng sistema sa unang bahagi.

03

Opus ng Open Source World?

Kung titingnan sa ekolohiya ng malalaking modelo sa 2026, ang halaga ng GLM-5 ay higit na nakasalalay sa paglabag nito sa isang bagay na halos tinatanggap na dati: ang system-level intelligence ay tila maaari lamang umiral sa mga saradong modelo.

Dati, talagang pinatakbo ng Claude Opus 4.6 at GPT-5.3 ang landas ng "Agentic Coding" - ang modelo ay hindi na naghahangad ng agarang feedback, ngunit sa pamamagitan ng pagpaplano, paghiwa-hiwalay, at paulit-ulit na pagpapatakbo, upang kumpletuhin ang tunay na kumplikadong mga gawain sa engineering. Ngunit ang halaga ay napakataas din: ang pagkonsumo ng Token ng mga high-intensity na gawain ay napakataas, at ang isang kumpletong pagtatangka sa antas ng sistema ay madalas na nangangahulugan ng isang malaking gastos sa pagtawag.

Dito nagbibigay ang GLM-5 ng ibang solusyon. Bilang isang open source na modelo, ibinalik nito ang "system architect-level AI" mula sa cloud at mga bill sa sariling kapaligiran ng mga developer. Maaari mo itong i-deploy nang lokal, hayaan itong gumugol ng oras sa pagnguya sa mga maruruming trabaho, nakakapagod na trabaho, at malalaking trabaho: ayusin ang mga log, suriin ang mga dependency, baguhin ang lumang code, at punan ang mga kondisyon ng hangganan.

Maaari itong ituring bilang isang pagbabago sa istruktura ng cost-effectiveness - ang arkitekto-level intelligence ay hindi na isang pribilehiyo ng ilang mga koponan.

Kung gagamitin ang isang propesyonal na metapora upang maunawaan ang pagkakaibang ito, ito ay magiging mas intuitive. Ang mga modelo tulad ng Kimi 2.5 ay mas katulad ng mahuhusay na front-end engineer na may online na aesthetics at malakas na pakiramdam ng interaksyon, mahusay sa One-shot generation, visual presentation at mabilis na feedback; habang ang estilo ng GLM-5 ay malinaw na naiiba, ito ay mas katulad ng isang beteranong system architect na nagbabantay sa ilalim na linya at nagbibigay-diin sa lohika: bigyang-pansin ang mga relasyon ng module, mga landas ng exception, pagpapanatili at pangmatagalang matatag na operasyon.

Sa likod nito, sa katunayan, ay isang malinaw na propesyonal na pag-unlad ng programming AI - mula sa paghahangad ng "mukhang napakasarap" na Vibe Coding, hanggang sa pagbibigay-diin sa robustness at engineering discipline ng Engineering.

Higit sa mahalaga, ang paglitaw ng GLM-5 ay ginagawang mas maisasakatuparan ang konsepto ng isang taong kumpanya.Kapag ang isang developer ay mayroon nang AI partner sa lokal na computer na nakakaunawa sa system design, kayang tumakbo nang matagal, at kayang mag-self-correct, maraming gawaing pang-engineering na dating nangangailangan ng malaking team ay nagsisimulang maging kontrolado ng isang indibidwal. Sa hinaharap, may potensyal ang GLM-5 na maging "digital partner" sa isang "one-person company", na responsable sa pangunahing pagpapatupad ng engineering.