Otevřený svět má svůj Opus moment: Dokáže GLM-5 převzít štafetu Agentic Codingu?

Pokud se zeptáte vývojáře, co je na AI programování nejvíce frustrující?

Odpověď bude pravděpodobně mechanické „Omlouvám se, špatně jsem to pochopil“ před chybou, následované opakováním stejného chybného kódu.

V uplynulém roce se pokrok u velkých jazykových modelů pro kódování projevil spíše v „generativních schopnostech“: generování webových stránek, komponent nebo malých her jedním příkazem – vytvoření pixelové webové stránky, skvělé SVG ikony nebo hratelného hada za 15 sekund. Tyto ukázky jsou dostatečně úžasné, ale také dostatečně „lehké“, připomínají spíše pokročilé hračky vytvořené v éře Vibe Codingu (programování s atmosférou). Ale když dojde na vysoce souběžnou architekturu, adaptaci ovladačů na nízké úrovni nebo složité refaktoringy systémů, stanou se z nich „skleníkové květiny“.

Proto se v Silicon Valley v poslední době mění směr.

Ať už jde o Claude Opus 4.6 nebo GPT-5.3, tyto špičkové velké jazykové modely začínají klást důraz na Agentic Coding: nesnaží se o „okamžité výsledky“, ale spíše o dokončení systémových úkolů prostřednictvím plánování, dekompozice a opakovaného spouštění.

Tento posun paradigmatu od „front-endové estetiky“ k „systémovému inženýrství“ byl dříve považován za monopol uzavřených gigantů. Teprve když jsem otestoval GLM-5, jsem si uvědomil, že „éra architektů“ v komunitě s otevřeným zdrojovým kódem začala dříve.

***01***

**Od „front-endu“ k „systémovému inženýrství“**

Když se dříve mluvilo o AI Codingu, většinou se myslelo na známý narativ – generování webové stránky jedním příkazem, vytvoření malé hry za minutu, vytvoření skvělého dynamického efektu za deset sekund. Zdůrazňovaly „vizuální požitek“: tlačítka se hýbou, stránka vypadá dobře, efekty jsou bohaté.

Ale ti, kteří skutečně vstoupili na staveniště, vědí, že vytvoření dema neznamená, že dokážete podepřít systém.

Obtížnost složitých úkolů nespočívá v „psaní kódu“, ale v tom, jak rozdělit moduly, jak spravovat stavy, jak se vypořádat s výjimkami, jak optimalizovat výkon a zda si systém dokáže udržet strukturální stabilitu, když se začne komplikovat.

To je také důvod, proč jsme si vybrali složité úkoly jako testovací objekty.

Pozice GLM-5 se liší od mnoha konkurenčních produktů.

Pokud je většina modelů spíše jako „vynikající front-end“ – umí rychle generovat interaktivní rozhraní a vizuální efekty, pak GLM-5 je spíše „systémový inženýr“. Klade důraz na spolupráci více modulů, dlouhé řetězce úkolů a strukturální stabilitu, která je spustitelná v produkčním prostředí.

Abychom to ověřili, navrhli jsme dva testovací případy zcela odlišných dimenzí.

První test, zdánlivě snadný, ale ve skutečnosti vysoce systematický úkol – vytvořit interaktivní hru s tématem jarních svátků „AI vizuální ovládání ohňostroje gesty“ založenou na prohlížeči a kameře.

Ve videu z testování je vidět, že uživatel stojí před kamerou a gesty ovládá směr a rytmus odpalování ohňostroje; ohňostroj kvete ve vzduchu, doprovázený částicovými efekty a dynamickou světelnou odezvou, celková interakce je plynulá a přirozená.

Nejedná se však o jednoduchý front-endový dynamický efektový projekt. Obsahuje alespoň několik klíčových modulů: rozpoznávání gest a zpracování vizuálního vstupu; mapování souřadnic gest na logiku odpalování; částicový systém ohňostroje a efekty kvetení; vykreslování v reálném čase a řízení snímkové frekvence; kompatibilita prohlížeče a zpracování výjimek oprávnění kamery; správa interakčních stavů a mechanismus zpětné vazby uživatele.

Dá se říci, že se jedná o malý interaktivní systém s kompletní strukturou a plynulým zážitkem. Z procesu testování je vidět, že GLM-5 nevstoupil přímo do kódování, ale nejprve naplánoval celkovou architekturu: jak oddělit modul vizuálního vstupu, řídicí logickou vrstvu, vykreslovací vrstvu a efektovou vrstvu; jak přenášet datový tok; které části se mohou stát úzkými hrdly výkonu.

Následně postupně implementoval logiku, počínaje zpracováním dat rozpoznávání gest, přes výpočet trajektorie odpalování až po doladění parametrů efektu výbuchu částic.

Když se vykreslování zaseklo, aktivně navrhl snížit počet částic a optimalizovat strukturu cyklu; když rozpoznávání gest selhalo, upravil prahové hodnoty a strategie filtrování.

Efekt prezentovaný ve videu je „interakce, která vypadá velmi přirozeně“. Ale to, co se skrývá za tím, je kompletní inženýrský řetězec: plánování → psaní → ladění → optimalizace výkonu → korekce interakce.

Výsledný kód lze spustit přímo, interakce je stabilní, snímková frekvence je plynulá a lze zpracovat výjimečné situace. Důležitější je, že jeho pracovní metoda vykazuje jasné systémové myšlení: hranice modulů jsou jasné, logické vrstvení je rozumné, místo aby se všechny funkce hromadily v jednom souboru.

Druhý případ testuje schopnost strukturálního systému. Tento scénář lze označit za každodenní práci médií – importovat přepis rozhovoru, shrnout obsah a vygenerovat úhly a nápady pro témata.

V testu je vidět, že pracovní postup je velmi přímý: vložil jsem nedávný přepis rozhovoru, model začal analyzovat a následně vygeneroval shrnutí obsahu a úhly témat. Z výsledků je vidět, že úhly témat, které vygeneroval, jsou stále velmi operativní.

Ve srovnání s vizuálním interaktivním systémem se zdá, že organizace nahrávek je jednoduchá, ale ve skutečnosti testuje schopnost modelu „strukturální abstrakce“. Skutečná nahrávka rozhovoru je často vysoce nestrukturovaná: skoky v názorech, opakování informací, prolínání hlavních a vedlejších linií. Takže v tomto případě je schopnost, kterou GLM-5 prokázal, na systémové úrovni.

**Za prvé, schopnost rozpoznávání témat a extrakce hlavních linií.** Model negeneroval shrnutí v pořadí původního textu, ale nejprve určil, jaké jsou hlavní problémy, a poté reorganizoval obsah kolem tohoto problému. To znamená, že interně dokončil skenování, aby identifikoval, které informace patří do hlavní linie a které jsou doplňky nebo šumy. Tato schopnost je v podstatě schopnost plánování, to znamená, že před výstupem nejprve vytvoří abstraktní strukturální rámec.

**Za druhé, schopnost modulární reorganizace.** Seskupí související názory roztroušené v různých odstavcích do stejného modulu. Tato schopnost integrace mezi odstavci ukazuje, že model má globální konzistenci při zpracování dlouhých textů.

**Za třetí, schopnost aktivního úpravy logického pořadí.** Skutečný výstupní návrh se často liší od původního pořadí nahrávky. Je vidět, že GLM-5 má schopnost přeskupit vrstvy podle vztahu příčiny a následku nebo logiky argumentace. To odráží úsudek, že „logika má přednost před původním vstupním pořadím“. Tento režim „nejprve struktura, poté výstup“ je jádrem systémového inženýrství.

Tyto dva případy, jeden je systém vizuální interakce v reálném čase a druhý je systém zpracování struktury mediálních informací, se zdají být zcela odlišné. Ale ověřují stejnou věc – GLM-5 má kompletní schopnost uzavřeného cyklu úkolů: plánování → provedení → ladění → optimalizace.

V ohňostrojové hře se to odráží ve vrstvení modulů, optimalizaci výkonu a zpracování výjimek; v procesoru nahrávek se to odráží v posuzování témat, strukturální dekompozici a logické reorganizaci. Jejich společným bodem je, že model se nezastavil u „generování výsledků“, ale spíše u udržování struktury, která se může udržitelně vyvíjet.

Pokračoval jsem v pokusu s relativně složitým úkolem, „vytvoření minimalistického jádra operačního systému“. V tomto testu je skutečně pozoruhodné to, že kód ve videu nakonec běží, ale spíše chování GLM-5 v celém procesu.

Po obdržení úkolu nevstoupil okamžitě do stavu generování, ale nejprve objasnil hranice úkolu, aktivně rozdělil moduly, naplánoval strukturu systému a poté vstoupil do fáze implementace. Tato cesta „struktura na prvním místě“ je v podstatě inženýrské myšlení, o kterém jsem mluvil dříve – nejprve definujte, jak je systém složen, a poté diskutujte o konkrétních detailech implementace, místo abyste psali a skládali dohromady.

V cyklu vícenásobného psaní, spouštění, chyb a oprav se GLM-5 také nedočkal strukturálního kolapsu. Každá úprava se točila kolem zavedené architektury, místo aby ji zrušila a začala znovu nebo lokálně opravovala. To ukazuje, že interně udržuje kompletní systémový model, který je schopen udržet konzistenci v dlouhých řetězcích úkolů. Mnoho modelů má tendenci být po prodloužení kontextu rozporuplných, zatímco chování ve videu přesně odráží jeho schopnost trvalé paměti celkové struktury.

A také způsob, jakým zpracovává chyby. Když se objeví chyba, nezastaví se u povrchové spekulace, že „možná je problém v řádku kódu“, ale nejprve posoudí typ chyby, rozliší logické problémy, problémy s prostředím nebo konflikty závislostí a poté naplánuje cestu pro odstraňování problémů. Jedná se o ladění na úrovni strategie, jehož cílem je opravit cestu k problému.

Pokud se podíváte na volání nástrojů, tato schopnost bude ještě zřetelnější. Nejenže dává návrhy příkazů, ale také kombinuje aktivní plánování spouštění terminálu, analýzu protokolů, opravu prostředí a poté pokračuje v postupu úkolu. Toto chování se již blíží „autonomnímu řízení“ inženýrského postupu. Dokud není cíl dokončen, pokračuje v iteraci.

Nejprve plánování a poté provedení, udržování strukturální stability v dlouhých řetězcích, odstraňování problémů strategickým způsobem a pokračování v postupu kolem cíle – kombinace čtyř klíčových schopností potřebných pro systémové inženýrství umožňuje GLM-5 začít vykazovat vzorce chování, které se blíží způsobu práce inženýra.

**Proč může GLM-5 převzít štafetu „architekta“?**

Pokud první část testu prokázala, že GLM-5 „dokáže dělat složitou práci“, pak další otázka zní: **Proč to dokáže?** Odpověď spočívá v celé sadě „inženýrských vzorců chování“ skrytých za výstupem.

Klíčovým bodem je, že GLM-5 zjevně zavedl mechanismus sebeověřování myšlenkového řetězce podobný Claude Opus 4.6.

Při skutečném používání můžete cítit, že po obdržení úkolu nezačne okamžitě „vyplňovat kód“, ale provádí v zákulisí vícenásobné logické odvození: předvídá vztahy vazby mezi moduly, aktivně se vyhýbá cestám nekonečné smyčky a předem zjišťuje konflikty zdrojů a problémy s okrajovými podmínkami. Přímou změnou, kterou toto chování přináší, je – aby se zajistilo, že řešení obstojí v inženýrství, **je ochoten zpomalit a promyslet problém úplně**.

Ve složitých úkolech GLM-5 nejprve poskytne jasnou dekompozici modulů: ze kterých podmodulů se systém skládá, jaké jsou vstupy a výstupy každého modulu, které části lze provádět paralelně a které musí být dokončeny sériově. Poté je postupně překonává, místo aby psal a přemýšlel současně. Díky tomu se jeho pracovní metoda více podobá skutečnému inženýrovi: **nejprve nakreslete architektonický diagram a poté napište detaily implementace**.

Je zřejmé, že má „odolnost, aby nepřestal, dokud problém nevyřeší čistě“, místo aby spěšně skončil po dokončení zdánlivě správné části.

Tento rozdíl je zvláště patrný ve srovnání s tradičními modely kódování. V minulosti, když se mnoho modelů setkalo s chybou, rychle sklouzlo do známého režimu: omluva, opakování chybové zprávy, poskytnutí neověřeného návrhu opravy; pokud znovu selže, začne cyklicky vypisovat podobné odpovědi. Způsob, jakým GLM-5 zpracovává, je bližší starším architektům. V testu, když projekt nemohl běžet kvůli problémům se závislostmi prostředí, nezastavil se u povrchových chybových zpráv, ale aktivně analyzoval strom závislostí (Dependency Tree), určil zdroj konfliktu a dále nařídil OpenClaw provést opravu prostředí.

Celý proces se více podobá nasazení ve stylu „autonomního řízení“: model nereaguje pasivně, ale neustále čte protokoly, opravuje cesty a ověřuje výsledky.

Další schopnost, která je často přehlížena, ale je nesmírně důležitá v systémovém inženýrství, je integrita kontextu.

Okno GLM-5 s milionem tokenů mu umožňuje porozumět struktuře kódu, historii úprav, konfiguračním souborům a provozním protokolům celého projektu ve stejném kontextu. To znamená, že je již schopen posoudit z globálního pohledu, které moduly budou ovlivněny kaskádovými reakcemi jedné úpravy. V dlouhých řetězcích úkolů tato schopnost přímo určuje, zda je model „chytrý, ale krátkozraký“ nebo „stabilní a kontrolovatelný“.

Celkově vzato, GLM-5 skutečně převzal roli „architekta“ hlavně proto, že **začal přemýšlet o problémech jako architekt**: nejprve plánování, poté provedení; neustálé ověřování, neustálé opravy; zaměření na celkový systém, nikoli na jediný bod úspěchu.

To je také hlavní důvod, proč dokázal dokončit ty systémové testovací úkoly v první části.

***03***

**Opus otevřeného světa?**

Při pohledu na ekosystém velkých jazykových modelů v roce 2026 spočívá hodnota GLM-5 spíše v tom, že prolomil něco, co bylo dříve téměř implicitně přijímáno: inteligence na systémové úrovni se zdá být možná pouze v uzavřených modelech.

Dříve Claude Opus 4.6 a GPT-5.3 skutečně prošly cestou „Agentic Coding“ – model se již nesnaží o okamžitou zpětnou vazbu, ale spíše o dokončení skutečně složitých inženýrských úkolů prostřednictvím plánování, dekompozice a opakovaného spouštění. Ale cena je také vysoká: spotřeba tokenů u úkolů s vysokou intenzitou je extrémně vysoká a jeden kompletní pokus na systémové úrovni často znamená značné náklady na volání.

GLM-5 zde nabízí jiné řešení. Jako model s otevřeným zdrojovým kódem přináší „AI na úrovni systémového architekta“ z cloudu a účtů zpět do vlastního prostředí vývojáře. Můžete jej nasadit lokálně a nechat jej, aby si udělal čas na to, aby se prokousal těmi špinavými, únavnými a velkými pracemi: ladění protokolů, kontrola závislostí, úprava starého kódu, doplnění okrajových podmínek.

To lze považovat za strukturální změnu nákladové efektivity – inteligence na úrovni architekta již není privilegiem několika týmů.

Pokud bychom tento rozdíl chápali pomocí profesní metafory, bylo by to intuitivnější. Modely jako Kimi 2.5 jsou spíše jako vynikající front-endoví inženýři s online estetikou a silným smyslem pro interakci, kteří se specializují na generování One-shot, vizuální prezentaci a rychlou zpětnou vazbu; zatímco styl GLM-5 je zjevně odlišný, je spíše jako zkušený systémový architekt, který dodržuje spodní hranici a klade důraz na logiku: zaměřuje se na vztahy modulů, výjimečné cesty, udržovatelnost a dlouhodobý stabilní provoz.

Za tím se skrývá jasný profesní postup programovací AI – od snahy o Vibe Coding, který „vypadá skvěle“, k inženýrství, které klade důraz na robustnost a inženýrskou disciplínu.

Důležitější je, že výskyt GLM-5 činí koncept společnosti jednoho člověka reálnějším.

Když má vývojář lokálně AI partnera, který rozumí návrhu systému, dokáže dlouhodobě fungovat a sám se opravovat, mnoho inženýrských prací, které dříve vyžadovaly tým, se začíná zmenšovat do rozsahu, který může ovládat jednotlivec. Následně má GLM-5 potenciál stát se "digitálním partnerem" v jednočlenné společnosti, který je zodpovědný za implementaci klíčových inženýrských řešení.