Kdo po umělé inteligenci zkontroluje kód – a proč na to slabší model nestačí

Dejte jazykovému modelu jeho vlastní řešení s chybou a zeptejte se, jestli je v pořádku. Podle preprintu z července 2025 (Tsui, arXiv 2507.02778) takovou vlastní chybu model přehlédne přibližně v 64,5 % případů a vadný výstup propustí jako správný. Pak ale přijde drobnost, která celé téma osvětluje. Jakmile se tatáž pasáž modelu předloží jako cizí vstup, slepota mizí; a samotná minimální pobídka „Wait“ ji v testu snížila o 89,3 %. Stejné řešení, stejný model, stejná chyba. Změnil se jen úhel pohledu.

Tahle scéna není akademická kuriozita. Modely dnes píší produkční kód, ne hříčky, a otázka, kdo nebo co ten kód po nich zkontroluje, se přesouvá z konferenčních slajdů do reálných CI pipeline. V týmech přitom zdomácněla pohodlná odpověď: na review nasaďme menší, levnější model, protože hlídání je snazší než tvorba. Ta úvaha v sobě má zrnko pravdy a velký kus účetnictví.

O spolehlivosti kontroly nerozhoduje v první řadě velikost revizního modelu, ale jeho nezávislost na tom, kdo kód napsal. Teze „na review stačí slabší model“ platí pro snadné, mechanicky ověřitelné chyby a je z velké části artefaktem ceny a propustnosti, ne kvality detekce. U subtilních a kritických chyb - architektonických, bezpečnostních, logických v hloubce domény - slabý kontrolor systematicky míjí to nejdůležitější. A čím silnější je generátor, tím hůř se jeho chyby hledají.

Začněme tím, co je doložené nejpevněji. Že model nadržuje vlastnímu výstupu, ukázala recenzovaná práce z NeurIPS 2024 (Panickssery, Bowman, Feng; arXiv 2404.13076): na tisících článků našla lineární vztah mezi tím, jak dobře model rozpozná vlastní text, a tím, jak silně mu pak straní. GPT-4 i Llama svůj vlastní výstup „poznají“ a hodnotí ho příznivěji. Důležitější než samotný efekt je ale jeho příčina. Podle analýzy z konce roku 2024 (Wataoka et al., arXiv 2410.21819) nejde o ego, ale o perplexitu - model preferuje texty, které jsou mu povědomé, protože by je sám napsal podobně. Z toho plyne nepříjemný důsledek pro praxi: tahle zaujatost spolehlivě zmizí jen tehdy, když kontrolu provede jiný model, ne když témuž modelu vyměníte prompt.

Druhý pilíř je ještě tvrdší. Tři nezávislé recenzované studie se shodují, že model neumí spolehlivě opravit vlastní úvahu bez vnější zpětné vazby. Google DeepMind v práci pro ICLR 2024 (arXiv 2310.01798) ukázal, že po pokusu o sebeopravu se výkon modelů někdy dokonce zhoršil, a že víceagentní „debata“ nepřekoná prostou shodu více běhů téhož modelu. Tým z Cambridge a Google Research (ACL Findings 2024, arXiv 2311.08516) pak lokalizoval úzké hrdlo: problém není chybu opravit, ale najít ji. Malý klasifikátor natrénovaný na datech mimo doménu přitom v hledání chyb překonal promptování velkého modelu - což je samo o sobě silný argument, že detekce není v první řadě otázka velikosti. A kritický přehled z Penn State (TACL 2024, arXiv 2406.01297) shrnul, že žádná z dosavadních prací nepředvedla úspěšnou sebeopravu s pouhou zpětnou vazbou od promptovaného modelu; funguje to jen tam, kde existuje spolehlivý vnější signál.

Když se totéž měří přímo na detekci chyb, obraz se nelepší. Benchmark ReaLMistake (Kamoi et al., COLM 2024, arXiv 2404.03602) zjistil, že GPT-4 i Claude 3 hledají chyby v odpovědích modelů s velmi nízkým recallem, výrazně hůř než lidé, a že self-consistency ani většinové hlasování detekci nezvednou. Naivní škálování slabého modelu „víc pokusů“ tedy nepomáhá.

Tím se dostáváme k jádru sporu o velikost. Pokud je hledání chyb obtížné, neměl by ho silnější model zvládat líp? Zčásti ano - jenže s háčkem, který hraje proti slabým kontrolorům. Práce „Variation in Verification“ (arXiv 2509.17995) ukázala, že chyby slabších generátorů se detekují snáz než chyby silných. Pro verifikátor Qwen2.5-72B klesla schopnost zachytit chybné řešení z hodnoty 0,68 u úloh řešených modelem Llama-3.1-8B na pouhých 0,17 u úloh od silnějšího Qwen3-32B - měřeno na matematických úlohách s jednoznačně ověřitelným výsledkem. Přeloženo do praxe, a za předpokladu, že tentýž mechanismus platí i pro kód: čím lepší model řešení napsal, tím spíš potřebujete na jeho kontrolu silný - a hlavně jiný - model. Souběžně práce „Learning to Self-Verify“ (arXiv 2602.07594) doložila, že zlepšování generování nevede k odpovídajícímu zlepšení sebeverifikace; ta asymetrie přetrvává.

U kódu je důkazů méně a rozcházejí se. Preprint z května 2026 (Reddy et al., arXiv 2605.21537), jehož autoři působí v AWS, ale výzkum deklarují jako nezávislý na zaměstnavateli a bez proprietárních dat, prošel 1 980 volání na modernizaci kódu napříč jedenácti produkčními modely. Sémantické pasti, které na neškodném kódu vznikaly v 7 % případů, vyskočily u rizikového kódu na 39,7 %, a co je horší: 31,7 % vlastních sémantických chyb model tiše schválil. U jednoho modelu to bylo 100 %. Drift přitom nešel čistě s velikostí modelu, kolísal od 5,6 do 46,7 %, což ukazuje spíš na strukturální problém než na nedostatek schopností.

Recenzovaná studie z roku 2026 (Dolcetti et al., Springer, DOI 10.1007/s44163-026-01009-5) v hodnocení kódu žádné nadržování vlastnímu výstupu nenašla. Modely jsou podle ní v detekci bugů prostě špatné plošně, bez ohledu na autorství - F1 pod 80 % u správnosti, pod 30 % u zranitelností. Možné smíření obou nálezů: nejde o „ego“, ale o kombinaci toho, že modely subtilní chyby obecně přehlížejí, a že vlastní kód je jim navíc povědomý. Práce z University of Virginia (arXiv 2504.03846) k tomu přidává znepokojivý detail - silnější modely jsou sice lepší soudci, ale jejich škodlivé nadržování se zhoršuje právě tehdy, když se samy mýlí. Silnější model hůř pozná, že se plete.

Teď nejsilnější verze opačného názoru, protože si ji téma zaslouží. Asymetrie verifikace je reálná: u velké třídy úloh je kontrola levnější než tvorba, a empiricky to sedí. Na sto úlohách z LiveCodeBench dosáhlo ověřování přes property-based testy 87 % proti 63 % u samotného generování (PGS, arXiv 2506.18315, na modelu DeepSeek-R1-32B) - nešlo tedy o čistou self-review, ale o strukturovanou zpětnou vazbu z testů. Slabé verifikátory navíc v agregaci fungují: stanfordský systém Weaver (arXiv 2506.18203) kombinací mnoha slabých signálů uzavřel mezeru mezi generováním a ověřením o 14,5 %, a metoda vícenásobné agentní verifikace (arXiv 2502.20379) přinesla zisky i tam, kde slabé verifikátory posuzovaly silné generátory. Připočtěme ekonomiku: review běží na každém pull requestu mnohonásobně častěji než generování, takže tlak na menší a rychlejší model je racionální. Ta úvaha je platná - ale jen za jedné podmínky. Všechny uvedené výsledky pocházejí z úloh s objektivní pravdou, typicky z matematiky, kde funguje sečíst mnoho slabých signálů a kde existuje jednoznačné „správně“. Otevřená detekce subtilního bugu v cizí codebase takovou pravdu nemá. Slabý reviewer je proto obhajitelný jako první filtr na snadné a ověřitelné chyby, ne jako poslední slovo nad bezpečnostně či architektonicky citlivým kódem. A přesně v brownfield kódu, kde dominují integrační a architektonické chyby, slabý model selhává nejvíc.

Z toho všeho ale neplyne „nasaďte největší model“. Plyne z toho něco užitečnějšího. Dokonalý model neexistuje, takže smysl nedává hledat jediného správného reviewra, ale skládat vrstvy s co nejméně překrývajícími se slepými skvrnami. První vrstvou jsou deterministické nástroje: kompilátor nebo typový kontrolor, linter, sanitizery, testy, statická analýza. V řeči modelů jsou „hloupé“, jenže jejich mechanismus selhání je jiný než u modelu, a to je právě to cenné. Srovnání nástrojů SAST a modelů (Zhou et al., arXiv 2407.16235) ukázalo doplňkovost obou světů: SAST má nízkou míru záchytu, ale málo falešných poplachů, zatímco modely odhalí 90 až 100 % zranitelností za cenu vysoké falešné pozitivity. Když se obojí spojí, slabiny se tlumí - hybridní SAST-Genius (arXiv 2509.15433) snížil falešné poplachy nástroje Semgrep z 225 na 20. Druhou vrstvou je jiný, ideálně silný model. A třetí vrstvou zůstává člověk, protože záměr, kontext byznysu, zneužitelnost a udržovatelnost model bez vnějšího kontextu nevidí. Tady ovšem číhá past zvaná automatizační zaujatost: metaanalýza klinických podpůrných systémů (Goddard, Roudsari, Wyatt; JAMIA 2012, PMC3240751) zjistila, že když nástroj radí špatně, zvyšuje pravděpodobnost chybného lidského rozhodnutí o 26 % (risk ratio 1,26; interval spolehlivosti 1,11 až 1,44). Reviewer proto musí běžící kód aktivně zkoušet, ne jen číst diff a přikyvovat.

A protože v tomhle tématu mluví hodně hlasů, vyplatí se vědět, kdo má jaký zájem. Nejstřízlivější závěry pocházejí od akademických týmů bez vlastního produktu - z Penn State, Cambridge, University of Virginia nebo z italsko-britské skupiny kolem Dolcettiho. Výrobci hraničních modelů mají dvojí motivaci. Někdy přiznají limit, jako když DeepMind otevřeně napsal, že sebeoprava nefunguje; takový závěr jde proti vlastnímu zájmu, a tím je důvěryhodnější. Jindy chtějí ukázat, že jejich kontrola je dost dobrá. Příznačný je text OpenAI o ověřování kódu ve velkém měřítku (alignment.openai.com), který není recenzovaný a pochází od firmy prodávající jak modely, tak review agenta: tvrdí, že jeho kontrola zůstává srovnatelně účinná i na vlastním kódu, ale sám přiznává, že čisté přímé měření tohoto tvrzení chybí a že recall je trvale vyšší na kódu psaném lidmi. Výrobci nástrojů pro code review - Greptile, CodeRabbit, Qodo, cubic a další - mají zájem ukázat, že automatická kontrola funguje, případně že stačí levnější model, který snižuje jejich náklady. Jejich vlastní benchmarky jsou vzájemně nekonzistentní a čísla typu „třikrát až pětkrát víc nalezených chyb u cizího modelu“ patří do kategorie marketing, ne věda; jeden vendor si vlastním křížovým testem naměřil nadržování pod dvěma procentními body. Zvlášť ostražitý je dobré být u preprintů na arXivu: nejsou recenzované a velká část pochází právě od komerčních laboratoří se zájmem na výsledku.

Stojí za to dodat, kam vyšší schopnosti modelu riziko posouvají. Zpráva firmy Sonar z října 2025, postavená na více než 4 400 programovacích úlohách v Javě, naměřila u Claude Sonnet 4 vyšší průchodnost testů o 6,3 % proti starší verzi - ale jeho chyby byly o 93 % častěji té nejvyšší závažnosti. „Code smells“ tvořily u každého testovaného modelu přes 90 % všech nálezů. Sonar prodává nástroje na kvalitu kódu, takže má zájem ukazovat, že kód od AI potřebuje kontrolu; směr té zaujatosti je dobré držet v hlavě. Přesto se nález shoduje s mechanismem, který vidíme i jinde: vyšší reasoning chybovost nemaže, jen ji přesouvá k subtilnějším a nebezpečnějším pastím.

Co si z toho odnést prakticky? Že odpověď nehledejte ve vendor benchmarcích, ale ve vlastních datech. Nasaďte si do vlastní codebase kontrolovanou sadu chyb a změřte, kolik jich váš reviewer najde a kolik chybných řešení propustí. Pokud schopnost zachytit chybu na vašem typu kódu spadne pod hranici, kterou by žádný kontrolor neměl podkročit, je ten reviewer na kritický kód slabý - bez ohledu na to, co slibuje jeho dodavatel. Skutečná otázka totiž nezní, který model nasadit na review, ale kolik nezávislých vrstev jste ochotni postavit mezi vygenerovaný kód a produkci. Jeden reviewer, byť hraniční, je monokultura. A monokultury padají na první chorobě, na kterou nemají protilátku.

Tento text vznikl na základě strukturované rešerše a prošel ověřením zdrojů na primární úrovni: existence všech citovaných prací, jejich identifikátory (arXiv, DOI, PMC), autorství i místo publikace byly ověřeny proti arXiv, Springer a PubMed Central. Některá konkrétní čísla z preprintů roku 2026 a z plných textů (přesné krajní hodnoty driftu u Reddyho, hodnota risk ratio z metaanalýzy JAMIA, prahy F1 u Dolcettiho) odpovídají abstraktům a snippetům, ale před citací v posudku či dalším použití zaslouží kontrolu ve full-textu. Vendorské materiály nesou nejnižší jistotu. Úrovně jistoty: VYSOKÁ (recenzovaný primární zdroj), STŘEDNÍ (preprint nebo jednotlivá nezávislá studie), NÍZKÁ (marketingově zatížené nebo neověřené tvrzení).

Tři poctivé výhrady k samotnému tématu. Za prvé: čistý kontrolovaný experiment „týž model versus jiný model na identickém kódu“ v recenzované literatuře v podstatě chybí. Mechanismus výhody jiného modelu (dekorelované slepé skvrny) je doložen na úrovni principu, jeho velikost konkrétně v code review zatím nezávisle nikdo nezměřil. Za druhé: většina nejsilnějších důkazů pochází z matematiky a reasoningu, ne z produkčního kódu; přenos na kód je rozumná, ale ne dokázaná extrapolace - tam, kde v textu zaznívá číslo naměřené na matematické úloze, je to výslovně uvedeno. Za třetí: efektové velikosti silně závisejí na obtížnosti úlohy, jazyce a typu chyby - žádné jednotlivé číslo nelze zobecnit.

Transparentnost tvorby:

Koncepce, struktura a redakční linie článku jsou dílem autora, který vypracoval obsahovou skicu, stanovil klíčové teze a řídil celý proces tvorby. Generativní AI (Claude, Anthropic) byla využita jako nástroj pro rešerši, vyhledávání primárních zdrojů a formulační rozpracování autorovy obsahové skici.

Autor výstupy průběžně redigoval, ověřil klíčová zjištění a schválil finální znění. Žádná část textu nebyla publikována bez lidské kontroly. Všechny faktické údaje byly ověřeny proti veřejně dostupným zdrojům uvedeným v textu.

Postup je v souladu s požadavky čl. 50 Nařízení EU 2024/1689 (AI Act) na transparentnost AI-generovaného obsahu. #poweredByAI