Když kód píšou agenti, bottleneckem se stává člověk

Před rokem jsem většinu dne strávil psaním kódu. Dnes velkou část implementace odvedou agenti a moje práce se posunula o patro výš: rozhodnout, co se má postavit, jak to má být navržené, a ověřit, jestli to, co přišlo zpátky, obstojí.

Je to práce, kterou umím a která dává mnohem větší páku. Ale je vyčerpávající jinak, než jsem čekal, a chvíli mi trvalo pochopit proč.

Protože mi na to chyběl návod, dohledal jsem, co o tom říkají data a jak si den kolem agentů organizují lidé, kteří v tom jedou naplno. Tohle je z toho výtah.

Co se vlastně změnilo

Programování mělo přirozený rytmus:

napíšu kód → spustím → chyba → přemýšlím → opravím → funguje → další problém

Ta smyčka trvala minuty a měla okamžitou zpětnou vazbu. Zelené testy, funkční endpoint, zmizelý bug.

Velká část dne dnes vypadá spíš takhle:

zadám úkol → čekám → čtu 80 řádků → kontroluju diff → přemýšlím, jestli je to správně
→ řeknu „jo" → čekám → čtu další výstup

Vypadá to podobně, ale je to jiný druh duševní práce. Ubyla aktivní manipulace s problémem. Přibylo číst, chápat, pochybovat a rozhodovat. Tedy zrovna ta část, u které nedostávám průběžně žádné potvrzení, že to jde dobře.

A přidalo se čekání. Když agent deset minut něco implementuje, nemůžu se mezitím pustit do jiné náročné věci, protože za chvíli se musím vrátit. Takže otevřu něco malého. Pak agent skončí, já musím znovu načíst kontext, pochopit, co udělal, zkontrolovat rozhodnutí a určit směr. A zase: Implementing…

Nejde o soustředění. Jde o to, že tenhle režim ho systematicky seká na kusy po deseti minutách. A na to jsem workflow nastavené neměl.

Není to jen můj pocit a už to má jméno

Boston Consulting Group letos zavedla pro tenhle stav termín „AI brain fry". Popisují ho jako kognitivní přetížení z toho, že člověku nezbývá dost pracovní paměti a pozornosti na úkoly a interakce, které řízení AI agentů vyžaduje. Projevuje se mentální mlhou, horším soustředěním a pomalejším rozhodováním.

Z jejich průzkumu (asi 1 500 zaměstnanců napříč obory) mě zaujaly dvě věci. Produktivita roste u prvního a druhého agenta, u třetího slaběji, a od čtvrtého klesá. A lidé, kteří brain fry hlásí, dělají o 39 % víc závažných chyb.

Je to konzultantský průzkum, ne recenzovaný výzkum, takže bych ta čísla nebral jako fyzikální konstantu. Ale ten tvar sedí na to, co pozoruju na sobě i kolem sebe. A hlavně: dává docela dobrý důvod, proč nepouštět agentů co nejvíc.

Posunula se role, ne jen nástroj

Anthropic ve svém 2026 Agentic Coding Trends Report popisuje posun, který na sobě poznávám doslova: taktická práce, tedy psaní, debugování a údržba kódu, přechází na agenty, zatímco člověk se posouvá k architektuře, návrhu systému, koordinaci agentů a hodnocení jejich výstupu.

Je fér dodat, že Anthropic prodává Claude Code, takže je to pohled dodavatele a jde o predikce, ne o měření. Sami to v reportu píšou.

Zajímavější je jejich vlastní číslo: vývojáři používají AI zhruba v 60 % své práce, ale plně delegovat dokážou jen 0 až 20 % úkolů. Zbytek je přesně to, o čem píšu: zadat, počkat, pochopit, rozhodnout.

A pak je tu studie z prosince 2025 s názvem, který to vystihuje líp než celý report: „Professional Software Developers Don't Vibe, They Control". Autoři pozorovali třináct profesionálních vývojářů při práci na vlastních úkolech a doplnili to dotazníkem pro devadesát devět dalších. Zjištění: zkušení vývojáři agentovi nepředají všechno a neodejdou. Používají svoji expertizu právě na kontrolu návrhu, implementace a kvality.

Je to kvalitativní studie na malém vzorku, takže z ní neplyne žádné procento zrychlení. Ale jako popis chování sedí přesně. A je to podle mě ta zásadní dělicí čára mezi „nechal jsem to vygenerovat" a „postavil jsem to s pomocí agentů".

Vznikl nový bottleneck

Dřív to fungovalo takhle:

člověk → pomalu vyrábí kód → počítač rychle ověří

Teď takhle:

AI → rychle vyrábí kód → člověk pomalu chápe a ověřuje

Thoughtworks pro tohle riziko zařadil do dubnového Technology Radaru pojem codebase cognitive debt (kognitivní dluh codebase), rovnou do kategorie „proceed with caution". Popisují ho jako rostoucí mezeru mezi tím, jak systém skutečně funguje, a tím, jak mu tým rozumí. AI mění systém rychleji, než stíhá růst pochopení.

A tady je ta zákeřná část: čím míň systému rozumím, tím hůř dokážu AI řídit. Udržení mentálního modelu není estetika. Je to přímo předpoklad toho, abych poznal, že agent navrhl blbost, dřív než se to dostane do produkce.

Z toho plyne jedna nepříjemná věc. Řešením není pustit pět agentů paralelně. Technicky získám pětinásobnou implementační kapacitu. Prakticky ale získám pětkrát „rozhodni tohle", pětkrát diff, pětkrát návrat do kontextu a pětkrát review.

Místo továrny na software si postavím továrnu na vlastní vyčerpání.

Ještě jedna studie, kterou je potřeba číst opatrně

Nedá mi to nezmínit experiment METR z července 2025. Šestnáct zkušených open-source vývojářů, 246 reálných úkolů na vlastních velkých repozitářích. Výsledek: s AI nástroji byli o 19 % pomalejší.

Nejzajímavější na tom není to číslo. Je to tohle: předem čekali zrychlení o 24 % a i po skončení experimentu si mysleli, že jim AI pomohla o 20 %. Byli pomalejší a nevěděli o tom.

Než z toho někdo udělá argument proti AI, tři výhrady. Testoval se Cursor s Claude 3.5 a 3.7, což jsou dnes starožitnosti. METR sám výsledek označil za zastaralý. A když se v únoru 2026 pokusili experiment zopakovat, narazili na problém, který je sám o sobě výmluvný: rostoucí část vývojářů odmítá účast, protože nejsou ochotní pracovat bez AI. Nová data naznačují zrychlení, ale statisticky průkazná nejsou.

Beru si z toho jediné, zato důležité: mezi „mám pocit, že jsem rychlejší" a „jsem rychlejší" je větší mezera, než bych čekal. Platí to oběma směry a je to dobrý důvod měřit výsledek, ne dojem.

Jak to řeší ostatní

Tohle mě zajímalo nejvíc. Mezi lidmi jedoucími Claude Code, Codex nebo Cursor agentně se opakuje několik konkrétních věcí a dá se to shrnout do jednoho principu:

Člověk nemá sledovat práci agenta. Má navrhnout systém, ve kterém agent přinese hotový, ověřitelný výsledek.

Tedy míň prompt → koukám → odpovím → koukám → opravuju a víc specifikace → delegace → agent pracuje sám → automatické testy → review → hotovo.

Konkrétně:

1. Nekoukat agentovi pod ruce. Zadat větší, dobře ohraničený úkol a přepnout jinam. Zadání musí být takové, aby se agent nemusel každých pět minut ptát. Je to největší změna oproti „pair programmingu s AI", na který jsme si zvykli.

2. Oddělit dispatch a review. Místo zadám → čekám → čtu → zadám → čekám → čtu spíš zadám A → zadám B → jiná práce → review A → review B. Z interaktivního chatu se stane fronta práce, kterou odbavím v jednom soustředěném bloku.

3. Pouštět víc agentů, ale na nezávislé věci. Jeden na backend, druhý na testy, třetí na analýzu jiného ticketu. Nejde o to mít jich deset. Ve chvíli, kdy všichni začnou současně chtít review, je bottleneckem člověk. (Viz to číslo od BCG o čtvrtém agentovi.)

4. Nutit agenta k self-review před předáním. Konec úkolu není „hotovo", ale: spusť testy, lint a typecheck, projdi vlastní diff, hledej regresní rizika a teprve pak mi shrň, cos změnil a kde potřebuješ moje rozhodnutí. Nudnou část review tak udělá první AI nebo druhý agent.

Ideální předání nevypadá jako 800 řádků kódu k přečtení, ale takhle:

Implementováno X.
Změněny komponenty A/B/C.
Rozhodl jsem Y kvůli Z.
Přidal jsem 14 testů, všechny procházejí.
Typecheck a lint OK.
Tady jsou 2 místa, která potřebují tvoje rozhodnutí.
Tady je diff.

Pak je moje práce rozhodování, ne archeologie.

5. Nečíst všechno stejně pozorně. Tohle je asi nejtěžší přerod. Kontrola se přesouvá z „přečtu každý řádek" na „ověřím chování, architekturu, riziková místa a testy". Diff se pořád používá, ale pozornost nemůže být rozdělená rovnoměrně mezi všech 700 změněných řádků. Musí být koncentrovaná tam, kde se dá něco pokazit doopravdy.

6. Držet úkoly ve správné velikosti. „Udělej celý nový billing" je moc velké na kontrolu. „Přejmenuj tuhle metodu" je tak malé, že budu celý den obsluhovat agenta. Dobrá jednotka je něco, co agent dotáhne samostatně do testovatelného výsledku.

7. Nevyplňovat čekání jinou rozpracovanou prací. Na dobu, kdy agent běží, se berou věci, které jdou bezpečně přerušit a nemají vlastní rozpracovaný stav: mail, triage úkolů, dokumentace, příprava dalších zadání. A když agent běží dvě minuty, klidně nic. Snaha vyplnit každých devadesát sekund produktivitou vyjde dráž, než se zdá.

A je tu ještě druhý tábor, který mi přijde poctivý: někteří vývojáři záměrně nemaximalizují AI throughput. Mají jednoho agenta, dají mu úkol a mezitím dělají něco jiného. Zjistili, že řízení pěti paralelních agentů je sice produktivnější na počet commitů, ale subjektivně je to strašná práce.

Jak to dělám já

Nesnažím se obnovit starý způsob práce. Naučit se osm hodin disciplinovaně moderovat agenty mi přijde jako špatný cíl.

Přesnější je připustit, že se mi kus profese posunul. V části práce jsem technický vedoucí týmu velmi rychlých juniorů, kteří nikdy nespí a každých deset minut chtějí rozhodnutí. Kód pořád píšu, hlavně tam, kde jde o návrh a citlivá místa. Ale těžiště se přesunulo k tomu, co má vzniknout a jestli to, co vzniklo, obstojí.

Ze všech těch bodů jsem si zatím vzal tři a jedu je asi měsíc:

Dva stavy dne místo jednoho. Dispatch: mám dvě až tři jasně definované věci a pošlu je agentům. Review: neřeším nic nového, beru hotové výsledky jeden po druhém, pochopit → zkontrolovat → rozhodnout → merge nebo vrátit. Zní to banálně, ale odstranilo to největší otravnost, tedy neustálé přepínání mezi zadáváním a kontrolou.

Definition of done píšu do zadání, ne až do review. Konkrétně: co má vzniknout, co musí projít, co má agent zkontrolovat sám, než mi to předá. Většina mého dřívějšího review byla práce, kterou jsem měl zadat.

Během čekání nesahám na další rozpracovanou věc. Na tomhle jsem se spálil nejvíc. Vypadá logicky vyplnit čekání jiným úkolem, jenže tím držím v hlavě dva nedokončené kontexty naráz. Agent se ozve, já musím ten druhý odložit, načíst zpátky první, udělat review a vrátit se. Po pár takových přepnutích pořádně nevím ani v jednom, kde jsem skončil. Dneska si na tu dobu beru jen práci, která nemá vlastní rozpracovaný stav.

Co jsem naopak nezkoušel: pět paralelních agentů. Po tom, co jsem se dočetl u BCG, na to nespěchám. A upřímně mi vyšlo, že mým limitem není implementační kapacita, ale to, kolik rozhodnutí za den udělám dobře.

To je asi nejužitečnější věc, kterou jsem si z toho odnesl. Mým výsledkem už není jen napsaný kód. Je jím i dobré rozhodnutí a schválená změna. Zní to samozřejmě. Zkuste si to ale říct v pátek večer, když se díváte na den plný rozhodnutí a málo viditelného výstupu.

Kde to podle mě je

Jsme ve zvláštním přechodném období. Umíme generovat software rychleji, než jsme se naučili to generování řídit. Nástroje se za dva roky zlepšily o řád, pracovní návyky kolem nich skoro vůbec.

Zajímavá otázka už dneska není, jestli AI umí napsat kód. Umí. Otázka je, jak si nastavit práci tak, aby ten kód byl pořád něčí odpovědnost a někdo mu rozuměl.

Pokud řešíte to samé, budu rád, když se ozvete. Zajímá mě hlavně, jak si organizujete den, ne který model používáte.

Zdroje

METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (7/2025) a aktualizace designu experimentu (2/2026)
Anthropic: 2026 Agentic Coding Trends Report. Vendor report, tedy predikce, ne měření.
Thoughtworks Technology Radar vol. 34: Codebase cognitive debt (4/2026)
Huang, Reyna, Lerner, Xia, Hempel: Professional Software Developers Don't Vibe, They Control (12/2025). Kvalitativní studie, N=13 pozorování a 99 respondentů v dotazníku.
BCG: When Using AI Leads to Brain Fry (3/2026), popularizace pro vývojáře na Built In