Nechte AI dělat výzkum, zatímco spíte

Když říkám, že se v AI mění situace každým týdnem, tak to není v nadsázce. Je to pár týdnů, co vyšel OpenClaw, a dnes ho už někteří berou jako standardní návrhový vzor (třeba Nvidia a jejic Nemoclaw)…

Šestého března, tedy před 12 dny, zveřejnil Andrej Karpathy repo s názvem autoresearch a k němu napsal tuto větu: „Svého času dělal výzkum umělé inteligence masový počítač mezi jídlem, spánkem a občasnou zábavou, a občas se synchronizoval pomocí zvukových vln na rituálu zvaném ‘skupinová porada’. Ta éra je dávno pryč.”

Je to nadsázka, ale jádro je reálné. Karpathy předtavil systém, ve kterém AI agent autonomně modifikuje tréninkový kód, spouští experimenty, měří výsledky a rozhoduje, co si ponechat a co zahodit, a to bez jediného zásahu člověka. Vy jdete klidně spát, ráno se vzbudíte a máte ke kávě log se stovkou provedených experimentů.

Tento článek rozebírá, jak to funguje, jak Rastislav “Rasty” Turek tento přístup upravil pro programování a jak z toho lze sestavit obecnou šablonu použitelnou pro vlastní projekty.

Anderj Karpathy řešil optimalizaci ML, tedy strojového učení. Kdo to zkoušel, tak ví, že to je činnost plná laborování s parametry a hledání optimálního výsledku, který vyvažuje rychlost, přesnost a velikost.

Jeho repo je malé, obsahuje v zásadě tři hlavní soubory, které na sobě závisí:

prepare.py je neměnný tréninkový skript. Stahuje tréninková data, trénuje BPE tokenizér, obsahuje dataloader a evaluační funkci. Tento soubor agent nesmí upravovat.

train.py je jediný soubor, který agent smí měnit. Obsahuje GPT model, optimizér (Muon + AdamW) a trénovací smyčku. Vše je otevřené: architektura, hyperparametry, batch size, hloubka sítě.

program.md je instrukce pro agenta. Karpathy ho nazývá “velmi odlehčeným skillem”. Technicky jde o Markdown soubor, který Claude Code načte do kontextu na začátku sezení.

Metriku tvoří val_bpb, validační bity na bajt. Nižší je lepší, a protože je nezávislá na velikosti slovníku, umožňuje souměřitelné srovnání experimentů s různými architekturami. Každý trénink trvá přesně pět minut. Pevný časový rámec je klíčové rozhodnutí: nezáleží, co agent změní, model bude vždy trénovat stejně dlouho.

Smyčka vypadá takto: agent přečte aktuální train.py, vymyslí úpravu, zapíše ji, spustí trénink přes uv run train.py > run.log 2>&1, přečte výsledek přes grep "^val_bpb:" run.log, porovná s předchozím nejlepším výsledkem, a buď si commit ponechá, nebo provede git reset. Pak zapíše řádek do results.tsv a začne znovu.

Zásadní instrukce v program.md zní: NEVER STOP. Agent nesmí uprostřed smyčky zastavit a ptát se, zda má pokračovat. Uživatel může být pryč od počítače, může spát. Pokud dojdou nápady, agent se má zamyslet hlouběji. Musí si znovu přečíst soubory, zkusit kombinace předchozích experimentů, sáhnout po radikálnějších změnách. Smyčka běží, dokud ji člověk ručně nezastaví.

Karpathy do instrukce zakomponoval méně zřejmé, ale důležité pravidlo: metrika nestačí. Zlepšení o 0,001 val_bpb za cenu dvaceti řádků upraveného kódu nestojí za to. Zlepšení o nulu, ale s jednodušším kódem, stojí za to vždy. Smazání funkce se stejným nebo lepším výsledkem znamená úsporu, tedy úspěch. Agent tedy neoptimalizuje pouze jednu metriku; optimalizuje poměr zisku vůči přidané složitosti.

Karpathyho smyčka (modifikuj, změř, ponech nebo zahoď, opakuj) silně připomíná přístup, který v počítačové vědě existuje od devadesátých let: genetické programování.

Klasické genetické programování (GP) pracuje s populací řešení reprezentovaných jako stromy nebo programy. V každé generaci se hodnotí schopnost každého jedince (jak dobře řeší daný problém), selektují se nejlepší, a na ně se aplikují dva operátory: mutace (náhodná změna části programu) a křížení (výměna podstromů mezi dvěma jedinci). Výsledkem je nová generace, která je statisticky o něco lepší než předchozí. Proces se opakuje, dokud schopnost nedosáhne požadované hodnoty nebo nevyprší výpočetní rozpočet. GP takto dokázalo syntetizovat třídící algoritmy, elektrické obvody nebo řídící logiku robotů, aniž by člověk napsal jediný řádek kódu výsledného programu.

Paralela s autoresearch je reálná: fitness funkce (val_bpb nebo testy), selekční tlak (keep/discard), iterativní prohledávání prostoru řešení, žádný lidský zásah v každém kroku. Ale jsou tu tři podstatné rozdíly.

Populace versus jedinec. Klasické GP hodnotí desítky nebo stovky řešení paralelně a čerpá různorodost právě z jejich vzájemného křížení. Autoresearch pracuje s populací velikosti jedna: jeden experiment, ponechat nebo zahodit, další. Žádné křížení. Je to spíš evoluce se sofistikovaným operátorem mutace než plnohodnotné GP.

Slepá versus informovaná mutace. V klasickém GP je mutace záměrně náhodná: překlopí náhodný bit, vymění náhodný podstrom. Informace o tom, proč změna pomohla nebo uškodila, se do dalšího kroku nepřenáší jinak než přes selekci. V autoresearch je “mutace” LLM, který kód chápe. Agent nehází náhodnou kostkou. Formuluje hypotézu, implementuje ji cíleně, a v dalším experimentu na výsledek navazuje. To je kvalitativně jiný operátor: místo náhodného prohledávání jde o informované prohledávání, založené na znalosti problematiky.

Paměť. GP populace si “pamatuje” úspěšné vzory nepřímo, přes selekci jedinců. Autoresearch si je pamatuje explicitně - v results.tsv a session.md jsou záznamy všech experimentů, které agent čte a z nichž vyvozuje, co má smysl zkoušet dál.

Dalo by se říct, že autoresearch je GP, kde mutační operátor má doktorát z oboru a zápisník plný poznámek. Rastyho rozšíření na tři týmy pak přidává další paralelu: červený tým jako evaluační fáze (identifikace problémů) a zelený jako aplikační fáze (opravy) vzdáleně připomínají oddělení fitness evaluace od reprodukce v klasickém GP. Ale stále bez populace a křížení.

Pokud by někdo chtěl jít skutečně blíže ke klasickému GP, logickým rozšířením by byly paralelní větve - více agentů experimentuje souběžně, každý na vlastní větvi, a koordinátor selektuje nejlepší výsledky, případně „kříží” nápady mezi větvemi. To by byl autentický evoluční algoritmus s LLM jako mutačním operátorem. Zatím to nikdo nepostavil - nebo aspoň nezveřejnil.

Spuštění je jednoduché. Otevřete Claude Code v adresáři s projektem, zakážete všechna oprávnění mimo čtení a spouštění skriptů, a napíšete:

Podívej se na program.md a zahajme nový experiment. Nejdřív setup.

Agent přečte program.md, navrhne tag pro větev (například mar17), vytvoří větev autoresearch/mar17, přečte prepare.py a train.py, ověří, že existují datové soubory v cache, a spustí první experiment. Od té chvíle pracuje sám.

Za několik hodin najdete v results.tsv přehled experimentů:

commit   val_bpb   memory_gb   status    description
a1b2c3d  0.9979    44.0        keep      baseline
b2c3d4e  0.9932    44.2        keep      increase LR to 0.04
c3d4e5f  1.0050    44.0        discard   switch to GeLU activation
d4e5f6g  0.0000     0.0        crash     double model width (OOM)

Každý záznam má commit hash, dosaženou metriku, spotřebu paměti, stav (keep/discard/crash) a popis toho, co bylo vyzkoušeno.

Rastislav Turek vzal Karpathyho myšlenku a rozšířil ji. Místo ML tréninku cílí na libovolný programátorský projekt. Místo numerické metriky používá testy, to je metrika, jejíž výsledek rozhoduje o úspěchu. A místo jednoho agenta nasazuje tři nezávislé týmy s řízeným tokem informací mezi nimi.

Princip informačních bariér je podstatný. Každý tým dostane jiný kontext a záměrně neví, co dělaly ostatní týmy.

Červený tým prochází kódovou základnu a píše zprávu o nálezech - chyby, chybějící testy, výkonnostní problémy, bezpečnostní mezery. Nic nemodifikuje. Výstupem je strukturovaná zpráva s přesnou lokací každého nálezu (soubor, číslo řádku), popisem problému a dopadem.

Koordinátor (to je samotný Claude Code) přečte zprávu červeného týmu a před předáním zelenému týmu ji sanitizuje. Odstraní metodologii (tedy informaci o tom, jak byl problém nalezen), případné návrhy oprav, komentáře k návrhu kódu. Zelený tým dostane pouze fakta: co, kde, dopad. Nic víc.

Proč? Protože pokud zelený tým ví, jak červený k nálezu dospěl, přebírá jeho úhel pohledu. Záměrnou neznalostí kontextu se zvyšuje šance, že problém vyřeší jiným způsobem, nebo odhalí, že ho nelze reprodukovat.

Zelený tým pak opravuje nálezy jeden po druhém. Po každé opravě spustí testy. Pokud testy neprojdou, vrátí změnu a nález přeskočí. Každý commit má přesný popis opravy.

Tým pro refaktorizaci dostane kód v aktuálním stavu, po opravách zeleného týmu, ale bez jakéhokoli vědomí o tom, co bylo nalezeno nebo opraveno. Vybere tři až pět nejvýnosnějších zjednodušení, zkusí je a po každém spustí testy.

Koordinátor na konci každého cyklu ověří výsledky testů, zapíše resumé do session logu a spustí další cyklus. Pokud testy po refaktorizaci přestanou procházet, vrátí commity refaktorizačního týmu, pak případně i zeleného týmu, a pokračuje dál.

Sám Rasty uvádí, že v projektu v Go s 25.000 řádky vyprodukovalo pět cyklů 49 commitů: 31 oprav chyb (z toho 8 rozbíjelo klíčovou funkcionalitu), 6 nových testovacích sad, 5 optimalizací odstraňujících vzor N+1 dotazů, a přibližně 100 řádků mrtvého kódu.

Spuštění v Claude Code je přes slash command:

/autoresearch ~/cesta/k/projektu

Koordinátor detekuje stack (Go, Node, Rust, Python, Ruby a další), najde příkaz pro spuštění testů, vytvoří větev autoresearch/improve a spustí cykly. Po přerušení lze pokračovat přes:

/autoresearch resume

Autoresearch funguje nejlépe tam, kde existuje spolehlivá zpětná vazba. U ML tréninku je to numerická metrika. U kódové základny jsou to testy. Čím lepší pokrytí, tím cennější výstupy - zelený tým může po každé opravě skutečně ověřit, že nic nerozbil.

Projekty s nízkým pokrytím dostávají méně hodnoty. Červený tým najde problémy, ale zelený nemá jak ověřit opravy a bude přeskakovat více nálezů. U takových projektů červený tým typicky označí chybějící testy jako prioritu a po několika cyklech pokrytí naroste.

Velká monorepa s desítkami tisíc souborů je rozumné omezit konfiguračními vzory include/exclude, aby se týmy soustředily na relevantní část kódu a nepálily kontext na nepodstatné soubory.

Není to nástroj pro architekturální přepisy. Zelený tým opravuje konkrétní chyby na konkrétních řádcích a záměrně minimalizuje rozsah změn. Pokud projekt potřebuje přepsat z monolitu na mikroslužby, autoresearch k tomu není vhodný. Pokud má spousta chyb, chybějící testy a nedůsledné zpracování chyb, je to přesně jeho doménа.

Z obou přístupů lze sestavit doménově nezávislou šablonu použitelnou pro libovolný iterativní proces s měřitelným výsledkem. Tady je popis jejích funkčních bloků a důvody, proč jsou navrženy takto.