Епоха Opus у світі відкритого коду: чи зможе GLM-5 перейняти естафету Agentic Coding?
Якщо ви запитаєте розробника, який момент у AI-програмуванні найбільше дратує, він, швидше за все, відповість, що це механічне «Вибачте, я неправильно зрозумів» перед помилкою, а потім повторення того ж неправильного коду.
За останній рік прогрес 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 спочатку дає чітке розкладання модуля: з яких підмодулів складається система, які вхідні та вихідні дані кожного модуля, які частини можна просувати паралельно, а які потрібно завершити послідовно. Потім він долає їх один за одним, а не пише та думає одночасно. Це робить його спосіб роботи більше схожим на справжнього інженера: **спочатку намалювати архітектурну схему, а потім написати деталі реалізації**. Очевидно, що він має «стійкість не зупинятися, поки проблема не буде вирішена повністю», а не недбало завершувати, виконавши локальну частину, яка здається правильною.
Ця різниця особливо очевидна в порівнянні з традиційними моделями Coding. У минулому багато моделей швидко впадали у знайому модель, коли стикалися з помилками: вибачалися, повторювали інформацію про помилку, давали неперевірену пропозицію щодо виправлення; якщо знову не вдавалося, вони починали циклічно виводити приблизні відповіді. Спосіб обробки GLM-5 більше схожий на досвідченого архітектора. У реальному тесті, коли проєкт не міг запуститися через проблеми із залежностями середовища, він не зупинився на поверхневій інформації про помилку, а активно проаналізував дерево залежностей (Dependency Tree), визначив джерело конфлікту та додатково наказав OpenClaw відновити середовище.
Весь процес більше схожий на розгортання в стилі «автопілота»: модель не реагує пасивно, а постійно зчитує журнали, виправляє шляхи, перевіряє результати.
Інша здатність, яку часто ігнорують, але яка надзвичайно важлива в системній інженерії, – це цілісність контексту.
Вікно в мільйон токенів GLM-5 дозволяє йому розуміти структуру коду, історію змін, файли конфігурації та журнали виконання всього проєкту в одному контексті. Це означає, що він уже може судити про те, які модулі викличе зміна з глобальної точки зору. У завданнях з довгим ланцюгом ця здатність безпосередньо визначає, чи є модель «розумною, але недалекоглядною», чи «стабільною та контрольованою».
Загалом, GLM-5 дійсно переймає роль «архітектора» головним чином тому, що **починає думати про проблеми, як архітектор**: спочатку планувати, потім виконувати; постійно перевіряти, постійно виправляти; зосереджуватися на системі в цілому, а не на одноточковій успішності.
Це також є основною причиною, чому він може виконувати ті системні реальні тестові завдання в першій частині.
***03***
**Opus у світі відкритого коду?**
З точки зору екосистеми великих моделей у 2026 році, цінність GLM-5 полягає більше в тому, що він порушив те, що раніше майже за замовчуванням приймалося: системний інтелект, здається, може існувати лише в моделях із закритим кодом.
Раніше Claude Opus 4.6 і GPT-5.3 дійсно пройшли шлях «Agentic Coding» – модель більше не прагне до миттєвого зворотного зв'язку, а виконує справді складні інженерні завдання шляхом планування, розбиття на частини та багаторазового виконання. Але ціна також висока: споживання токенів для завдань з високою інтенсивністю надзвичайно високе, і повна спроба системного рівня часто означає значні витрати на виклик.
GLM-5 пропонує тут інше рішення. Як модель з відкритим кодом, він повернув «AI рівня системного архітектора» з хмари та рахунків у власне середовище розробника. Ви можете розгорнути його локально, щоб він витрачав час на те, щоб гризти ту брудну, важку та велику роботу: налаштовувати журнали, перевіряти залежності, змінювати старий код, заповнювати граничні умови.
Це можна розглядати як структурну зміну рентабельності – інтелект рівня архітектора більше не є привілеєм невеликої кількості команд.
Якщо використовувати професійну метафору для розуміння цієї різниці, це буде більш інтуїтивно зрозуміло. Моделі, як-от Kimi 2.5, більше схожі на відмінних фронтенд-інженерів з онлайн-естетикою та надзвичайною інтерактивністю, які вміють генерувати One-shot, візуально представляти та швидко надавати зворотний зв'язок; а стиль GLM-5 явно відрізняється, він більше схожий на досвідченого системного архітектора, який дотримується основних принципів і логіки: звертає увагу на відносини між модулями, шляхи винятків, можливість обслуговування та довгострокову стабільну роботу.
За цим насправді стоїть чітке професійне просування програмування AI – від прагнення до Vibe Coding, який «виглядає дуже круто», до Engineering, який наголошує на надійності та інженерній дисципліні.
Що ще важливіше, поява GLM-5 робить концепцію компанії з однією людиною більш реалістичною.
Коли розробник може мати локально AI-партнера, який розуміє системний дизайн, може працювати тривалий час і самостійно виправляти помилки, багато інженерних робіт, які раніше вимагали командної роботи, починають стискатися до масштабу, контрольованого однією людиною. У майбутньому GLM-5 має потенціал стати тим «цифровим партнером», який відповідає за основну інженерну реалізацію в компанії з однією людиною.
