Момент Opus в мире Open Source: сможет ли GLM-5 подхватить эстафету Agentic Coding?

Если вы спросите разработчика, какой момент в AI-программировании вызывает наибольшее отчаяние,

то, скорее всего, он ответит, что это механическое «Извините, я неправильно понял» перед ошибкой, а затем повторение того же ошибочного кода.

В прошлом году прогресс больших языковых моделей в программировании больше проявлялся в «возможностях генерации»: создание веб-страниц, компонентов, небольших игр одной фразой — создание пиксельной веб-страницы, крутой SVG-иконки или работающей «Змейки» за 15 секунд. Эти демо достаточно впечатляющие, но и достаточно «легкие», они немного похожи на продвинутые игрушки, созданные в эпоху Vibe Coding (программирование под настроение). Но когда дело доходит до высоконагруженной архитектуры, адаптации драйверов нижнего уровня или сложной реструктуризации системы, они становятся «тепличными цветами».

Поэтому в последнее время в Кремниевой долине изменился ветер.

Будь то Claude Opus 4.6 или GPT-5.3, эти топовые большие модели начинают подчеркивать Agentic Coding: не стремятся к «мгновенному результату», а выполняют задачи системного уровня посредством планирования, декомпозиции и многократного выполнения.

Этот сдвиг парадигмы от «фронтенд-эстетики» к «системной инженерии» ранее считался монополией закрытых гигантов. Только после тестирования GLM-5 я понял, что «эпоха архитекторов» в сообществе Open Source началась раньше времени.

01

От «фронтенда» к «системной инженерии»

Раньше, говоря об AI Coding, в основном вспоминали знакомый нарратив — создание веб-страницы одной фразой, создание небольшой игры за минуту, создание крутого динамического эффекта за десять секунд. Они подчеркивают «визуальное удовольствие»: кнопки двигаются, страницы красивые, эффекты богатые.

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

Сложность сложных задач заключается не в «написании кода», а в том, как разделить модули, как управлять состоянием, как обрабатывать исключения, как оптимизировать производительность и, когда система становится сложной, можно ли поддерживать стабильность структуры.

Это также причина, по которой мы выбрали сложные задачи в качестве объектов для реальных тестов.

Позиционирование GLM-5 отличается от многих конкурентов.

Если большинство моделей больше похожи на «отличный фронтенд» — умеют быстро генерировать интерактивные интерфейсы и визуальные эффекты, то GLM-5 больше склоняется к «роли системного инженера». Он подчеркивает многомодульное сотрудничество, задачи с длинными связями и структурную стабильность, пригодную для работы в производственной среде.

Чтобы проверить это, мы разработали два совершенно разных по масштабу практических примера.

Первый тест — кажущаяся легкой, но на самом деле высоко систематизированная задача — создание интерактивной игры на тему китайского Нового года «AI Visual Air Control Fireworks» на основе браузера и камеры.

В видео реального теста видно, что пользователь стоит перед камерой и управляет направлением и ритмом запуска фейерверков с помощью жестов; фейерверки распускаются в воздухе, сопровождаясь эффектами частиц и динамической световой обратной связью, а общее взаимодействие плавное и естественное.

Но это не простой проект фронтенд-динамических эффектов. Он включает в себя как минимум следующие основные модули: распознавание жестов и обработка визуального ввода; отображение координат жестов в логику запуска; система частиц фейерверка и эффекты распускания; рендеринг в реальном времени и контроль частоты кадров; совместимость с браузером и обработка исключений разрешений камеры; управление состоянием взаимодействия и механизмы обратной связи с пользователем.

Можно сказать, что это небольшая интерактивная система с полной структурой и плавным взаимодействием. Судя по процессу реального тестирования, 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 в мире Open Source?

Если смотреть на экологию больших моделей в 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 потенциально может стать тем самым «цифровым партнером», отвечающим за ключевую инженерную реализацию в компании, состоящей из одного человека.