Testy prošly a produkce stejně spadla: mezera v ověřování AI kódu, kterou nikdo nechce pojmenovat

CloudBees letos udělal průzkum mezi víc než 200 tech lídry a výsledek je z těch, co si přečtete dvakrát, protože si ty dvě poloviny navzájem protiřečí. 92 % si bylo jistých svým kódem ještě předtím, než ho pustili do produkce. 81 % zároveň hlásilo víc produkčních selhání z AI kódu než před rokem. Obě čísla pocházejí od stejných lidí. Nechte to na sebe chvíli působit, protože to není šum, je to signál o tom, jak rozbitá je zpětná vazba mezi tím, co vám říká CI, a tím, co se reálně stane, když kód narazí na skutečný provoz.

Telemetrie od Lightrun to ještě přiostřuje. Zjistili, že 43 % změn vygenerovaných AI potřebovalo debugging v produkci, a to až poté, co prošly QA. Ne když QA přeskočily. Když jím prošly. Takže skoro polovina AI kódu, který prošel všemi branami, co váš tým postavil, lintery, unit testy, integračním sadami, smoke testy na stagingu i manuálním PR review, stejně po nasazení spadla.

Většina engineering týmů to teď čte jako problém s objemem. Generujeme víc kódu, takže propadne víc chyb, takže potřebujeme víc bran. Ten instinkt je špatný a spoustu týmů bude stát incident ve dvě ráno, než přijdou na to proč. Objem není problém. Problém je model ověřování a přidávání dalšího stejného ověřování pipeline jen zpomalí, aniž by chytalo věci, na které nikdy nebylo navržené.

Zamyslete se nad tím, co vlastně lidský pull request kóduje. Když některý z vašich vývojářů napíše funkci, diff je viditelný artefakt, ale za ním sedí mentální model. Ví, proč sáhl po mapě místo slice, pamatuje si, že upstream služba ve třech konkrétních edge casech vrací nully, má intuici o tom, která část codebase je křehká, protože ho posledně vzbudil pager, když to spadlo. Code review proces byl navržený s předpokladem, že tenhle mentální model existuje a že ho reviewer může prozkoumat otázkami ve vlákně PR.

AI kód za sebou žádný mentální model nemá. Diff je celý artefakt. Je tam věrohodně vypadající error handling, který vznikl pattern-matchingem z trénovacích dat, ne přemýšlením, jsou tam předpoklady zabudované do kódu, o kterých model nemohl vědět, že jsou špatně, protože nikdy neviděl váš produkční provoz, a je tam sebevědomě vypadající happy path, která řeší přesně ty případy zmíněné v promptu a všechno ostatní potichu ignoruje.

Váš deterministický pipeline kontroluje, jestli je kód vnitřně konzistentní. Zkompiluje se, projdou testy, sedí to na style guide, splňuje to kontrakt, který testy ověřují. Co zkontrolovat nedokáže, je jestli předpoklady, na kterých kód stojí, odpovídají realitě, protože nic v unit test sadě nekóduje to nepořádné, nezdokumentované chování systému, ve kterém kód poběží. Lidský autor tenhle kontext nosil v hlavě a reviewer ho z něj vytahoval konverzací. Vyndejte člověka a odstranili jste vrstvu, na které celá vaše architektura ověřování potichu stála, zatímco všechny brány, co s ní počítaly, zůstaly na místě.

Tady je ta část, na které ujedou i chytré týmy. Když AI napíše feature a zároveň napíše testy pro tu feature, testy projdou v míře, která působí uklidňujícím dojmem a ve skutečnosti nic neznamená. Model vygeneroval kód za jednoho souboru předpokladů a pak vygeneroval testy za stejného souboru předpokladů. Samozřejmě, že si navzájem odpovídají. Postavili jste uzavřenou smyčku, kde věc, kterou ověřujete, a věc, která ověřuje, sdílejí stejná slepá místa.

Viděli jsme to konkrétně na document processing pipeline, který jsme minulý kvartál převzali po klientovi. Předchozí tým hodně používal AI nástroj a report pokrytí testy ukazoval 94 %, což je na papíře skvělé. Produkční logy vyprávěly jiný příběh: stálý pramínek selhání na PDF s konkrétním embedded font encodingem. Vygenerovaný parser zvládal encodingy, na kterých model viděl příklady, vygenerované testy mu krmily přesně tyhle encodingy a celé to svítilo zeleně, zatímco to potichu zahazovalo možná 6 % reálných dokumentů. Žádná CI brána by to nikdy nechytila, protože každý test v sadě byl psaný proti vlastním předpokladům parseru o tom, jak vypadá PDF.

Tohle je ten strukturální problém, který průzkumy měří. Číslo jistoty od CloudBees je vysoké přesně proto, že testy procházejí, a testy procházejí přesně proto, že testují kód proti sobě samému, ne proti realitě. Přidat do toho pipeline další bránu, mutation testing, přísnější threshold pokrytí, dalšího reviewera, nepomůže, protože každá z těch bran pořád operuje na stejné uzavřené množině předpokladů. Můžete navršit deset deterministických kontrol, budou si všechny navzájem odpovídat a kód stejně spadne, jakmile narazí na ten jeden input, který nikdo, člověk ani model, nedokázal vymyslet.

Řešením není víc CI, ale jiná kategorie ověřování, která míří na vrstvu předpokladů místo na vrstvu konzistence. Pár věcí, které nám a klientům, kterým jsme s tím pomáhali, fungovaly.

Donuťte model vytáhnout své předpoklady explicitně, ještě než se vůbec podíváte na kód. Když generujeme netriviální změnu, první artefakt, který chceme, není diff, ale psaný seznam každého předpokladu, na kterém implementace stojí. Jaké inputy očekává, jaké failure modes považuje za nemožné, jakému upstream chování věří. Senior vývojář ten seznam přečte a špatný předpoklad chytí za třicet vteřin, zatímco při čtení tří set řádků věrohodného kódu by ho nechytil nikdy.

Testujte proti datům ve tvaru produkce, ne proti syntetickým datům, co si model vymyslel. Shadow traffic, přehrané reálné requesty, nahrané payloady ze stagingu, které přišly ze skutečných integrací. Těch 43 % od Lightrun žije skoro celých v mezeře mezi tím, jak si model představoval inputy, a tím, jak reálně vypadají, takže nejlevnější tah s nejvyšší pákou je dát kódu reálné inputy ještě předtím, než jde do produkce, ne až potom.

Berte AI změny ve své deploy strategii defaultně jako rizikovější. Menší blast radius, agresivnější canary, rychlejší automatické rollback triggery navázané na error rate a latenci, ne na to, že si toho někdo všimne. Pokud přijmete, že nezanedbatelná část tohoto kódu nese skryté špatné předpoklady, racionální odpověď je udělat cenu špatného předpokladu levnou na objevení a levnou na otočení, ne předstírat, že to dokážete předem ověřit pryč.

A nechte člověka vlastnit integrační hranice. Vnitřek si model může psát celý den, ale místa, kde se nový kód dotýká zbytku systému, kontrakty, datové tvary, ošetření chyb na švech, ta potřebuje držet v ruce člověk, který systému rozumí, protože to je přesně ten kontext, který model nemá a vaše test sada nekóduje.

Většina týmů, se kterými mluvím, si svou AI governance politiku nastaví reaktivně, ve válečné místnosti, týden poté, co jim vygenerovaná změna na čtyřicet minut položila checkout. To je špatná chvíle na to přemýšlet jasně o architektuře a politiky, které z těch schůzek vypadnou, bývají buď zbytečné divadlo, nebo plošný zákaz, který vaši vývojáři stejně do měsíce obejdou.

Lepší tah je sepsat si teď, dokud nic nehoří, že AI kód prochází jinou ověřovací cestou než lidský kód, a myslet to strukturálně, ne jako interní memo. To znamená jiné artefakty vyžadované v PR, jiná testovací data, jiné zacházení při deploy a jasné pravidlo, kterých částí systému se model smí dotýkat bez dozoru. Není to moc procesu a většinu z toho dobrý tým z půlky dělá už teď, rozdíl je v tom udělat to explicitní a udělat to defaultem místo výjimky, na kterou si vzpomenete ve dnech, kdy zrovna dáváte pozor.

Ve steezru stavíme spoustu nástrojů poháněných AI, automatizační pipeline, document processing, interní systémy, které hodně stojí na generovaném kódu, takže tohle není argument proti používání těchhle nástrojů. Používáme je pořád a zrychlují nás. Ten argument je užší. Pipeline, který jste postavili pro lidský kód, je špatný nástroj na ověřování strojového kódu, data od CloudBees a Lightrun jsou jen zvuk toho nesouladu, který konečně zesílil natolik, že se dá změřit, a týmy, které z roku 2026 vyjdou v dobré kondici, budou ty, co přestavěly ověřovací vrstvu místo toho, aby na ten starý pipeline přišroubovaly další bránu a doufaly, že příštích 43 % padne na někoho jiného.