Když chytrý AI nástroj selhává z hloupých důvodů

Existuje specifický typ frustrace, který přichází, když sledujete inteligentní systém padat kvůli stupidním příčinám. Zažil jsem to nedávno, když jsem experimentoval s lokálními AI coding agenty — trendem, který sílí s tím, jak se open-weight modely zlepšují a roste důraz na soukromí při vývoji.

Experiment byl prostý: dokáže coding agent běžící výhradně na lokálním hardware postavit funkční hru? Ne nějakou triviální demo verzi, ale něco se skutečnou správou stavu, renderovací logikou, zpracováním vstupů a hratelným rozhraním. Odpověď, po značném škrábání se na hlavě, zní ano — ale dostat se tam odhalilo kategorii problémů, se kterou si ekosystém AI nástrojů neví moc rady.

Konfigurace, která měla fungovat

Stack se skládal ze tří komponent reprezentujících špičku lokálního AI vývoje: provider-agnostický coding agent CLI, Ollama servírující OpenAI-kompatibilní API z localhostu, a Qwen3.8 27B běžící na lokálním stroji. Pro představu — není to žádné poddimenzované uspořádání. 27B model při velikosti 17 GB se pohodlně vejde do 32 GB unified memory a podporuje tool calling se slušnými reasoning schopnostmi.

Počáteční výsledky byly slibné. Do patnácti minut agent vytvořil kompletní HTML strukturu a téměř 200 řádků NES-stylového CSS s fazetovanými efekty a správnou barevnou paletou. Ještě působivější bylo, že agent během procesu sám zachytil vlastní chybu: zapsal soubor, přečetl si ho, všiml se nesouladu mezi tím, co zamýšlel, a tím, co skončilo na disku, a opravil to bez vyzvání. To je autentické agentické chování, které naznačovalo, že model úkol zvládne.

Pak se ale agent pokusil napsat soubor s herní logikou, a vše se zastavilo.

Spirála smrti

Následovala sekvence, kterou každý, kdo se potýkal s AI toolingem, pozná. Třináct po sobě jdoucích pokusů o zápis herního engine souboru, každý ukončený uprostřed generování. Stream jednoduše zemřel — žádná chyba, žádné vysvětlení, žádný použitelný výstup.

Nejvíce frustrující nebyla samotná chyba, ale sledování reasoning procesu agenta. Protože každý pokus začínal znovu od nuly, model pokaždé odvozoval stejná designová rozhodnutí znovu a pokaždé skončil u jinýchscoring tabulek a implementačních přístupů. Tři pokusy znamenaly tři různé odpovědi na stejnou architektonickou otázku. Agent strávil hodinu přemýšlením a nevyexpedoval nic.

Zjevný viník se zdál být jasný — paměťový tlak. Zavření záložek prohlížeče uvolnilo několik gigabajtů RAM a věci se trochu zlepšily, což diagnózu zdánlivě potvrdilo. Ale to byla špatná lekce.

Co ve skutečnosti odhalily logy

Návrat k serverovým logům vyprávěl úplně jiný příběh. V žádném z nich nebyla jediná chyba out-of-memory. Volná systémová paměť se pohodlně držela mezi 21 a 27 gigabajty po celou dobu, přičemž model zabíral 17 GB. Paměť nikdy nebyla problém.

Skutečný problém byla konfigurační nesoulad, který neprodukoval žádnou viditelnou chybu. Konfigurace agenta inzerovala 32 768-tokenový context window. Ale Ollama server byl restartován s 8 192-tokenovým stropem, a tento nesoulad zůstal neodhalen. Agent spokojeně plánoval 800-řádkový soubor napsat najednou, protože podle svých informací měl k dispozici 32k prostoru. Když generování narazilo na 8k zeď uprostřed tool callu, spojení bylo přerušeno bez chybové zprávy, kterou by agent mohl analyzovat.

Vedlejší komplikace se skrývala ve startovacích logách: Ollama se spustila s povoleným context shiftingem, což by umožnilo oknu klouzat, když by došlo místo — starší tokeny by se obětovaly ve prospěch nových. Ale architektura modelu tuto funkci nepodporovala, takže byla tiše deaktivována. Co mělo být měkkým limitem, se stalo tvrdou zdí.

DevOps disciplína, kterou AI vývoj vyžaduje

Tato zkušenost krystalizuje něco důležitého o lokálním AI vývoji, co nadšení kolem open-weight modelů tends zakrýt. Když provozujete modely na vlastním hardware, nejen píšete kód — provozujete infrastrukturu. A infrastruktura vyžaduje stejnou diagnostickou disciplínu, správu konfigurace a pozornost k operačním parametrům jako produkční systémy.

Context windows nejsou abstraktní vlastnosti modelu k nastavení a zapomenutí. Jsou to operační parametry, které interagují s vaším tool chainem nečekanými způsoby. Když nakonfigurovaný context agenta neodpovídá skutečnému stropu serveru, nedostanete varování — dostanete tichá selhání, která vypadají jako neschopnost modelu, přestože ve skutečnosti jde o operační miskonfiguraci.

Praktické ponaučení pro vývojáře zkoumající lokální AI coding agenty je přímočaré: validujte své prostředí stejně důkladně jako produkční nasazení. Kontrolujte, že konfigurace agenta odpovídá runtime parametrům. Čtěte serverové logy, ne jen výstup agenta. Rozumějte tomu, jaké funkce vaše architektura modelu skutečně podporuje versus co tooling pouze zkouší aktivovat.

Modely se zlepšují. Tooling dospívá. Ale propast mezi "funguje v demo verzích" a "funguje spolehlivě při dennodenním používání" stále vyžaduje lidský úsudek k překlenutí — a ten úsudek vypadá hodně jako tradiční DevOps disciplína aplikovaná na novou kategorii infrastruktury.

Tetris build nakonec uspěl. Trvalo to čtyři a půl hodiny rozložené do dvou dnů, vyprodukoval čistý kód ve třech souborech a funguje správně. Ale lekce nepřišly ze succès, ale z pochopení, proč selhání nastala — a z rozpoznání, že někdy jsou nejdražší problémy zcela nesouvisející s inteligencí.