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 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: bugfixy 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. Tohle je ta nejpodceňovanější část. Smyčka bez ověření není agent, je to generátor diffů.

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.

3. Postav zpětnou vazbu dřív, než ji budeš potřebovat. Minimální sada: testy spustitelné jedním příkazem, lint, typová kontrola. 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. Konečné stadium — agent běžící bez dozoru nad celou úlohou — si nech jen pro úlohy, kde máš silnou automatickou verifikaci.

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á? To první ti řekne, kde rozšířit autonomii, to druhé, co přidat do instrukčního souboru.

Č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.
• 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.

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.
• 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. A zlaté pravidlo platí pořád: nekupuj delší prompt, kupuj rychlejší zpětnou vazbu.