Moment Opus w świecie open source: Czy GLM-5 przejmie pałeczkę w Agentic Codingu?

Jeśli zapytasz programistę, jaki jest najbardziej frustrujący moment w programowaniu z wykorzystaniem AI?

Odpowiedź prawdopodobnie będzie brzmiała: mechaniczne „Przepraszam, źle zrozumiałem” w obliczu błędu, a następnie powtarzanie tego samego błędnego kodu.

W ciągu ostatniego roku postęp modeli Coding był bardziej widoczny w „zdolności generowania”: generowanie stron internetowych, komponentów, małych gier jednym zdaniem – stworzenie strony internetowej w stylu pixel art, fajnej ikony SVG lub działającego węża w 15 sekund. Te dema są wystarczająco oszałamiające, ale także wystarczająco „lekkie”, przypominają zaawansowane zabawki wyprodukowane w erze Vibe Coding (programowania z klimatem). Ale jeśli chodzi o architekturę wysokiej współbieżności, adaptację sterowników niskiego poziomu lub złożoną przebudowę systemu, stają się one „kwiatami szklarniowymi”.

Ostatnio w Dolinie Krzemowej wiatr zmienił kierunek.

Niezależnie od tego, czy jest to Claude Opus 4.6, czy GPT-5.3, te topowe modele zaczynają podkreślać Agentic Coding: nie dążą do „natychmiastowych wyników”, ale poprzez planowanie, dekompozycję i powtarzane uruchamianie, realizują zadania na poziomie systemu.

To przesunięcie paradygmatu od „estetyki front-endu” do „inżynierii systemów” było wcześniej uważane za obszar monopolu zamkniętych gigantów. Dopiero po przetestowaniu GLM-5 zdałem sobie sprawę, że „era architektów” w społeczności open source rozpoczęła się wcześniej.

01

Od „front-endu” do „inżynierii systemów”

Wcześniej, mówiąc o AI Coding, najczęściej myślało się o znajomej narracji – generowanie stron internetowych jednym zdaniem, tworzenie małej gry w minutę, budowanie fajnego efektu animacji w dziesięć sekund. Podkreślają one „wizualną przyjemność”: przyciski się poruszają, strona wygląda dobrze, efekty są bogate.

Ale każdy, kto naprawdę wszedł na plac budowy, wie, że wygenerowanie dema nie oznacza możliwości utrzymania systemu.

Trudność złożonych zadań nie polega na „pisaniu kodu”, ale na tym, jak podzielić moduły, jak zarządzać stanem, jak zabezpieczyć się przed wyjątkami, jak zoptymalizować wydajność i czy system może utrzymać stabilność struktury, gdy zaczyna się komplikować.

Dlatego wybraliśmy złożone zadania jako obiekty testowe w świecie rzeczywistym.

Pozycjonowanie GLM-5 różni się od wielu konkurencyjnych produktów.

Jeśli większość modeli przypomina bardziej „doskonały front-end” – dobrze radzi sobie z szybkim generowaniem interfejsów interaktywnych i efektów wizualnych, to GLM-5 jest bardziej zbliżony do „roli inżynierii systemów”. Podkreśla współpracę wielu modułów, zadania o długiej ścieżce i stabilność struktury, która może działać w środowisku produkcyjnym.

Aby to zweryfikować, zaprojektowaliśmy dwa zupełnie różne wymiarowo przypadki testowe w świecie rzeczywistym.

Pierwszy test to zadanie, które wydaje się łatwe, ale w rzeczywistości jest wysoce usystematyzowane – oparte na przeglądarce i kamerze, aby zrealizować interaktywną grę o tematyce noworocznej „AI Visual Air Control Fireworks”.

Jak widać na filmie z testów w świecie rzeczywistym, użytkownik stoi przed kamerą i kontroluje kierunek i rytm wystrzeliwania fajerwerków za pomocą gestów; fajerwerki rozkwitają w powietrzu, czemu towarzyszą efekty cząsteczkowe i dynamiczne sprzężenie zwrotne efektów świetlnych, a cała interakcja jest płynna i naturalna.

Ale to nie jest prosty projekt efektów front-end. Zawiera co najmniej następujące podstawowe moduły: rozpoznawanie gestów i przetwarzanie wejścia wizualnego; mapowanie współrzędnych gestów na logikę wystrzeliwania; system cząsteczek fajerwerków i efekty rozkwitu; renderowanie w czasie rzeczywistym i kontrola liczby klatek na sekundę; obsługa kompatybilności przeglądarki i wyjątków uprawnień kamery; zarządzanie stanem interakcji i mechanizmy sprzężenia zwrotnego z użytkownikiem.

Można powiedzieć, że jest to mały interaktywny system o kompletnej strukturze i płynnym działaniu. Z procesu testowania w świecie rzeczywistym wynika, że GLM-5 nie wszedł bezpośrednio w kodowanie, ale najpierw zaplanował ogólną architekturę: jak oddzielić moduł wejścia wizualnego, warstwę logiki sterowania, warstwę renderowania i warstwę efektów specjalnych; jak przesyłać strumień danych; które części mogą stać się wąskim gardłem wydajności.

Następnie realizuje logikę warstwa po warstwie, zaczynając od przetwarzania danych rozpoznawania gestów, poprzez obliczanie trajektorii wystrzeliwania, aż po dostrajanie parametrów efektu eksplozji cząsteczek.

Gdy renderowanie utknęło, aktywnie zasugerował zmniejszenie liczby cząsteczek i optymalizację struktury pętli; gdy rozpoznawanie gestów było błędne, dostosował próg i strategię filtrowania.

Efekt prezentowany na filmie to „interakcja, która wydaje się bardzo naturalna”. Ale za tym kryje się kompletny łańcuch inżynieryjny: planowanie → pisanie → debugowanie → optymalizacja wydajności → korekta interakcji.

Wygenerowany kod można uruchomić bezpośrednio, interakcja jest stabilna, liczba klatek na sekundę jest płynna, a wyjątkowe sytuacje można obsłużyć. Co ważniejsze, jego sposób pracy prezentuje jasne myślenie systemowe: granice modułów są jasne, warstwy logiczne są rozsądne, a nie układanie wszystkich funkcji w jednym pliku.

Drugi przypadek testuje zdolność systemu strukturalnego. Ten scenariusz można powiedzieć, że jest codzienną pracą mediów – importowanie stenogramu wywiadu, podsumowywanie treści i wyprowadzanie kątów i pomysłów na tematy.

Jak widać w teście w świecie rzeczywistym, proces działania jest bardzo bezpośredni: wkleiłem stenogram wywiadu z jakiegoś czasu temu, model zaczął analizować, a następnie wyprowadził podsumowanie treści i kąty tematyczne. Z wyników wynika, że kąty tematyczne, które wygenerował, są nadal bardzo operacyjne.

W porównaniu z wizualnym systemem interakcji, porządkowanie nagrań wydaje się proste, ale w rzeczywistości testuje „zdolność abstrakcji struktury” modelu. Prawdziwe nagranie wywiadu jest często wysoce niestrukturalne: przeskakiwanie punktów widzenia, powtarzanie informacji, przeplatanie się linii głównych i pobocznych. Dlatego w tym przypadku zdolność, którą wykazał GLM-5, jest na poziomie systemu.

Po pierwsze, zdolność rozpoznawania tematów i wyodrębniania linii głównych. Model nie generuje streszczenia w kolejności oryginalnego tekstu, ale najpierw ocenia, jaki jest główny temat, a następnie reorganizuje treść wokół tego tematu. Oznacza to, że wewnętrznie zakończył skanowanie, rozpoznając, które informacje należą do linii głównej, a które są uzupełnieniem lub szumem. Ta zdolność jest w istocie zdolnością planowania, czyli ustanowienia abstrakcyjnej ramy strukturalnej przed wyprowadzeniem.

Po drugie, zdolność do ponownego montażu modułowego. Będzie klasyfikować powiązane punkty widzenia rozproszone w różnych akapitach do tego samego modułu. Ta zdolność integracji między akapitami pokazuje, że model ma globalną spójność podczas przetwarzania długich tekstów.

Po trzecie, zdolność do aktywnego dostosowywania kolejności logicznej. Rzeczywisty wyprowadzony zarys często różni się od oryginalnej kolejności nagrywania. Widać, że GLM-5 dokonuje ponownego ułożenia warstw zgodnie z relacjami przyczynowo-skutkowymi lub logiką argumentacji. Odzwierciedla to osąd „logika ma pierwszeństwo przed oryginalną kolejnością wejścia”. Ten tryb „najpierw struktura, potem wyjście” jest rdzeniem myślenia o inżynierii systemów.

Te dwa przypadki, jeden to system interakcji wizualnej w czasie rzeczywistym, a drugi to system przetwarzania struktury informacji medialnych, wydają się zupełnie różne. Ale weryfikują to samo – GLM-5 ma pełną zdolność do zamknięcia pętli zadania: planowanie → wykonanie → debugowanie → optymalizacja.

W grze w fajerwerki znajduje to odzwierciedlenie w warstwowaniu modułów, optymalizacji wydajności i obsłudze wyjątków; w procesorze nagrań znajduje to odzwierciedlenie w ocenie tematu, dekompozycji struktury i reorganizacji logicznej. Ich wspólną cechą jest to, że model nie zatrzymuje się na „generowaniu wyników”, ale utrzymuje strukturę, która może się stale rozwijać.

Kontynuowałem próby z stosunkowo złożonym zadaniem, „zbudowaniem minimalistycznego jądra systemu operacyjnego”. W tym teście w świecie rzeczywistym. Naprawdę warte uwagi jest nie to, że kod na filmie ostatecznie działa, ale sposób, w jaki GLM-5 zachowuje się w całym procesie.

Nie wszedł od razu w stan generowania po otrzymaniu zadania, ale najpierw sprecyzował granice zadania, aktywnie podzielił moduły, zaplanował strukturę systemu, a następnie wszedł w fazę realizacji. Ta ścieżka „struktura na pierwszym miejscu” jest w istocie myśleniem inżynieryjnym, o którym wspomniano wcześniej – najpierw zdefiniuj, jak system jest zbudowany, a następnie omów szczegóły implementacji, zamiast pisać i łączyć.

W wielokrotnych cyklach pisania, uruchamiania, zgłaszania błędów i poprawiania GLM-5 nie wykazywał również załamania struktury. Każda modyfikacja jest rozwijana wokół ustalonej architektury, a nie obalana i rozpoczynana od nowa lub lokalnie poprawiana. Oznacza to, że wewnętrznie utrzymuje kompletny model systemu i może zachować spójność w zadaniach o długiej ścieżce. Wiele modeli jest podatnych na sprzeczności po wydłużeniu kontekstu, a wydajność na filmie odzwierciedla jego zdolność do ciągłego zapamiętywania ogólnej struktury.

Jest też sposób, w jaki radzi sobie z błędami. Gdy pojawia się błąd, nie zatrzymuje się na powierzchownych przypuszczeniach, że „może to problem z wierszem kodu”, ale najpierw ocenia typ błędu, rozróżnia problemy logiczne, problemy środowiskowe lub konflikty zależności, a następnie planuje ścieżkę rozwiązywania problemów. Jest to debugowanie na poziomie strategii, którego celem jest naprawa ścieżki problemu.

Jeśli połączymy to z wywoływaniem narzędzi, ta zdolność stanie się bardziej oczywista. Nie tylko daje sugestie dotyczące poleceń, ale także łączy aktywne planowanie wykonania terminala, analizuje dzienniki, naprawia środowisko, a następnie kontynuuje realizację zadania. To zachowanie jest już zbliżone do „autonomicznej” realizacji inżynieryjnej. Jeśli cel nie zostanie osiągnięty, będzie kontynuował iterację.

Najpierw planowanie, a następnie wykonanie, utrzymywanie stabilności struktury w długich ścieżkach, rozwiązywanie problemów w sposób strategiczny i ciągłe dążenie do celu – to nakładanie się czterech podstawowych zdolności wymaganych przez inżynierię systemów pozwala GLM-5 zacząć prezentować wzorce zachowań zbliżone do sposobu pracy inżyniera.

Dlaczego GLM-5 może przejąć pałeczkę „architekta”?

Jeśli pierwsza część testu udowodniła, że GLM-5 „może wykonywać złożone zadania”, to następne pytanie brzmi: dlaczego może? Odpowiedź leży w całym zestawie „wzorców zachowań na poziomie inżynieryjnym” ukrytych za wyjściem.

Kluczowym punktem jest to, że GLM-5 wyraźnie wprowadził mechanizm samooceny łańcucha myślowego podobny do Claude Opus 4.6.

W rzeczywistym użyciu można odczuć, że nie zaczyna od razu „wypełniać kodu” po otrzymaniu zadania, ale przeprowadza wiele rund wnioskowania logicznego w tle: przewiduje relacje sprzężenia między modułami, aktywnie unika ścieżek nieskończonej pętli i z wyprzedzeniem wykrywa konflikty zasobów i problemy z warunkami brzegowymi. Bezpośrednią zmianą wynikającą z tego zachowania jest to, że aby upewnić się, że plan jest uzasadniony inżynieryjnie, chce zwolnić i przemyśleć problem w całości.

W złożonych zadaniach GLM-5 najpierw przedstawi jasny podział modułów: z jakich podmodułów składa się system, jakie są wejścia i wyjścia każdego modułu, które części można realizować równolegle, a które muszą być realizowane szeregowo. Następnie pokonuje je jeden po drugim, zamiast pisać i myśleć jednocześnie. To sprawia, że jego sposób pracy bardziej przypomina prawdziwego inżyniera: najpierw narysuj diagram architektury, a następnie napisz szczegóły implementacji.

Oczywiście czuje się, że ma „wytrwałość, aby nie przestać, dopóki problem nie zostanie rozwiązany”, zamiast pośpiesznie kończyć po ukończeniu pozornie poprawnej części.

Ta różnica jest szczególnie widoczna w porównaniu z tradycyjnymi modelami Coding. W przeszłości wiele modeli, napotykając błędy, szybko wpadało w znajomy tryb: przepraszanie, powtarzanie informacji o błędzie, dawanie niezweryfikowanej sugestii naprawy; jeśli ponownie się nie powiedzie, zaczyna cyklicznie wyprowadzać przybliżone odpowiedzi. Sposób postępowania GLM-5 jest bardziej zbliżony do doświadczonego architekta. W teście w świecie rzeczywistym, gdy projekt nie mógł zostać uruchomiony z powodu problemów z zależnościami środowiskowymi, nie zatrzymał się na powierzchownych informacjach o błędach, ale aktywnie analizował drzewo zależności (Dependency Tree), oceniał źródło konfliktu i dalej nakazywał OpenClaw naprawę środowiska.

Cały proces bardziej przypomina wdrożenie w stylu „autonomicznej jazdy”: model nie reaguje pasywnie, ale stale odczytuje dzienniki, poprawia ścieżki i weryfikuje wyniki.

Inną często pomijaną, ale niezwykle ważną zdolnością w inżynierii systemów jest integralność kontekstu.

Okienko Token o wartości miliona GLM-5 umożliwia mu zrozumienie struktury kodu, historii modyfikacji, plików konfiguracyjnych i dzienników uruchamiania całego projektu w tym samym kontekście. Oznacza to, że jest już w stanie ocenić z globalnej perspektywy, na które moduły wpłynie modyfikacja. W zadaniach o długiej ścieżce ta zdolność bezpośrednio decyduje o tym, czy model jest „inteligentny, ale krótkowzroczny”, czy „stabilny i kontrolowany”.

Podsumowując, GLM-5 naprawdę przejmuje rolę „architekta”, głównie dlatego, że zaczyna myśleć o problemach jak architekt: najpierw planuj, potem wykonuj; stale weryfikuj, stale poprawiaj; koncentruj się na całym systemie, a nie na pojedynczym sukcesie.

To jest również podstawowy powód, dla którego jest w stanie ukończyć te zadania testowe na poziomie systemu w pierwszej części.

03

Opus w świecie open source?

Patrząc na ekosystem dużych modeli w 2026 roku, wartość GLM-5 polega bardziej na tym, że przełamuje coś, co wcześniej było prawie domyślnie akceptowane: inteligencja na poziomie systemu wydaje się istnieć tylko w modelach zamkniętych.

Wcześniej Claude Opus 4.6 i GPT-5.3 rzeczywiście przeszły drogę „Agentic Coding” – model nie dąży już do natychmiastowego sprzężenia zwrotnego, ale poprzez planowanie, dekompozycję i powtarzane uruchamianie, realizuje naprawdę złożone zadania inżynieryjne. Ale cena jest również wysoka: zużycie Tokenów w zadaniach o wysokiej intensywności jest niezwykle wysokie, a pełna próba na poziomie systemu często oznacza znaczne koszty wywołania.

GLM-5 oferuje tutaj inne rozwiązanie. Jako model open source, przenosi „AI na poziomie architekta systemu” z chmury i rachunków z powrotem do własnego środowiska programistów. Możesz wdrożyć go lokalnie, aby poświęcił czas na gryzienie tych brudnych, żmudnych i dużych zadań: dostosowywanie dzienników, sprawdzanie zależności, modyfikowanie starego kodu i uzupełnianie warunków brzegowych.

Można to postrzegać jako strukturalną zmianę opłacalności – inteligencja na poziomie architekta nie jest już przywilejem nielicznych zespołów.

Jeśli użyjemy metafory zawodowej, aby zrozumieć tę różnicę, będzie to bardziej intuicyjne. Modele takie jak Kimi 2.5 bardziej przypominają doskonałych inżynierów front-end, którzy są estetyczni i mają silne poczucie interakcji, dobrze radzą sobie z generowaniem One-shot, prezentacją wizualną i szybkim sprzężeniem zwrotnym; podczas gdy styl GLM-5 jest wyraźnie inny, bardziej przypomina doświadczonego architekta systemu, który przestrzega zasad, przywiązuje wagę do logiki: koncentruje się na relacjach między modułami, ścieżkach wyjątków, możliwości konserwacji i długoterminowej stabilnej pracy.

Za tym kryje się w rzeczywistości jasny postęp zawodowy w programowaniu AI – od dążenia do „wyglądającego fajnie” Vibe Coding do podkreślania solidności i dyscypliny inżynieryjnej.

Co ważniejsze, pojawienie się GLM-5 sprawia, że koncepcja firmy jednoosobowej staje się bardziej realna.Gdy programista może mieć lokalnie partnera AI, który rozumie projektowanie systemów, może działać długoterminowo i może się sam korygować, wiele prac inżynieryjnych, które pierwotnie wymagały zespołu, zaczyna być kompresowanych do zakresu kontrolowanego przez jedną osobę. W przyszłości GLM-5 ma potencjał, aby stać się "cyfrowym partnerem" w jednoosobowej firmie, odpowiedzialnym za realizację kluczowych projektów inżynieryjnych.