Kognitivní dluh — nová cena za AI rychlost

Znáš ten pocit? Tým dodává rychleji než kdykoli předtím. Sprint velocity jde nahoru, deployment frequency vypadá skvěle. Všechno svítí zeleně.

A přesto máš divný pocit, že když se něco rozbije, nikdo vlastně neví, jak to funguje.

Není to paranoia. Je to kognitivní dluh.

Co je kognitivní dluh

Technický dluh znáš — je to špatný kód, ke kterému se jednou vrátíš (nebo nevrátíš). Kognitivní dluh je něco jiného a v jistém smyslu horšího: je to stav, kdy tvůj tým aktivně produkuje kód, kterému nerozumí.

Margaret Storey z University of Victoria tento koncept formalizovala v únoru 2026. Její výzkum ukazuje, že AI-asistovaný vývoj vytváří systematickou mezeru mezi tím, co tým dodává, a tím, co tým skutečně chápe.

Klasický technický dluh je viditelný — můžeš ho změřit, nastavit metriky, naplánovat refactoring sprint. Kognitivní dluh je neviditelný. Všechno funguje. Testy procházejí. Ale porozumění eroduje s každým merge requestem, který prošel review s komentářem „LGTM, AI to vygenerovalo”.

40 % rychleji — ale za jakou cenu?

Data jsou jednoznačná: AI nástroje urychlují vývoj o 30–40 %. GitHub Copilot, Cursor, Claude Code — to všechno funguje. Tvůj tým reálně dodává rychleji.

Problém není v rychlosti samotné. Problém je v tom, co se děje mezi tou rychlostí:

• Kód prochází review, aniž by mu reviewer rozuměl — protože „AI to vygenerovalo, vypadá to OK”
• Junioři se nenaučí fundamenty — proč řešit architectural patterns, když AI to vygeneruje?
• Senioři přestanou klást nepříjemné otázky — protože všechno funguje (zatím)

Je to jako řídit auto stále rychleji, ale s mlžnými světly místo dálkových. Funguje to — dokud nepřijde zatáčka, kterou nevidíš.

54 % lídrů chce méně juniorů. To je chyba.

Tady to začne být opravdu zajímavé. Průzkumy z roku 2026 ukazují, že 54 % engineering lídrů plánuje nabírat méně juniorních vývojářů kvůli AI. Logika zní rozumně: „AI zvládne práci juniorů, tak proč je nabírat?”

Jenže tady je problém, který tahle logika přehlíží:

Junioři nejsou jen levná pracovní síla. Junioři jsou pipeline pro seniory.

Každý seniorní vývojář, kterého dnes máš v týmu, byl jednou junior, který se musel prokousat nepříjemnými debugging sessions, pochopit, proč architektonické rozhodnutí z roku 2019 dává smysl, a naučit se rozpoznat „kód, který vypadá správně” od „kódu, který je správný”.

AI generuje kód. Ale AI negeneruje úsudek. Ten se buduje léty zkušeností — a ty zkušenosti začínají jako juniorní pozice.

Kognitivní dluh v praxi

Jak to vypadá v reálném týmu? Tři scénáře, které potkávám u klientů:

Scénář 1: „Incident, který nikdo nechápe”

Produkce spadne ve 2 ráno. On-call vývojář otevře kód, který způsobil problém. Kód vygenerovala AI před třemi měsíci, prošel review, testy procházejí. Ale nikdo v týmu neví, proč je implementovaný takhle. Debugging, který by normálně trval hodinu, trvá celý den.

Scénář 2: „Refactoring, na který se nikdo neodváží”

Část systému potřebuje refactoring. Ale kód je AI-generovaný, nikdo mu úplně nerozumí, a nikdo nechce být ten, kdo to rozbije. Takže se obchází. Přidávají se workaroundy. Kognitivní dluh roste.

Scénář 3: „Junior, který neumí debugovat”

Junior vývojář v týmu dva roky. Umí skvěle promptovat AI. Ale když AI vygeneruje nefunkční kód, neumí identifikovat problém. Nemá mentální modely, které by mu řekly, kde hledat. Protože se je nikdy nenaučil — AI je vždycky obešlo.

Review praktiky, které zachovají rychlost

Řešení není zpomalit. Řešení je být rychlý a rozumět tomu, co děláš. Tady jsou konkrétní praktiky, které fungují:

1. „Explain Your AI” pravidlo

Každý PR s AI-generovaným kódem musí obsahovat vysvětlení od autora: proč je to implementované takhle, jaké alternativy zvažoval, a co by se stalo, kdyby se klíčová část odstranila.

Ne proto, aby to trvalo déle. Proto, aby autor musel kód pochopit, než ho pošle do review.

2. Rotace „Deep Review” role

Jeden člověk v týmu má každý sprint roli „deep reviewer”. Neříká jen „LGTM”. Klade otázky. Zpochybňuje. Vysvětluje juniorům, proč je něco problematické. Tato role rotuje — takže každý si ji zkusí.

3. „Kill the AI” debugging sessions

Jednou za dva týdny: debugging session bez AI nástrojů. Starý dobrý breakpoint, log, a přemýšlení. Ne proto, že AI je špatné — proto, že chceš, aby tvůj tým uměl fungovat i bez něj.

4. Junior mentoring s AI kontextem

Junioři pracují s AI, ale s mentorem, který se ptá: „AI ti navrhlo tohle. Proč to funguje? Co by se stalo, kdybys změnil tuhle část?” Cíl není zabránit juniorům v používání AI — cíl je zajistit, že se u toho učí.

5. Architectural Decision Records (ADR)

U každého většího AI-generovaného rozhodnutí krátký zápis: jaký byl kontext, jaké byly alternativy, proč jsme zvolili tohle. Dva odstavce. Budoucí ty ti poděkuje.

Metrika, kterou zatím nikdo nesleduje

Sprint velocity měříš. Deployment frequency měříš. Code coverage měříš.

Ale comprehension coverage — kolik procent kódové báze tvůj tým skutečně chápe — neměří nikdo. A přitom je to pravděpodobně nejdůležitější metrika pro dlouhodobou udržitelnost.

Nemám pro tebe magický nástroj, který to změří automaticky. Ale máš nástroje, které ti dají proxy:

• Bus factor — kolik lidí musí odejít, než se část systému stane black boxem?
• Incident resolution time trend — prodlužuje se čas řešení incidentů, i když velocity roste?
• Review depth — kolik komentářů a otázek je průměrně na PR? Pozor: klesající trend je ambivalentní. Pokud zároveň drží bus factor a incidenty se řeší rychle, je to známka zralosti. Pokud ale klesá i bus factor nebo roste resolution time — review se nejspíš stává formalitou a dluh tiše roste.

Nejde o to zpomalit

Tohle je důležité: kognitivní dluh se neřeší tím, že přestaneš používat AI. To by bylo jako řešit technický dluh tím, že přestaneš psát kód.

Řeší se tím, že:

1. Uznáš, že existuje — pojmenuj ho, mluv o něm na standupech a retro
2. Měříš ho (nebo alespoň jeho proxy) — viz metriky výše
3. Investuješ do porozumění — review praktiky, mentoring, debugging sessions
4. Nepřestaneš nabírat juniory — přizpůsob onboarding, ale nezavírej pipeline

Tvůj CTO report za Q1 vypadá skvěle. Velocity nahoru, time-to-market dolů. Ale pokud se za těmi čísly schovává tým, který nerozumí vlastnímu kódu, je to časovaná bomba. A teď víš, jak se jmenuje.

Co s tím

1. Pojmenuj to — „kognitivní dluh” dej do slovníku svého týmu, ať má problém jméno
2. Zaveď „Explain Your AI” pravidlo — od příštího sprintu, nulové náklady
3. Změř bus factor — pro každou kritickou část systému
4. Neruš juniorní pozice — přizpůsob mentoring, ale ten pipeline potřebuješ
5. Přidej do retro — pravidelnou otázku o porozumění kódu

Žádný z těchto kroků tě nezpomalí. Všechny ti pomohou udržet rychlost, kterou ti AI dává — a nezaplatit za ni víc, než musíš.

Chceš to probrat pro tvůj konkrétní tým? Ozvi se.

Mohlo by tě zajímat

• Vibe coding — technický dluh na steroidech
• Školit, nebo nabírat?
• Proč 90 % AI školení nic nezmění