Proč někdy coding agent působí geniálně a proč dobré vlákno nezahazuji

Typická situace vypadá takto: coding agent opraví jednu chybu, všimne si vedlejší závislosti, doplní test a při další změně už sám respektuje hranice modulu. Po několika úkolech působí, jako by konkrétní aplikaci skutečně pochopil. Pak otevřete nové vlákno se stejným repozitářem a podobným zadáním; a tentýž nástroj začne řešit symptom, přehlédne konvenci nebo navrhne změnu, kterou jste v předchozí relaci nemuseli vůbec vysvětlovat.

V takové chvíli je lákavé říct, že jste dostali „lepší model“. Nemám pro to důkaz. Uživatel nevidí do routingu, konfigurace ani případných produktových experimentů služby a stejný rozdíl může vzniknout i náhodností generování, prvním krokem agenta, stavem nástrojů nebo kvalitou kontextu, který se během práce nahromadil. Z jednoho povedeného vlákna proto nelze poctivě odvodit, co přesně se na straně služby stalo.

Pro práci vývojáře však přesná příčina není první otázkou. Důležité je, že kvalita coding agenta není jen vlastností názvu modelu. Vzniká také z aktuální relace: z přečtených souborů, zvolených nástrojů, oprav, které jste odmítli, a prvních rozhodnutí, jež nasměrovala všechny další kroky. Když tato kombinace opakovaně funguje, nezahazuji ji jen kvůli zvyku začínat každý ticket v novém vlákně.

Stejný model neznamená stejnou pracovní trajektorii

Generativní modely nejsou ve výchozím nastavení deterministické. OpenAI uvádí, že stejné požadavky mohou vytvářet různé výstupy; Anthropic obdobně upozorňuje, že ani nulová teplota negarantuje totožnou odpověď. U coding agenta se rozdíl ještě násobí tím, že každý první krok mění další prostředí práce.

Agent, který jako první otevře správný konfigurační soubor, spustí relevantní test a správně pojmenuje hranici modulu, se vydá jinou cestou než agent, který začne lokální úpravou symptomu. Po několika krocích už nejde jen o dvě různá znění odpovědi. Jde o dvě odlišné pracovní trajektorie s jinými předpoklady, přečtenými soubory, výsledky nástrojů a opravami.

Kontext není historie chatu. Je to rozpracovaný stav systému

Codex i Claude Code umožňují rozpracovanou relaci obnovit a oba nástroje pracují s kompresí dlouhého kontextu. To není pouze uživatelské pohodlí. Relace obsahuje informace, které nemusí být nikde jinde pohromadě: co už agent přečetl, které konvence pochopil, jaké opravy jste odmítli, které testy selhaly a jaké kompromisy jste společně přijali.

Nové vlákno může dostat stejný repozitář a stejný úkol, ale nedostane automaticky stejnou interpretaci. Ztrácí drobná rozhodnutí a korekce, které z agenta postupně vytvořily užitečného spolupracovníka pro konkrétní část systému.

Když agent funguje, přidávejte navazující práci

V praxi proto sleduji nikoliv jednu efektní odpověď, ale několik znaků stabilně dobré práce. Agent zachovává architektonický styl, sám kontroluje dopady do sousedních modulů, nespokojí se s průchodem jednoho testu, umí vysvětlit riziko změny a při opravě nevytváří další lokální výjimku.

Když se tyto znaky opakují, dávám do stejné relace další úkoly ze stejné oblasti: další endpoint, související migraci, doplnění testů, kontrolu logování nebo refaktor stejného modulu. Nejde o pověru, že relace má „dobrou náladu“. Jde o využití už získaného kontextu a ověřené pracovní trajektorie.

Dobré vlákno není důvod pokračovat navždy

Dlouhý kontext se časem komprimuje a může začít obsahovat zastaralé cíle, slepé cesty nebo mnoho nesouvisejících detailů. Anthropic proto doporučuje mezi nesouvisejícími úkoly kontext vyčistit; současně umožňuje relaci pojmenovat, obnovit nebo rozvětvit. Codex obdobně podporuje návrat k uložené relaci.

Relaci ukončuji nebo větvím, když agent opakovaně vrací starý předpoklad, plete dva cíle, začíná opravovat vlastní předchozí workaroundy, zbytečně rozšiřuje scope nebo když se práce přesouvá do jiné části systému s jinými pravidly. Správné pravidlo tedy není „jedno vlákno na celý projekt“. Je jím „nezahazovat produktivní kontext bez důvodu“.

Jak si produktivní relaci pojistit

• Vytvořte Git checkpoint po každé stabilní etapě a uložte stav testů.
• Požádejte agenta o stručný handover: architektonické předpoklady, provedené změny, otevřená rizika a další doporučený krok.
• Pro alternativní řešení raději relaci rozvětvěte, než abyste zničili funkční směr práce.
• Při přechodu na nesouvisející úkol založte čistý kontext a přeneste pouze ověřené závěry.
• Výkon neposuzujte podle dojmu. Sledujte průchod testů, množství oprav po review, počet porušených konvencí a čas k přijatelnému diffu.

Pozorování lze ověřit

Tuto hypotézu lze ve firmě otestovat bez spekulace o interním fungování dodavatele. Vyberte sadu podobných úloh a porovnejte nové relace s pokračováním úspěšné relace. Měřte první průchod testy, počet korekcí, porušení architektonických pravidel, dobu do review a podíl akceptovaného diffu. Teprve potom lze říct, zda pokračování dobrého kontextu ve vašem prostředí skutečně přináší hodnotu.

Z mého pozorování zatím plyne střízlivý závěr: není prokázané, že uživatel narazil na tajně lepší model. Je ale dobře možné, že narazil na mimořádně dobrou kombinaci generování, kontextu a prvních rozhodnutí. Z provozního pohledu je rozumné tuto kombinaci nezahodit.