Když všechno vypadá v pořádku, začíná moje práce

Minule jsem psal o tom, že když kód píšou agenti, bottleneckem se stává člověk. Že mým limitem není implementační kapacita, ale kolik rozhodnutí za den udělám dobře.

Od té doby mi vrtá hlavou nepříjemné pokračování. Napsal jsem, že těžiště mojí práce je teď v kontrole a v rozhodování. Ale co když je zrovna kontrola slabší, než si o ní myslím?

Došlo mi to na obyčejném review. Agent vrátil změnu ve zpracování objednávek a k tomu odstavec, proč to udělal zrovna takhle. Dávalo to smysl. Kód vypadal čistě, testy zelené. Napsal jsem „ok". Za dva dny se ukázalo, že jeden typ objednávky se zpracuje špatně.

Když jsem si to přehrál zpátky, zjistil jsem nepříjemnou věc. Ta informace v tom diffu byla. Já jsem ji četl. Jen jsem s ní nic neudělal. Nehledal jsem totiž chybu. Ověřoval jsem, jestli mi to dává smysl.

To je rozdíl, který jsem si dlouho neuvědomoval.

Co se vlastně změnilo

Dřív měla moje práce zabudovanou pojistku. Když jsem něco navrhl špatně, nefungovalo to. Verdikt přišel sám a bylo mu jedno, jak moc jsem si věřil.

dřív:  problém → můj nápad → zkusím → nefunguje → přemýšlím znovu
dnes:  problém → hotové řešení i s vysvětlením → posoudím → „ok"

Vypadá to jako drobnost. Není.

V prvním případě problém řeším. Mám o něm vlastní představu dřív, než uvidím jakoukoli odpověď. Ve druhém případě hotovou odpověď posuzuju. A představu o tom problému mi dodá ten, koho mám zkontrolovat.

Kontrolovat hotovou práci je něco jiného než tu práci udělat. A jde mi to hůř, než jsem si myslel.

Nedávno pro to vznikl pojem: kognitivní kapitulace

Kognitivní kapitulace (anglicky cognitive surrender) je moment, kdy člověk vezme odpověď AI za svou, aniž by ji pořádně prohnal vlastní hlavou. Ten pojem nedávno navrhli Steven Shaw a Gideon Nave z Whartonu ve studii z ledna 2026, není to zavedený termín z učebnice.

Zkoušeli to jednoduše. Lidé řešili logické úlohy, u kterých první nápad bývá špatně. Část z nich mohla použít chatbota. Ten měl náhodně nastavené, jestli poradí dobře, nebo sebejistě špatně.

Co jim vyšlo:

s dobrou radou se lidé zlepšili o 25 procentních bodů oproti těm bez AI
se špatnou radou si pohoršili o 15 procentních bodů
dobrou radu poslechli v 93 % případů, špatnou v 80 %

Tu první odrážku beru stejně vážně jako tu druhou. Není to studie proti AI. Když AI poradí dobře, přínos je velký. Když poradí špatně, škoda je taky velká. A o tom, co z toho nastane, nerozhoduje nástroj. Rozhoduje to, jestli si tu odpověď zkontroluju.

Přidám dvě výhrady. Studie zatím neprošla recenzním řízením. A testovaly se na ní logické hádanky, ne skutečná práce. Naletět u chytáku a schválit špatný merge není totéž.

Podle pocitu se to poznat nedá

Ze stejné studie vyšla ještě jedna věc. Lidé s chatbotem si věřili asi o 12 % víc než lidé bez něj. A to jim chatbot v polovině případů radil špatně.

Tohle je pro mě jádro celé věci.

Kdybych u špatného rozhodnutí cítil nejistotu, nemám problém. Zpomalím, projdu to znovu, zeptám se někoho. Jenže ta nejistota nepřijde. Přijde pravý opak.

Minule jsem zmiňoval experiment METR. Vývojáři s AI tam byli o 19 % pomalejší a i po skončení testu si mysleli, že jim AI pomohla. Tehdy mi to přišlo jako kuriozita. Dneska to čtu jinak. Je to ta samá věc: mám pocit, že práce jde dobře, a ten pocit nemá s výsledkem moc společného. (Sami autoři v únoru 2026 doplnili, že u novějších nástrojů už zrychlení nejspíš nastává. To ale nic nemění na tom rozdílu mezi pocitem a měřením, kvůli kterému tu studii zmiňuju.)

Podobně dopadla studie ze Stanfordu, tentokrát rovnou na vývojářích. Jedna skupina psala bezpečnostně citlivý kód s AI asistentem, druhá bez něj. Ta s asistentem napsala méně bezpečný kód. A přitom si víc věřila, že píše bezpečně. Nejlíp dopadli lidé, kteří asistentovi věřili nejmíň.

Testovaly se tam modely z roku 2022, dneska je to muzeum. Neberu si z toho, že AI píše nebezpečný kód. Beru si jediné: podle pocitu se to poznat nedá.

Hranice schopností AI není vidět

Kdyby chyby chodily tam, kde je čekám, dám si na ta místa pozor a mám hotovo. Jenže tak to nefunguje.

Existuje na to termín: jagged frontier, tedy roztřepená hranice schopností. Znamená to, že AI nezvládá úkoly podle toho, jak jsou těžké pro člověka. Něco snadného jí nejde, něco složitého zvládne bez zaváhání. Termín zavedli výzkumníci z Harvardu a BCG v experimentu se 758 konzultanty.

U úkolů, které AI zvládala, zvedla kvalitu výstupu o víc než 40 %. U úkolu kousek za tou hranicí byli lidé s AI o 19 procentních bodů náchylnější odevzdat špatné řešení. To druhé číslo je potřeba brát s rezervou: stojí na jediné úloze, schválně navržené tak, aby na ní model selhal, a testoval se GPT-4 z dubna 2023.

Praktický dopad ale zůstává: nemůžu si dopředu říct, u které skupiny úkolů budu opatrný. Podle toho, jak těžký mi ten úkol připadá, se to poznat nedá. Špatný výstup navíc vypadá stejně sebejistě jako dobrý.

Co pomáhá

Wharton zkoušel dvě cesty, jak kapitulaci zmenšit. Časový tlak nezabral vůbec. Zabralo něco jiného: odměna za správnou odpověď a okamžitá zpětná vazba u každého pokusu. Lidé pak špatné rady odmítali mnohem častěji.

Pro moji práci z toho plyne jednoduchá věc. Nemá smysl si slibovat, že budu číst pozorněji. Smysl má mít u výsledku něco, co ho posoudí za mě.

Rozdělil jsem si podle toho práci na dvě hromádky:

posoudí to za mě:   testy, typecheck, lint, build, migrace, běh na reálných datech
posoudím jen já:    návrh, byznysová logika, priority, text pro klienta, odhad dopadu

U první hromádky převedu velkou část kontroly na automatické pojistky. Stačí je zadat dopředu a agent si je pustí sám, ještě než mi práci předá.

Vyřešené to ale není a nechci to tak tvrdit. Na začátku článku je chyba, která prošla přes zelené testy, a nebyla to náhoda. Když testy píše ten samý agent, co psal kód, vycházejí ze stejného pochopení zadání. Chybný předpoklad si tak dostane vlastní zelený test. Je to přesně stejná past jako to hezky napsané zdůvodnění, jen o patro níž. Taky vypadá jako důkaz a taky jím není.

Váhu má hlavně kontrola, která nevznikla spolu s tím řešením. Zadání, co má platit. Porovnání se zdrojovým systémem. Kontrolní součet. Běh na reálných datech.

U druhé hromádky ani tohle nemám. Tam jsem kontrola já a nikdo jiný. A platí u ní nepříjemné pravidlo: čím míň dané věci rozumím, tím míň se můžu spolehnout na vlastní review. Nemusím umět napsat všechno, co kontroluju, ale musím vědět, co má platit a podle čeho to poznám. Kde tohle nemám, tam nekontroluju. Tam jenom čtu a přikyvuju.

Jak to dělám já

Nesnažím se AI míň věřit. To zní chytře a nedá se podle toho pracovat. Zkouším místo toho čtyři konkrétní věci a jedu je asi tři týdny.

Vlastní odhad si píšu dřív, než otevřu výsledek. Do zadání si přidám dvě tři věty: jak bych to řešil já a co se u toho dá pokazit. Nejde o to mít pravdu. Jde o to mít vlastní představu dřív, než dostanu hotovou. Když se pak výsledek liší, mám o čem přemýšlet. Bez toho jenom kývu na cizí návrh.

Po agentovi chci důkaz, ne vysvětlení. V minulém článku jsem psal, že definition of done patří do zadání. Posunul jsem to dál. Nezajímá mě věta, že to funguje. Zajímá mě, co to dokazuje. Které testy na to sahají a jestli vznikly z mého zadání, nebo si je agent domyslel k vlastnímu řešení. Co je ověřené na reálných datech. Co záměrně neřeším. Hezky napsaný odstavec o tom, jak je řešení správné, mi kontrolu neusnadňuje. Ztěžuje ji.

Rychlý souhlas beru jako varovný signál. Tohle je nejpodivnější návyk z celé sady a funguje mi nejlíp. Když do půl minuty cítím „ok, tohle je ono", je to přesně ten stav, který ta studie měří. Nemusí to znamenat, že je to špatně. Znamená to, že jsem zatím nic nezkontroloval, jen jsem dostal dobrý pocit. Tak si položím otázku: kdyby to bylo špatně, kde by se to projevilo?

U druhé hromádky zpomaluju schválně. Nechám si návrh rozepsat do dvou tří variant i s tím, co mluví proti každé z nich. Jednu možnost umím jenom schválit nebo zamítnout. Mezi třemi se musím rozhodnout. To je jiná práce a mnohem hůř se u ní přikyvuje.

Co naopak nedělám: nečtu všechno dvakrát pomaleji. Tím bych se vrátil přesně do toho bottlenecku, o kterém byl minulý článek.

Mimo kód je to stejné, jen to není vidět

U kódu mám aspoň ty testy. Většina firem ale nasazuje AI přesně tam, kde nic takového není. Do nabídek, odpovědí zákazníkům, podkladů pro rozhodnutí, analýz, shrnutí schůzek.

Kontrola se pak formuluje jako „ať to po AI někdo přečte". Podle čísel výš je to slabší pojistka, než jak zní. Čte to člověk, který dostal hotovou odpověď i s vysvětlením. Často ji neumí ověřit rychleji, než by ji sám napsal. A pocit jistoty ho neupozorní, že něco nehraje.

Když dneska navrhuju automatizaci, ptám se dřív než na nástroj: co v tomhle kroku hraje roli testu? Někdy je to kontrolní součet nebo porovnání se zdrojovým systémem. Někdy vzorek, který se ověří ručně. Někdy stačí, že výstup nikam neodejde, dokud ho někdo schválí a má k tomu podklady mimo AI.

Když na tu otázku odpověď není, není to hotová automatizace. Je to jen rychlejší způsob, jak vyrobit něco, co nikdo neověří.

Kde to podle mě je

Minulý článek jsem uzavřel tím, že mým výsledkem už není jen napsaný kód, ale i dobré rozhodnutí. Tenhle bych uzavřel doplňkem, který mi tam chyběl. Dobré rozhodnutí není to, u kterého mám dobrý pocit.

Nebaví mě verze téhle debaty, kde se řeší, jestli AI lidi hloupne. Zajímavější je, co se s tím dá dělat. Kapitulace není povahová vada. Je to reakce na situaci, kterou si kolem sebe stavím sám. A dá se postavit jinak: mít vlastní odhad dřív než odpověď, chtít důkaz místo vysvětlení a být nejostražitější zrovna ve chvíli, kdy se všechno zdá v pořádku.

Zajímalo by mě, jak to řešíte vy, hlavně mimo vývoj. Co u vás v procesu hraje roli testu? Ozvěte se, tohle je téma, kde se docela rád nechám vyvést z omylu.

Zdroje

Shaw, Nave: Thinking Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender (1/2026). Preprint bez recenzního řízení, tři předregistrované experimenty, 1 372 účastníků. Srozumitelné shrnutí od autorů na Knowledge at Wharton.
Dell'Acqua a kol.: Navigating the Jagged Technological Frontier, Organization Science (3/2026). Terénní experiment se 758 konzultanty BCG, prošlo recenzním řízením. Zhoršení o 19 procentních bodů ale stojí na jediné úloze mimo hranici a na GPT-4 z dubna 2023.
Perry, Srivastava, Kumar, Boneh: Do Users Write More Insecure Code with AI Assistants?, ACM CCS 2023. Testované modely jsou dnes zastaralé, použitelné je hlavně zjištění o sebedůvěře.
METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (7/2025) a aktualizace z 2/2026, podle které u novějších nástrojů zrychlení nejspíš nastává. Zmiňuju kvůli rozdílu mezi vnímanou a skutečnou rychlostí, ten aktualizace nevyvrací.