Coding agents — když model sahá do repa

Zlaté pravidlo: Agent je přesně tak dobrý, jak rychle pozná, že se mýlí. Neinvestuj do delších promptů, investuj do zpětné vazby — testy, lint, typy, CI, sim a spustitelné příklady jsou pro agenta smysly. Bez nich koduje poslepu a ty to zjistíš až v review.

Kdy tohle potřebuješ

Coding agent se ti vyplatí ve chvíli, kdy máš víc dobře popsatelné práce než rukou: bug fixy s jasnou reprodukcí, testy k dopsání, migrace „udělej totéž na 40 místech“, prototyp, který chceš do večera, refactor se záchrannou sítí testů. Nevyplatí se tam, kde sám nevíš, co chceš — agent nejasné zadání nezpřesní, jen ho rychleji a sebevědoměji špatně implementuje.

Pro představu o tempu: na SWE-bench Verified (reálné GitHub issues z open-source projektů) řeší nejlepší modely přes 70 % úloh a podle měření METR se délka úloh, které agenti zvládají samostatně, zhruba každého půl roku zdvojnásobuje. To není důvod k panice ani k euforii. Je to důvod naučit se s nimi pracovat dřív, než se to naučí konkurence.

Jak to doopravdy funguje

Coding agent je smyčka: přečti kontext → navrhni změnu → proveď ji → spusť něco, co změnu ověří → interpretuj výsledek → opakuj. Model v ní není orákulum, je to řidič.

Kvalita výsledku stojí na třech věcech:

1. Kontext — co agent vidí: soubory, dokumentaci, konvence projektu, chybové hlášky. Kontextové okno je omezené, takže agent neustále rozhoduje, co číst a co ignorovat. Projekt, ve kterém se dá zorientovat (čitelná struktura, README, konvence), je projekt, ve kterém agent dělá méně škody.
2. Nástroje — co agent smí: číst soubory, editovat, pouštět příkazy, hledat. Tady vzniká většina rizik. Agent s právem spouštět cokoliv je agent, který ti někdy spustí cokoliv.
3. Zpětná vazba — jak agent pozná úspěch: exit code testů, výstup lintru, chyba typového systému, screenshot, CI, simulator. Tohle je ta nejpodceňovanější část. Smyčka bez ověření není agent, je to generátor diffů.

Closed-loop: verifikace je infrastruktura, ne afterthought

Nejčastější chyba firem kolem coding agentů není „špatný model“. Je to underinvestment do verifikace. One-shot generování kódu (napiš PR a člověk to doladí) dává krátkodobý pocit rychlosti a dlouhodobě frontu review, která se neškáluje.

Closed-loop znamená: agent dostane úkol, rozloží ho, udělá práci a bez člověka v každém kroku projde smyčkou ověření (testy, CI, build, sim, lint). Člověk vstupuje na hranicích: zadání, riskantní rozhodnutí, finální merge u kritických změn. Ne jako „last-mile editor“ u každého diffu.

V praxi to není trade-off „rychlost vs. kvalita“. Rychlost agentů je zakódovaná kvalita: testy, skills, CLAUDE.md / AGENTS.md, MCP nástroje, konzistentní konvence. Co nejde spustit automaticky, nejde škálovat přes background agenty ani automerge.

Co z toho plyne pro tým

• Silná test automation dřív než fleet agentů. Automerge a background jobs dávají smysl jen tam, kde komponenty přežijí automatické změny.
• Verification loop jako produktová infrastruktura. Stejně jako CI pro lidi: jeden příkaz, deterministický signál pass/fail, logy, které agent umí číst.
• Konzistentní codebase. Monorepo s jednotnými vzory agentům sedí; deset stylů v jednom ekosystému je zmatek v kontextu, ne „diverzita“.
• Ownership po komponentech. Jasný vlastník = jasné, kdo drží testy a kdo schvaluje výjimky.

Případ: Spotify × Claude Code (closed-loop ve velkém)

V rozhovoru tvůrce Claude Code Borise Chernyho se Spotify Chief Engineerem (interní systém Honk) zaznívá stejná teze na enterprise škále:

• Deterministické AST/script migrace napříč tisíci repy narazily na obří API surface a edge casy.
• Early LLM one-shot nefungoval. Postupně přišla dekompozice, iterace a judge vrstva.
• S judge vrstvou šla úspěšnost PR zhruba z ~20–30 % na ~80 %. U silnějších modelů (éra Opus 4.5) judge jako samostatnou vrstvu zase odstranili: model + silná verifikace v CI stačily víc.
• Dnešní tvar: Claude Agent SDK v K8s, tools, CI buildy Linux + macOS, iOS simulator / UI flowy. Honk už není jen batch migrace, ale ubiquitní agent tooling (včetně Slack úkolů a background běhů).
• Org signály ze stejného callu (orientačně, z rozhovoru): tisíce engineerů, tisíce deployů denně, výrazný nárůst frekvence PR a podíl AI-authored PR v desítkách procent. ROI dřív „obvious“; další tvrdé měření má jít z PR → work item → A/B → user value a cost accounting tokenů.

Pointa není „buďte jako Spotify“. Pointa je: škála agentů stojí na smyčce, kterou umíš měřit, ne na delším promptu v IDE.

Postup: jak agenta zapojit, krok za krokem

1. Začni na úlohách s jasnou definicí hotovo. Failing test, konkrétní bug s reprodukcí, endpoint podle vzoru vedlejšího endpointu. Čím líp jde výsledek ověřit příkazem, tím dřív se chyba ukáže. Vyhni se zprvu úlohám typu „zrefaktoruj architekturu“ — to je seniorní práce i pro člověka.

2. Dej projektu instrukční soubor (CLAUDE.md, AGENTS.md — podle nástroje). Patří tam: jak se spouští testy a lint, konvence, kterých se držet, co se nesmí (např. „nikdy nesahej na migrace bez ptaní“), známé pasti projektu. Piš ho jako onboarding pro nového kolegu, který má dokonalou paměť na to, co mu napíšeš, a nulovou na to, co mu řekneš ústně. A udržuj ho: pokaždé, když agent udělá chybu, kterou šlo popsat dopředu, přidej řádek. To není dokumentace navíc. Je to zakódovaná kvalita, kterou agent umí použít ve smyčce.

3. Postav zpětnou vazbu dřív, než ji budeš potřebovat. Minimální sada: testy spustitelné jedním příkazem, lint, typová kontrola. U UI přidej screenshot diff nebo sim. Pokud projekt nic z toho nemá, nech agenta nejdřív dopsat testy k existujícímu chování — to je mimochodem skvělá první úloha.

4. U větších úloh chtěj nejdřív plán, ne kód. Nech agenta prozkoumat repo a popsat, co a kde změní. Plán zkontroluj — chyba v plánu se opravuje větou, chyba v hotovém kódu hodinou. Teprve pak ho pusť implementovat.

5. Čti diffy, ne reporty. Agent ti vždycky řekne, že je hotovo a všechno funguje. To není lhaní, to je optimismus. Věř výstupu testů a vlastním očím na diffu. Hlídej hlavně: tiché „opravy“ testů, aby prošly; spolknuté výjimky; zahardcodované hodnoty tam, kde měla být logika.

6. Autonomii rozšiřuj postupně. Začni v režimu, kdy agent žádá o potvrzení každé akce. Až si ověříš, že na daném typu úloh nedělá hlouposti, povol mu víc. Background agent a automerge si nech jen pro úlohy se silnou automatickou verifikací a jasným blast radius.

7. Měř to. Po pár týdnech se podívej: kolik PR od agenta prošlo bez přepisování? Kde opakovaně selhává? Jaká je PR success rate před a po judge/CI krocích? To první ti řekne, kde rozšířit autonomii, to druhé, co přidat do instrukčního souboru a do test harnessu.

Časté chyby a jak je opravit

• Vágní zadání („zlepši performance“) → dej cíl a metriku: „endpoint /search odpovídá nad 800 ms, dostaň ho pod 200 ms, profiluj nejdřív“.
• Agent bez testů → nejdřív testy, pak feature. Jinak dostaneš kód, který „vypadá správně“, což je nejdražší druh špatného kódu.
• One-shot mindset → vyžaduj smyčku: implementace + spuštění verifikace + další pokus. Jednorázový diff bez pass/fail signálu není hotová práce.
• Mega-úloha v jednom kuse → krájej na kroky ověřitelné zvlášť. Agent, kterému utíká kontext uprostřed velké úlohy, začne improvizovat.
• Slepá důvěra v „hotovo, funguje“ → spusť testy sám, přečti diff. Pravidlo zní: důvěřuj, ale verifikuj, přičemž „důvěřuj“ je v té větě navíc.
• Opravování agenta donekonečna v chatu → když se třikrát točíš na tomtéž, zahoď konverzaci, zpřesni zadání a začni čistě. Dlouhá konverzace plná slepých uliček je zaneřáděný kontext.
• Jeden velký PR týdně → menší PR častěji. Úzkým hrdlem procesu je lidská pozornost při review, ne rychlost generování kódu.
• Deset stylů v jednom monorepu → sjednoť patterns, tooling a naming dřív, než nasadíš fleet agentů. Inconsistency bolí lidi; agenty zabíjí.

Kdy to nepoužívat

Když neumíš popsat, jak poznáš, že je úloha hotová. Když je kód kritický a nemá verifikaci (platby, migrace ostrých dat, bezpečnostní logika) — tam agent smí maximálně navrhovat, ne provádět. A když se učíš novou technologii: nech si od agenta vysvětlovat a ukazovat, ale piš sám, jinak se nenaučíš poznat, kdy ti lže.

Knihy a zdroje

• Building effective agents (Anthropic) — základní text o agentních smyčkách a o tom, proč jednoduché vzory porážejí složité frameworky. Krátké, hutné, zdarma.
• Claude Code: Best practices for agentic coding (Anthropic) — konkrétní pracovní postupy: instrukční soubory, plánování před kódem, práce s testy. Většina rad platí pro libovolný coding agent.
• Boris Cherny × Spotify: closed-loop AI coding — rozhovor o verification loops, Honk a proč one-shot nestačí. Primární signál k sekci closed-loop výše.
• AI Engineering (Chip Huyen, O'Reilly 2025) — nejlepší ucelená kniha o stavbě aplikací nad foundation modely: evaluace, RAG, agenti, latence a náklady. Pokud máš přečíst jednu knihu, tak tuhle.
• A Philosophy of Software Design (John Ousterhout) — není o AI, a právě proto: malé moduly, čistá rozhraní a nízká komplexita jsou přesně to, co dělá kód „agent-friendly“. Klasika, která s nástupem agentů získala druhý dech.
• SWE-bench — benchmark, kterým se měří coding agenti na reálných GitHub issues. Hodí se znát, když čteš marketingová čísla.
• METR — výzkum měřící, jak dlouhé úlohy agenti zvládají autonomně. Nejstřízlivější data o tempu pokroku, co najdeš.
• Blog Simona Willisona — průběžně nejpoctivější praktické zápisky o práci s LLM a agenty. Žádný hype, samé experimenty.

Co si pamatovat

Coding agent je násobič tvého inženýrského procesu. Projekt s testy, malými úlohami a jasnými konvencemi zrychlí; projekt bez hranic jen rychleji zaplaví dluhem. Smyčka je jednoduchá: ohraničená úloha → plán → implementace s verifikací → tvoje review na hranicích. Closed-loop bez silné verifikace je jen drahý generátor diffů. A zlaté pravidlo platí pořád: nekupuj delší prompt, kupuj rychlejší zpětnou vazbu.