Úzké hrdlo AI vývoje je ověření, ne psaní kódu

Když tým začne programovat s AI, kód vzniká rychleji. Rychleji se ale nasazuje jen tehdy, když má tým kde výsledek ověřit. Úzké místo se přesune od otázky „jak to postavíme“ k otázce „jak poznáme, že to funguje“. Pokud chybí testovací prostředí nebo sada testů, zrychlení skončí dávno před produkcí.

Jiří Kuldanek z našeho týmu to vídá tak často, že to popisuje jako obvyklý průběh. „Typicky ale postup vypadá tak, že firmu naučíme pracovat s AI, vygeneruje spousty kódu, co vypadá dobře, ale bojí se to nasadit, protože neví, co vlastně napsali.“

Při jedné nedávné spolupráci jsme stejný tým navštívili třikrát. Vývojáři v něm už s AI dokázali vytvořit funkční aplikace. Pustit je k uživatelům s klidným svědomím ale nedokázali.

Řekli jsme jim, že je to dobrá zpráva, a mysleli jsme to vážně. Firmy zavádějí AI právě proto, aby se prokousaly backlogem, který dřív rostl rychleji, než ho kdokoli stačil zpracovat. Pro tento tým už samotný vývoj nebyl to nejtěžší. Místo otázky „jak to vyvineme“ teď řešil otázku „jak zajistíme, aby to bylo správně“. Takový problém je lepší než ten původní a dá se vyřešit.

Důvod byl prozaický a systémový. Tým neměl sandbox, dev ani staging prostředí. Vývojáři si tak neměli kde změnu proklikat dřív, než se dostala k lidem, kteří na aplikaci závisejí.

Každá změna, kterou AI pomohla napsat rychleji, proto jen skončila ve frontě změn, které nikdo neověřil. Zrychlení, které AI přinesla, nezmizelo, jen se proměnilo v hromadu nedokončené práce. Ani CI/CD pipeline tu moc nepomůže, když před produkcí není kam nasazovat.

Nejvýmluvnější nám přijde, že tým na potřebu automatizovaných testů přišel sám. Dlouho se bez nich obešel. Jakmile ale většinu kódu přestal psát člověk, potřeboval tým jiný způsob, jak zjistit, co kód dělá. Testy byly nasnadě.

Jiří popisuje, jak obvykle pokračujeme. „V tu chvíli je jdeme učit psát s AI tak, aby si AI vedlo plnohodnotnou sadu testů a dodržovalo de facto testovací pyramidu či jiné obecné testovací konvence.“

Když kód píše model, přestávají být postupy jako test-driven development věcí vkusu.

Jiří ale u obecné sady testů nekončí. „Killer shot je ovšem to, že každá aplikace vypadá jinak a skoro u každé aplikace lze přijít s kreativním způsobem ověřování. Ta samotná implementace toho způsobu ověření je přenechána AI pod dohledem vývojáře.“

Jeho příklady jsou praktické:

Navíc se to samo posiluje. Čím víc kódu firma s AI napíše, tím lépe se v AI vyzná a tím lépe navrhuje vlastní způsoby, jak kód pomocí AI ověřovat.

Nedůvěra ke kódu z AI je dobře doložená. V průzkumu State of Code od Sonaru z roku 2026 mezi víc než 1 100 vývojáři uvedlo 96 %, že kódu vygenerovanému AI plně nevěří. Přesto ho před commitem vždy kontroluje jen 48 %. Sonar prodává nástroje na ověřování kódu, takže výsledky čtěte s vědomím, že na nich má obchodní zájem. Směr ale odpovídá tomu, co vidíme v praxi.

Většina článků, které jsme k tématu našli, hledá úzké hrdlo v kapacitě na code review: příliš velké pull requesty, přetížení senioři, review, které je potřeba automatizovat. To platí. My ale narážíme na potíž už o krok dřív. Některé týmy vůbec nemají kde změnu ověřit, a to žádné zrychlení review nevyřeší.

Kde prostředí existuje, dalším omezením se stává review. Deterministické kontroly na konci pipeline, třeba kontrola buildu nebo bezpečnosti, review zrychlují. Člověk už totiž nemusí hledat to, co dokáže zachytit stroj.

Stejně důležitá je velikost. Pull requesty vám nesmějí znovu přerůst přes hlavu, musí zůstat přiměřeně velké.

Jak to řeší tým Claude Code, popsal Anthropic v říjnu 2026 v článku How the Claude Code team does code review. Každou změnu přečte klasifikátor a přiřadí jí úroveň rizika. Změnu s nízkým rizikem nemusí schvalovat člověk, jakmile automatické review i bezpečnostní kontroly svítí zeleně. Změnu se středním rizikem schvaluje jeden člověk, změnu s vysokým rizikem dva.

Uvádějí také, že většina pull requestů nad 1 000 řádků dostane připomínky, kdežto většina malých projde bez nich. Podle jejich vlastních čísel se počet začleněných pull requestů od června do září víc než zdvojnásobil. Podíl těch, které bylo nutné revertovat, přitom klesl o víc než 40 %.

Myšlenku převezmete i bez jejich nástrojů. Předem si určete, které změny smí agent ověřit sám, které potřebují druhého agenta a které člověka.

Ověřování není jediná fáze, ve které se práce hromadí. Když se vývoj zrychlí, narazí na své limity i práce, která mu předchází. Vedle kontrol a testování se jako úzké místo ukáže i příprava dobré specifikace pro vývojáře.

Totéž se děje i po dodání. V jednom případě nebyli na tolik nových funkcí připraveni zákazníci našeho klienta. Marketing a produktový marketing museli zpomalit tempo vydávání, aby si uživatelé mohli na změny zvykat postupně. Úzkým hrdlem bývají lidé.

Jiří bez obalu říká, co je varovný signál. „Právě neexistence těch klasických správných procesů u psaní a dodání kódu je nejlepší indikátor toho, že tým po adopci psaní s AI stejně nebude schopný tak rychle dodávat.“

Známe i opačný případ. Pracovali jsme s týmy, kde za námi po zavedení AI přišli sami vývojáři s tím, že mají najednou mnohem víc kapacity. Celé vývojové prostředí měli nastavené správně a nový kód z AI zapadl do životního cyklu, který už měli zavedený.

Než proto týmu slíbíme jakékoli zrychlení, ptáme se:

Když jsou odpovědi chabé, práce začíná právě tady. Tyto otázky míří na to, jak se software vyvíjí a dodává. Širší záběr má hodnocení připravenosti na AI: případy použití, data a systémy, dovednosti a pravidla.

Zrychlení, které prodáváme, se neprojeví u zákazníka, který na ně není připravený. Horší je, že než si toho někdo všimne, uběhne pár týdnů. Ty otázky raději položíme před prvním workshopem, než abychom po něm vysvětlovali, proč se zrychlení nedostavilo.

Vycházíme z práce v terénu. Podrobně popsaný případ je jedna spolupráce, kterou jsme sledovali při třech návštěvách, bez jakéhokoli měření před a po. Když Jiří říká „typicky“, znamená to, že nešlo o výjimku. Jak často se to stává, jsme však nepočítali. Na tento vzorec narážíme opakovaně. Neznamená to ale, že chybějící testovací prostředí brzdí zavádění AI nejčastěji.

Chcete, aby váš tým prošel s AI celým cyklem od analýzy požadavků přes implementaci a testy až po nasazení? Právě to pokrývá naše školení End-to-end AI pro IT.