Отворен код Opus момент: Дали GLM-5 може да ја преземе штафетата на Agentic Coding?

Ако прашате програмер, кој е најфрустрирачкиот момент во програмирањето со вештачка интелигенција?

Најверојатно ќе ви одговори дека тоа е механичкото „Извинете, погрешно разбрав“ пред грешка, а потоа повторување на истиот погрешен код.

Во текот на изминатата година, напредокот на големите модели за кодирање повеќе се рефлектира во „способноста за генерирање“: генерирање веб-страници, компоненти, мали игри со една реченица - создавање веб-страница во пиксели, кул SVG икона или игра со змија што може да се игра за 15 секунди. Овие демо снимки се доволно неверојатни, но и доволно „лесни“, тие се малку како напредни играчки произведени во ерата на Vibe Coding (програмирање со атмосфера). Но, кога станува збор за архитектура со висока конкурентност, прилагодување на основните драјвери или сложена системска реконструкција, тие стануваат „цвеќиња во стаклена градина“.

Така, неодамна, ветрот во Силиконската долина се смени.

Без разлика дали станува збор за Claude Opus 4.6 или GPT-5.3, овие врвни големи модели почнуваат да го нагласуваат Agentic Coding: не бараат „брзи резултати“, туку завршуваат задачи на ниво на систем преку планирање, декомпозиција и повторено извршување.

Оваа промена на парадигмата од „естетика на предниот дел“ во „системско инженерство“ некогаш се сметаше за монополска област на затворени гиганти. Дури откако го тестирав GLM-5, сфатив дека „ерата на архитекти“ на заедницата со отворен код започна порано.

01

Од „преден дел“ до „системско инженерство“

Претходно, кога се зборуваше за AI Coding, најчесто се мислеше на познат наратив - генерирање веб-страница со една реченица, правење мала игра за една минута и поставување кул ефект за десет секунди. Тие ја нагласуваат „визуелната свежина“: копчињата се движат, страниците се убави, а ефектите се богати.

Но, оние кои навистина влегуваат во инженерската област знаат дека можноста да се генерира демо не значи дека може да се поддржи систем.

Тешкотијата на сложените задачи не е во „пишувањето код“, туку во тоа како да се поделат модулите, како да се управува со статусот, како да се обезбеди резервна копија за исклучоци, како да се оптимизираат перформансите и дали структурата може да остане стабилна кога системот ќе почне да станува сложен.

Ова е причината зошто избравме сложени задачи како објекти за тестирање во реални услови.

Позиционирањето на GLM-5 е различно од многу конкурентни производи.

Ако повеќето модели се повеќе како „одличен преден дел“ - добри во брзо генерирање интерактивни интерфејси и визуелни ефекти, тогаш GLM-5 е повеќе наклонет кон „улогата на системско инженерство“. Тој ја нагласува соработката со повеќе модули, задачи со долги врски и структурната стабилност што може да се изврши во производната средина.

За да го потврдиме ова, дизајниравме две реални случаи на тестирање со сосема различни димензии.

Првиот тест е задача која изгледа лесно, но е високо систематизирана - да се имплементира интерактивна игра со тема на пролетниот фестивал „AI визуелна контрола на огномет во воздух“ заснована на прелистувач и камера.

Како што може да се види во видеото од реалниот тест, корисникот стои пред камерата и го контролира правецот и ритамот на лансирање на огнометот со гестови; огнометот цвета во воздухот, придружен со ефекти на честички и повратни информации за динамички светлечки ефекти, а целокупната интеракција е течна и природна.

Но, ова не е едноставен проект за динамички ефекти на предниот дел. Тој содржи барем неколку основни модули: препознавање гестови и обработка на визуелен влез; мапирање на координатите на гестовите во логиката на лансирање; систем на честички на огномет и ефекти на цветање; реално време рендерирање и контрола на стапката на слики; компатибилност на прелистувачот и обработка на абнормалности на дозволите на камерата; управување со интерактивниот статус и механизам за повратни информации од корисникот

Може да се каже дека е мал интерактивен систем со комплетна структура и течно искуство. Од процесот на тестирање во реални услови, може да се види дека GLM-5 не влезе директно во кодирање, туку прво ја планираше целокупната архитектура: како да се одделат модулите за визуелен влез, контролниот логички слој, слојот за рендерирање и слојот за специјални ефекти; како да се пренесе протокот на податоци; кои делови може да станат тесни грла во перформансите.

Последователно, тој ја имплементираше логиката слој по слој, почнувајќи од обработката на податоците за препознавање гестови, до пресметката на траекторијата на лансирање, а потоа и до финото подесување на параметрите на ефектот на експлозија на честички.

Кога рендерирањето се заглави, тој проактивно предложи да се намали бројот на честички, да се оптимизира структурата на јамката; кога препознавањето гестови погрешно процени, тој ги прилагоди праговите и стратегиите за филтрирање.

Ефектот прикажан во видеото е „интеракција што изгледа многу природно“. Но, она што се рефлектира зад него е комплетен инженерски синџир: планирање → пишување → дебагирање → оптимизација на перформансите → корекција на интеракцијата.

Кодот што конечно се генерира може директно да се изврши, интеракцијата е стабилна, стапката на слики е мазна и може да се справи со абнормални ситуации. Поважно, неговиот начин на работа претставува јасно системско размислување: границите на модулите се јасни, логичкото слоевитост е разумно, наместо да ги натрупува сите функции во една датотека.

Вториот случај го тестира системскиот капацитет на структурата. Оваа сцена може да се каже дека е рутина во работата на медиумите - увезете стенограм од интервју, сумирајте ја содржината и изнесете перспективи и идеи за темата.

Како што може да се види во реалниот тест, процесот на работа е многу директен: залепив дел од стенограмот од интервјуто од пред некое време, моделот почна да анализира, а потоа изнесе резиме на содржината и перспективи за темата. Судејќи според резултатите, перспективите за темата што ги генерираше сепак се многу оперативни.

Во споредба со системот за визуелна интеракција, средувањето на снимките изгледа едноставно, но всушност ја тестира „способноста за структурна апстракција“ на моделот. Вистинската снимка од интервју често е високо неструктурирана: гледиштата скокаат, информациите се повторуваат, а главните и споредните линии се испреплетуваат. Затоа, во овој случај, способноста што ја покажа GLM-5 е на ниво на систем.

Прво, способност за препознавање теми и екстракција на главната линија. Моделот не генерираше резиме по редоследот на оригиналниот текст, туку прво процени која е основната тема, а потоа ја реорганизираше содржината околу оваа тема. Ова значи дека заврши скенирање внатрешно за да се идентификува кои информации припаѓаат на главната линија, а кои припаѓаат на дополнување или шум. Оваа способност е во суштина способност за планирање, односно воспоставување апстрактна структурна рамка пред да се изнесе.

Второ, способност за модуларна рекомбинација. Тој ќе ги категоризира релевантните гледишта расфрлани во различни пасуси во ист модул. Оваа способност за интеграција на повеќе пасуси покажува дека моделот има глобална конзистентност при обработка на долги текстови.

Трето, способност за проактивно прилагодување на логичкиот редослед. Вистинскиот изнесен нацрт често е различен од редоследот на оригиналната снимка. Може да се види дека GLM-5 има пресуда за „логиката е приоритет пред редоследот на оригиналниот влез“ според причинско-последичната врска или логиката на аргументација за повторно подредување на нивоата. Овој модел на „прво структура, потоа излез“ е јадрото на системското инженерско размислување.

Овие два случаи, едниот е систем за визуелна интеракција во реално време, а другиот е систем за обработка на структурата на медиумските информации, изгледаат сосема различни. Но, тие го потврдуваат истото нешто - GLM-5 има комплетна способност за затворање на задачите: планирање → извршување → дебагирање → оптимизација.

Во играта со огномет, ова се рефлектира во слоевитоста на модулите, оптимизацијата на перформансите и справувањето со абнормалности; во процесорот за снимање, ова се рефлектира во проценката на темата, структурната декомпозиција и логичката рекомбинација. Нивната заедничка точка е тоа што моделот не застана на „генерирање резултати“, туку одржува структура што може одржливо да се развива.

Продолжив да пробувам релативно сложена задача, „изградба на минимално јадро на оперативниот систем“. Во овој реален тест. Она што навистина вреди да се забележи не е тоа што кодот конечно се извршува во видеото, туку начинот на кој GLM-5 се однесува во текот на целиот процес.

Тој не влезе веднаш во состојба на генерирање откако ја доби задачата, туку прво ги разјасни границите на задачата, проактивно ги подели модулите, ја планираше структурата на системот, а потоа влезе во фазата на имплементација. Овој пат на „структурата е приоритет“ е во суштина инженерското размислување што го споменавме претходно - прво дефинирајте како е составен системот, а потоа разговарајте за специфичните детали за имплементација, наместо да пишувате и да составувате.

Во циклусот на повеќекратни пишувања, извршувања, грешки и корекции, GLM-5 исто така не покажа структурно пропаѓање. Секоја модификација се одвива околу воспоставената архитектура, наместо да се укине и да се започне одново или да се направат локални закрпи. Ова покажува дека тој одржува комплетен системски модел внатрешно и може да одржува конзистентност во задачите со долги врски. Многу модели се склони кон контрадикторности откако контекстот ќе се продолжи, а перформансите во видеото ја одразуваат неговата способност постојано да ја памети целокупната структура.

Исто така, начинот на кој се справува со грешките. Кога ќе се појави грешка, тој не застана на површинските претпоставки за „можеби има проблем со линија од кодот“, туку прво го процени типот на грешката, ги разликува логичките проблеми, проблемите со околината или конфликтите на зависности, а потоа го планира патот за проверка. Ова е дебагирање на ниво на стратегија, кое има за цел да го поправи патот на проблемот.

Ако се комбинира со повикување на алатки, оваа способност ќе биде поочигледна. Тој не само што дава предлози за команди, туку и се комбинира со проактивно распоредување на извршување на терминалот, анализа на дневници, поправка на околината и продолжување со задачата. Ова однесување е веќе малку блиску до „автопилот“ инженерски напредок. Ако целта не е завршена, таа продолжува да се повторува.

Прво планирање, потоа извршување, одржување на структурна стабилност во долги врски, решавање на проблеми на стратешки начин и континуирано напредување околу целта - комбинацијата на четирите основни способности потребни за системско инженерство му овозможува на GLM-5 да почне да покажува модели на однесување блиски до начинот на работа на инженерите.

Зошто GLM-5 може да ја преземе штафетата на „архитект“?

Ако првиот дел од реалниот тест докажа дека GLM-5 „може да врши сложени работи“, тогаш следното прашање е: зошто може? Одговорот лежи во целиот сет на „инженерски модели на однесување“ скриени зад излезот.

Клучната точка е дека GLM-5 очигледно воведе механизам за самопроверка на синџирот на размислување сличен на Claude Opus 4.6.

Во реалната употреба, може да се почувствува дека тој не почнува веднаш да „пополнува код“ откако ќе ја добие задачата, туку врши повеќекратни логички дедукции во заднина: предвидување на односите на спојување помеѓу модулите, проактивно избегнување на патеките на мртва јамка и откривање проблеми со конфликти на ресурси и гранични услови однапред. Директната промена што ја носи ова однесување е - за да се осигура дека решението е инженерски издржано, тој е подготвен да забави и целосно да размисли за проблемот.

Во сложените задачи, GLM-5 прво ќе даде јасна декомпозиција на модулите: од кои подмодули е составен системот, кои се влезовите и излезите на секој модул, кои делови може да се унапредат паралелно и кои мора да се завршат сериски. Потоа, тој ги освојува еден по еден, наместо да пишува и да размислува. Ова го прави неговиот начин на работа повеќе како вистински инженер: прво нацртајте дијаграм на архитектура, а потоа напишете детали за имплементација. Очигледно се чувствува дека има „упорност да не престане додека не го реши проблемот целосно“, наместо да заврши локален дел што изгледа точен и да заврши набрзина.

Оваа разлика е особено очигледна во споредба со традиционалните модели за кодирање. Во минатото, многу модели брзо се лизгаа во познат модел кога ќе наидеа на грешки: извинување, повторување на информациите за грешката, давање неверификуван предлог за поправка; ако повторно не успее, почнува да изнесува приближни одговори во циклус. Начинот на кој GLM-5 се справува со тоа е поблизок до искусен архитект. Во реалниот тест, кога проектот не можеше да се изврши поради проблеми со зависноста од околината, тој не застана на информациите за грешката на површината, туку проактивно го анализираше дрвото на зависности (Dependency Tree), го процени изворот на конфликтот и дополнително му нареди на OpenClaw да ја поправи околината.

Целиот процес е повеќе како распоредување во стилот на „автопилот“: моделот не реагира пасивно, туку постојано чита дневници, ги коригира патеките и ги потврдува резултатите.

Друга способност што често се занемарува, но е исклучително важна во системското инженерство, е комплетноста на контекстот.

Прозорецот Token од милион нивоа на GLM-5 му овозможува да ја разбере структурата на кодот, историските модификации, конфигурационите датотеки и дневниците за извршување на целиот проект во истиот контекст. Ова значи дека тој веќе може да процени од глобална перспектива кои модули ќе бидат погодени од синџирната реакција на модификација. Во задачите со долги врски, оваа способност директно одредува дали моделот е „паметен, но кратковид“ или „стабилен и контролиран“.

Севкупно, GLM-5 навистина ја презема улогата на „архитект“, главно затоа што почна да размислува за проблемите како архитект: прво планирање, потоа извршување; постојано проверување, постојано коригирање; фокусирање на целиот систем, наместо на еден успешен момент.

Ова е основната причина зошто може да ги заврши задачите за тестирање на ниво на систем во првиот дел.

03

Opus на отворен код?

Гледано во екосистемот на големи модели во 2026 година, вредноста на GLM-5 повеќе лежи во тоа што скрши нешто што претходно беше речиси стандардно прифатено: интелигенцијата на ниво на систем се чини дека може да постои само во модели со затворен код.

Претходно, Claude Opus 4.6 и GPT-5.3 навистина го отворија патот на „Agentic Coding“ - моделот повеќе не бара инстант повратни информации, туку завршува навистина сложени инженерски задачи преку планирање, декомпозиција и повторено извршување. Но, цената е исто така висока: потрошувачката на Token за задачи со висок интензитет е исклучително висока, а целосен обид на ниво на систем често значи значителни трошоци за повикување.

GLM-5 нуди различно решение овде. Како модел со отворен код, тој ја враќа „AI на ниво на системски архитект“ од облакот и сметките во сопствената околина на програмерите. Можете да го распоредите локално и да му дозволите да одвои време за да ги грицка валканите, напорни и големи работи: прилагодување на дневници, проверка на зависности, менување стар код и дополнување на гранични услови.

Ова може да се гледа како структурна промена во однос на трошоците - интелигенцијата на ниво на архитект повеќе не е привилегија на мал број тимови.

Ако ја разбереме оваа разлика со професионална метафора, тоа ќе биде поинтуитивно. Моделите како Kimi 2.5 се повеќе како одлични инженери на предниот дел со онлајн естетика и силно чувство за интеракција, добри во генерирање со еден удар, визуелна презентација и брза повратна информација; додека стилот на GLM-5 е очигледно различен, тој е повеќе како искусен системски архитект кој се придржува до основните принципи и ја нагласува логиката: фокусирање на односите на модулите, абнормалните патеки, одржливоста и долгорочното стабилно работење.

Зад ова, всушност, е јасно професионално унапредување на програмирањето со вештачка интелигенција - од стремеж кон Vibe Coding што „изгледа многу освежувачки“ до нагласување на робусноста и инженерската дисциплина.

Поважно, појавата на GLM-5 го прави концептот на компанија со еден човек поостварлив.Кога еден развивач може да има локално AI партнер кој разбира системски дизајн, може да работи долгорочно и може самостојно да се коригира, многу инженерски работи кои првично бараа тимска работа почнуваат да се компресираат во опсег контролиран од поединец. Следно, GLM-5 има потенцијал да стане „дигитален партнер“ одговорен за основната инженерска имплементација во компанија со еден човек.