AI píše kód, ne produkt: co mi zbylo, když psaní převzali agenti

Většinu kódu ve svých aplikacích už nepíšu. Píšou ho agenti, já zadávám, rozhoduju a kontroluju. Zrychlilo mě to násobně — jen jinak, než se o tom obvykle mluví. Nezkrátila se doba, za kterou je funkce hotová. Zkrátil se čas, který u ní musím strávit já. A na tom, co mi zbylo, je zajímavé, že je to přesně ta část práce, o které jsem si dřív myslel, že je vedlejší.

Kde se to zrychlení schovává

Studie, kterou v téhle debatě všichni citují, měří něco jiného, než co dělám já.

METR v roce 2025 pustila 16 zkušených vývojářů na 246 reálných úkolů ve vlastních open-source repozitářích. S AI nástroji byli o 19 % pomalejší — a přitom si mysleli, že byli o 20 % rychlejší. To číslo obletělo svět. Co se cituje míň, je že únorový update z roku 2026 na 57 vývojářích, 143 repozitářích a přes 800 úkolech výsledek otočil: vracející se vývojáři byli o zhruba 18 % rychlejší, nováčci o 4 %. Autoři sami dodávají, že je to jen velmi slabý důkaz o velikosti toho zrychlení a že kvůli výběru účastníků jde nejspíš o spodní odhad.

Jenže obě studie měří pořád totéž: jak dlouho trvá úkol vývojáři, který u něj sedí. To je režim, kdy máte model vedle sebe a čekáte, až dopíše.

Můj režim je jiný. Zadám dávku práce, odložím notebook a jdu dělat něco jiného. Než je část programu hotová, uplyne klidně týden — ale mého času v ní jsou hodiny: napsat zadání, rozhodnout dvě tři věci po cestě, přečíst diff, projít review.

Doba do hotova se dramaticky nezkrátila, občas se i natáhla. Moje hodiny ano, a to násobně. Kdybych Najeto psal ručně, jsou to měsíce večerů. Takhle jsou to týdny kalendáře a dny mojí práce — a ty týdny nejsou prázdné, jen v nich dělám něco jiného. Stopky nad jedním úkolem tohle změřit neumí.

Aby ten režim fungoval, musí platit tři věci: práce jde rozřezat na kusy, které na sebe nečekají; máte co dělat mezitím; a máte čím výstup ověřit. Když kterákoli chybí, spadnete zpátky k sezení u agenta — a tam je zrychlení opravdu sporné.

Na druhou stranu rozvahy patří Stack Overflow Developer Survey 2025: AI používá nebo plánuje používat přes 84 % vývojářů, ale důvěřuje jí jen 29 % — meziročně o 11 bodů míň. A největší frustrace, kterou uvádí 66 % lidí, není „píše to blbosti". Je to „skoro správně, ale ne úplně".

To je daň za ověřování — a platí se přesně v tom zdroji, který delegování uvolnilo, tedy v mém čase. Kód, který dostanu, je téměř vždy syntakticky v pořádku, prochází typy a vypadá jako něco, co bych napsal, jen trochu méně uklizeně. Také obsahuje rozhodnutí, která jsem nikdy nemusel řešit.

Konvence jsou spustitelná specifikace

Jediná věc, která u mě zásadně zvedla kvalitu výstupu, nebyl lepší model. Byla to pravidla zapsaná tak konkrétně, že se nedají obejít.

Mám je napsaná mimo repozitář, jako sadu konvencí, které si agent načte podle toho, co dělá. Ne „piš čistý kód", ale:

• Každý helper je vlastní soubor ve složce helpers/, jméno souboru = jméno funkce, unit test vedle něj.
• Žádné barrel index.ts, importuje se přímo.
• Sdílené konstanty do constants.ts v nejbližším společném rodiči.
• Nikdy any. as jen s odůvodněním v JSDoc.
• Větvení nad enumem vždy switch s vyčerpávající kontrolou v default, nikdy řetěz ifů — jinak nová varianta tiše spadne do poslední větve.
• Varianty obrazovky (benzín, elektro, plug-in hybrid, motohodiny) se dělí nahoře na úrovni obrazovky a sdílí se až podkomponenty.

Tohle nejsou stylistické preference. Jsou to pravidla, která omezují prostor, ve kterém se agent může splést. Vyčerpávající switch znamená, že nová varianta je chyba překladu na každém místě, kde se na ni zapomnělo. To je záchranná síť, kterou nemusím hlídat já.

Čím konkrétnější pravidlo, tím méně prostoru pro „skoro správně".

Orchestrace místo promptování

Nemluvím s jedním agentem. Mám jich pět a každý má jinou roli a jiná omezení:

Nejužitečnější pravidlo z celé té sady je to nejnudnější: review kontroluje jako první, jestli změna vůbec patří do zadání. Ne jestli je správně. Nekontrolovaný agent nepřidá chybu — přidá funkci, kterou jste nechtěli, refaktor, o který jste neprosili, a „vylepšení", které rozbije něco tři obrazovky dál. Rozsah je ta věc, která uteče první.

A druhé pravidlo: manager nesmí psát. Ve chvíli, kdy plánovač může sáhnout na kód, přestane delegovat a začne to „rychle opravit sám" — a s tím zmizí celá kontrolní smyčka.

Kde se úzké hrdlo přesunulo

Před dvěma lety byl limit „kolik toho stihnu napsat". Dnes je limit „kolik toho stihnu rozhodnout a ověřit" — psaní šlo delegovat celé, rozhodování a čtení diffů nejde delegovat vůbec. Právě proto se moje hodiny zkrátily, i když kalendář zůstal skoro stejný.

Prakticky to znamená:

• Zadání se stalo tou drahou částí. Hodina strávená se spec-writerem ušetří tři hodiny opravování něčeho, co je hotové špatně.
• Rozhodnutí se nesmí schovat do implementace. Když se agent zeptá „mám ukládat jméno místa, nebo celou adresu?", je to produktová otázka převlečená za technickou. Když se nezeptá, rozhodne to sám — a dozvíte se to za měsíc.
• Konkurenční výhoda se posunula. Když umí prototyp za hodinu udělat každý, přestává být hodnota v tom, že to umíte postavit. Zbývá úsudek, co postavit, a schopnost to dostat k lidem.

Neříkám, že to bez agentů dělám líp. Čtyři aplikace vedle plného úvazku bych jinak nedal. Říkám jen, že „AI mi napsala apku" je špatný popis toho, co se stalo. AI mi napsala kód. Apku jsem musel pořád rozhodnout já — a tahle část se nezmenšila, jen přestala být schovaná pod psaním.

Zdroje

• Randomizovaná studie vlivu AI na produktivitu zkušených open-source vývojářů — METR, červenec 2025 (16 vývojářů, 246 úkolů).
• Update výsledků na větší kohortě a změna designu experimentu — METR, únor 2026 (57 vývojářů, 143 repozitářů, přes 800 úkolů).
• Odborný článek k té studii na arXivu — METR, 2025.
• Kapitola o AI ve vývojářském průzkumu za rok 2025 — Stack Overflow, prosinec 2025.