Rituál zná každý, kdo si někdy zkusil postavit aplikaci s pomocí umělé inteligence. Popíšete, co chcete, model něco vyrobí, vypadá to skvěle — dokud to nespustíte. Napíšete, co je špatně, jedna věc se opraví a dvě další se rozbijí. Po čtyřech hodinách sedíte u něčeho rozbitějšího než na začátku a jste o čtyři hodiny starší. Závěr, že na tohle umělá inteligence zatím nestačí, býval rozumný a správný. Jenom už neplatí — a nejde o zásluhu nového modelu.
Zadání experimentu bylo jednoduché: nadiktovat aplikaci pro silový trénink, která se v čase učí a reaguje na spánek, stres i vytíženost, spustit proces a odejít. Za tři dny stála hotová databáze, výpočetní engine, rozhraní i aplikace v telefonu — otestované, ověřené a uložené. Bez jediného ručně napsaného řádku kódu.
Chytřejší model práci prodlouží, ze smyčky ale nevyvede
Intuice, že na zaseknutou práci stačí sáhnout po chytřejším modelu, má za sebou tvrdá data. Organizace METR měří takzvaný časový horizont agentů — jak dlouhou práci, vyjádřenou časem zkušeného člověka, dokáže agent dokončit alespoň v polovině případů. Na sadě převážně softwarových a výzkumných úloh se tento horizont od roku 2019 zdvojnásoboval zhruba každých sedm měsíců.
Chytřejší modely tedy skutečně a měřitelně dotahují delší práci než dřív. Přesto dokážou skončit v přesně té smyčce, kterou znáte z vlastního programování s modelem po ruce. Jenom jsou v ní vytrvalejší, protože na to mají nervy.
Agent, který čtyřistakrát klikl na nefunkční tlačítko
Ukázkový případ: agent dostane relativně obyčejný úkol v analyzátoru síťového provozu Wireshark. Otevře správné dialogové okno, klikne na tlačítko OK, nic se nestane. Klikne znovu, zase nic. Do vlastního záznamu si přitom poznamená, že tlačítko OK na kliknutí nereaguje — takže o problému ví. A pak klikne znovu a znovu a znovu, přes čtyři stovky marných kroků, o kterých má černé na bílém, že k ničemu nevedou. Skončí, teprve když mu dojde rozpočet.
Dělat pořád totéž a čekat jiný výsledek je doslova definice šílenství. A je to přesně ta lidská čtyřhodinová smyčka — jenom bez člověka, který ji po třech pokusech vzdá. Agent selhání vidí, ale nedokáže ho převést do stavu, na který by další krok musel reagovat. Nešlo přitom o slabý model: běh probíhal na silném modelu z řady Qwen skrze Claude Code.
Aplikace, která jednoduše neexistuje
Motivace celého pokusu byla praktická. Chybí aplikace, která inteligentně poradí, kolik váhy si naložit na činku — ne podle předem definovaného plánu, ale podle toho, v jakém stavu je člověk zrovna dnes. Vedle klasických empirických výpočtů by měla brát v úvahu kalendář a volný čas, kvalitu spánku, předchozí dny, energii, stres i náladu. A nejen to, jestli se předchozí den cvičilo, ale třeba i to, jestli se místo toho několik hodin sedělo v autě.
Něco podobného už existovalo jako soukromé workflow se skripty. Cílem ale byla skutečná přenositelná aplikace, do které se přihlásí další lidé se svými daty, cíli, kalendářem a podmínkami. Právě to je typ nástroje, který nejen optimalizuje trénink, ale díky ohledu na náladu ho dělá i příjemnějším a dlouhodobě udržitelnějším. A postavit se to mělo jedním zadáním: kliknout, spustit, odejít a vrátit se k hotové otestované aplikaci.
Jeden papír na práci i na evidenci o práci
Běžná agentní smyčka drží v jedné rostoucí historii dvě zcela odlišné věci: samotnou práci a evidenci o tom, co už je hotové. Představte si nákupní seznam, na který si zároveň zapisujete každou uličku, do níž jste vešli, každou věc, kterou jste nenašli, i každý neúspěšný pokus. U deseti položek to zvládnete. U dvou set už z papíru nepoznáte, co ještě sháníte a co dávno leží v košíku.
Z toho plynou dva problémy. První je změřený a říká se mu context rot: čím delší historie je, tím méně spolehlivě z ní model vytahuje podstatné. Laboratoř Chroma testovala osmnáct modelů při rostoucí délce vstupu a při stejné obtížnosti úlohy pozorovala stále méně spolehlivý výkon. Jednotlivé modely se chovaly různě, společný závěr byl ale jasný — milion tokenů není milion stejně spolehlivých tokenů.
Druhý problém je horší: agent si sám dává známky. Chyba v jednom kroku ještě není katastrofa, katastrofou je chyba v evidenci o tom kroku. Jakmile si agent napíše hotovo, všechny další kroky z toho vycházejí jako z ověřeného faktu. Stavíte další patro na základech, o kterých si někdo omylem poznamenal, že už ztvrdly. Přesně tady vzniká ten okamžik, kdy oprava jedné věci rozbije dvě další.
Vlastní chybu model nepojmenuje, cizí ano
Nabízí se otázka, proč si model historii prostě znovu nepřečte a chybu si neopraví sám. Protože vlastní chybu velmi často spolehlivě nepojmenuje — a existují na to experimenty. Výzkumníci vzali chybné tvrzení, vyloženě nesmysl, a měnili jen roli, pod kterou se modelu zobrazil: jednou jako jeho vlastní tvrzení, podruhé jako úvahu přicházející zvenčí. V deseti ze třinácti modelových konfigurací byl rozdíl statisticky vysoce významný. Míra, s jakou model chybu explicitně pojmenoval a odmítl, vyskočila u nálepky „zvenčí“ o 23 až 93 procentních bodů. Stejná chyba, stejný model, jiná nálepka o původu.
Je to totéž jako číst desetkrát vlastní e-mail bez povšimnutí překlepu, který kolega najde na první pohled. Neznamená to, že věta „zkontroluj si to po sobě“ nemůže nikdy pomoci — znamená to, že se za ni nedá postavit spolehlivý kontrolní systém. Pokud stavíte něco, kde záleží na spolehlivosti, je mnohem lepší mít dva různé modely, které se navzájem kontrolují, než jeden model kontrolující sám sebe. Model totiž do jisté míry rozpozná vlastnosti textu, které prozrazují, že ho psal on sám nebo stejný model — podobně jako člověk po půl roce pozná svůj vlastní styl. Nechat výstup ověřit v novém chatu téhož modelu proto nestačí.
Long Horizon Harness: hotový rámec místo domácího lepení
Framework, kvůli kterému celé video vzniklo, se jmenuje Long Horizon Harness. Zveřejnil ho tým z Alibaby a celý projekt je dostupný zdarma pod otevřenou licencí MIT. Nejdůležitější je hned zkraje: základ té architektury si už nemusíte stavět sami. Dřív bylo nutné podobné smyčky navrhnout, slepit a celé večery ladit. Tohle je hotový doplněk pro Claude Code nebo Codex — nainstalujete ho, nastavíte pro svůj projekt a on převezme dlouhé plánování, předávání stavu i opakovanou kontrolu.
Základní myšlenka je prostá. Dlouhý úkol není jen problém myšlení, je to primárně problém správy stavu.
Manažer, vykonavatel, auditor — tři role bez společné historie
Řešením je rozdělit práci mezi tři role, které nikdy nesdílejí jednu rostoucí pracovní historii. Manažer drží stav a rozhoduje, co se bude dělat dál — a přitom nemá vůbec žádný přístup k počítači. Nevidí soubory, nespustí příkazy, neotevře okna. Rozhoduje výhradně podle toho, co mu napsali auditoři.
Vykonavatel dostane jeden ohraničený úkol a úplně čerstvý kontext, jako když na směnu nastoupí někdo nový, kdo nezná slepé uličky předchozího kolegy. Když skončí, jeho pracovní historie se zahodí a dál jde jen report o tom, co údajně udělal. To „údajně“ je klíčové, protože pak přichází auditor. Ten také začíná s čistým kontextem, nevidí, jak vykonavatel před ním uvažoval, a report bere jen jako tvrzení — musí se podívat, co se v počítači doopravdy změnilo.
Jedno kolečko tedy vypadá takto: manažer řekne, co se má udělat, vykonavatel to provede a odevzdá report, auditor nezávisle zkontroluje skutečné soubory, logy nebo stav aplikace a napíše vlastní zprávu. Teprve podle ní manažer aktualizuje oficiální stav a rozhodne, co dál. Kolo se opakuje pořád dokola, v popisovaném nastavení nejvýše čtyřicetkrát — strop počtu iterací je volitelný. Role, kterou v nekonečném večeru zastával člověk — hlídat postup, rozpoznat selhání, zadat další krok — se rozdělila mezi manažera a auditora. Auditor navíc dostává výsledek jako cizí práci, ne jako pokračování vlastní úvahy, což je přesně ten efekt z experimentu s přeznačenými chybami.
Hotovo se zapíše jedině na slovo auditora
Celé to drží pohromadě jedno pravidlo: tvrzení vykonavatele nemá právo zápisu do oficiálního stavu. Představte si předělávku koupelny. Obkladač řekne, že je hotovo, a na první pohled to tak vypadá — jenže o výsledku nerozhoduje on. Přijde někdo, kdo u práce celý den nebyl a neslyšel žádné povídačky o křivé zdi, vylije na podlahu kbelík vody a sleduje, kam teče. Zaťuká na kachličky, zkontroluje rovné stěny. Žádné pocity, žádné výmluvy, žádná odůvodnění. Do papírů se hotovo napíše jedině tehdy, když auditor řekne, že je všechno v pořádku.
V účetnictví to funguje stejně: kdo provádí platbu, ten ji neschvaluje. Ti tři agenti tedy nespolupracují tím, že by si navzájem věřili. Spolupracují tím, že si nevěří ani slovo.
Dva různé modely mají méně společných slepých míst
Autoři frameworku používají pro manažera, vykonavatele i auditora standardně jeden a tentýž model — naměřené zlepšení tedy nevzniklo tím, že by audit obstarávala chytřejší umělá inteligence. V popisovaném běhu přesto přibyla ještě jedna pojistka: kód psal ChatGPT a kontroloval ho Claude. Není prokázané, že je to vždycky lepší, šlo o snahu ještě o kousek snížit šanci, že vykonavatel a auditor budou mít stejná slepá místa.
Pořád platí, že čím lepší zadání, tím lepší výsledek. Na rozdíl od jediného modelu si ale tenhle postup podstatně lépe poradí i se situací, kdy některé věci v zadání nejsou úplně přesné. Důvod je jednoduchý: tři modely pracují nezávisle a každý se může naplno soustředit na svou část problému. Nemusí zároveň promýšlet celý postup, kontrolovat sám sebe a řešit ostatní části úkolu — a fokusovaný úkol dopadne lépe i u modelu, který dokáže přemýšlet libovolně dlouho.
Patnáct nadpisů v LibreOffice: rozdíl mezi vypadá dobře a je hotovo
Krásně je to vidět na jedné úloze ze studie, která framework představila. Zadání znělo naformátovat v LibreOffice patnáct nadpisů předepsaným stylem. Běžný agent si práci zjednodušil — program obešel, otevřel podkladové XML a soubor přepsal přímo. Dokument se otevřel a na první pohled vypadal správně, jenže skóre bylo nula. Zadání totiž neříkalo jen, jak má výsledek vypadat, ale také že změna musí proběhnout přes LibreOffice.
S Long Horizon Harness vykonavatel všechno naklikal a auditor pak rozebral výsledný soubor a ověřil, že všech patnáct nadpisů má správný podkladový styl. Skóre vyskočilo na 0,89. Rozdíl tedy nespočíval ve vzhledu výsledku, ale v pracovním postupu a v tom, kdo má právo výsledek schválit. A ten agent s nefunkčním tlačítkem ve Wiresharku? Se stejným modelem, ale novou smyčkou se skóre téže úlohy zvedlo z 0,59 na 0,92 — z poloviny cesty na téměř hotovo.
Není to zázrak: kde organizace pomůže a kde ne
Zázrak ani zjevení to není. Základní schopnosti modelu se nemění. Je to podstatně dražší na tokeny i na limity v tarifu, protože ověřování je drahé. A není to všespásné: tam, kde je úzkým hrdlem vidění, matematika nebo algoritmus, pomůže lepší organizace práce podstatně méně. Největší smysl dává tam, kde je problémem vytrvalost, koordinace a ověřování.
Není to ani objev z čistého nebe. Anthropic už v listopadu 2025 popsal příbuzný postup pro dlouhé běhy — seznam funkcí, průběžné poznámky, čerstvé kontexty, testování, gitové checkpointy. Long Horizon Harness k tomu přidává tvrdší oddělení pravomocí: vykonavatel nemůže sám přepnout oficiální stav na hotovo a režim auditora pouze pro čtení se nevynucuje slibem, ale kontrolou stavu celého prostředí. Není to revoluce, je to postupný pokrok — zato pořádný, hlavně kvůli tomu zjednodušení.
Tři tisíce řádků přípravy, které nepsal člověk
Než vznikl první řádek produkčního kódu, bylo na světě přes tři tisíce řádků přípravy: rozbor zadání, analýza tréninkového zápisníku, rozhodnutí omezit se na osm fázových kontraktů a osm dokumentů, ve kterých je napsáno, co přesně znamená hotovo a jak se to pozná. Zní to jako noční můra, jenže tu přípravu nepsal člověk.
Vznikla z konverzace. Nadiktovaný byl jen záměr — mluvená a dost neuspořádaná verze toho, co má vzniknout. Model to rozebral na sedm oddělitelných systémů a ověřil technické předpoklady proti realitě. Tři představy opravil hned: že rozhraní pro zdravotní data nefunguje tak, jak se čekalo, že jedna ze služeb změnila přístup k tokenům a že hrudní pás Polar pro daný účel žádnou aplikaci nepotřebuje. Pak prošel skutečný zápisník a našel v něm vzorce, které původní zadání změnily. Na druhé straně zbylo jen odpovídání na otázky.
Není to tak úplně klasické stavění aplikace pouhým popovídáním si s modelem. Pořád jde o tvorbu specifikace, jenom se nepíše na klávesnici, ale diktuje se. Jdete se na hodinu projít se psem, vymýšlíte si, co byste chtěli, a potom zodpovíte kanonádu otázek, které pro vás model připraví.
Co vzniklo za tři dny
Nejdřív se z ručně psaného zápisníku — poznámek v telefonu plných zkratek, překlepů a různých způsobů zápisu — stala databáze. Pak vznikl výpočetní engine, který rozhoduje, kolik kilogramů si příště naložit, a nad ním vrstva, jež do doporučení zapojuje spánek a zotavení. Následovalo rozhraní, přes které se celý systém ovládá konverzací, a nakonec aplikace do telefonu. Osm fází, každá s vlastním kontraktem, dohromady stovky automatizovaných testů.
Čtyři zádrhely, které vyřešil dohled sám
Long Horizon Harness funguje jako doplněk napojený přímo do Claude Code nebo Codexu. Hodinový monolog s popisem celého zadání proto slouží hlavně jako základ pro to prostředí. Claude Code samotnou práci nedělá — jen spustí harness, sleduje jeho průběh a případně zasáhne. Právě proto je úvodní dlouhá konverzace důležitá: když harness někde uvízne nebo neví, jak pokračovat, nadřazený nástroj má dost informací, aby to posunul dál, aniž by kohokoli otravoval.
V běhu byly standardně nasazeny modely od OpenAI a Sonnet 5 od Anthropicu. Když se proces přestal posouvat, měl Claude Code autonomně povoleno přepnout na výkonnější model — a pokud narazil na zacyklení, mohl dokonce upravit zadání pro harness tak, aby dál odpovídalo původním požadavkům, ale umožnilo pokračovat. Úprava za běhu tedy byla možná.
Za celý třídenní běh se práce zasekla čtyřikrát a čtyřikrát to nástroj vyřešil sám, bez jediného lidského zásahu. Poprvé šlo o otázku, jak zacházet se sériemi, ze kterých engine nedokáže odvodit další doporučení — původní kritérium takovou možnost vůbec nepředpokládalo. Podruhé chtěl systém vědět, odkud vzít výchozí tabulku zátěží, protože v datech nového uživatele žádná být nemusí. Třetí případ zůstal nevyjasněný. Počtvrté aplikace dělala správnou věc, ale akceptační podmínka ji vyhodnotila jako chybu — šlo o pauzu, případně o zrušení rozdělaného tréninku. Problém tedy nebyl v programu, ale v zadání. Čtyřikrát systém různými slovy řekl totéž: tvoje definice hotového je vadná. A pokaždé měl pravdu. Kontrola z lidské strany se scvrkla na pár status reportů denně.
Problém není inteligence, ale definice hotového
Tím padá původní omyl. Překážkou dlouhých úkolů není jen inteligence, je jí definice hotového. Model ji může navrhnout, zpřesnit i hledat v ní díry. Nemůže ale spolehlivě znát záměr, který mu nikdo nedal — může vaši definici vybrousit, nemůže ji za vás chtít.
Zbývající lidská práce se tak posouvá jinam: vysnít si do detailu, co má vzniknout, a umět si o to říct. Zbytek už dneska zvládne systém, který si sám na sebe nevěří.
