Agentní AI potřebuje více testerů, ne méně

Agentní AI mění způsob, jakým se dodává software. Asistenti připravují pull requesty, agenti otevírají migrace a roboti pro kontrolu kódu tvrdí, že je změna bezpečná, ještě než člověk dopije kávu. Průmysl to často líčí jako cestu k menšímu počtu lidí v oblasti kvality. Tento pohled je mylný. Čím větší část kódové základny píší stroje, tím vzácnější dovedností není generování kódu. Je jí nezávislé ověřování.

Průzkum vývojářů Stack Overflow z roku 2025 zjistil, že 84 % respondentů používá nebo plánuje používat při vývoji nástroje AI a 51 % profesionálních vývojářů je používá denně. Pozitivní postoje klesly na 60 % a správnosti AI aktivně nedůvěřuje více vývojářů (46 %), než kolik jí důvěřuje (33 %). Nejčastěji uváděnou frustrací, kterou zmínilo 66 % respondentů, byla řešení, která jsou téměř správná, ale ne tak docela. Google Cloud ve svém výzkumu DORA z roku 2025 uvedl, že AI používá 90 % odborníků na vývoj softwaru a více než 80 % z nich tvrdí, že AI zvýšila jejich produktivitu. Jen 24 % však uvedlo, že AI důvěřuje hodně nebo velmi. Právě užitečnost bez důvěry rozšiřuje práci testerů, místo aby ji omezovala.

Rychlost není důkaz

Pracuji jako inženýr kvality softwaru a zaměřuji se na agentní testování a brány CI pro kód vytvořený pomocí AI. U nás jsme nasadili nástroj pro kontrolu PR a generátor testovacích případů. Oba slouží k přípravě návrhů. Ani jeden si nehodnotí vlastní práci. Toto pravidlo je důležité, protože agenti mluví s jistotou. Jistota však neznamená správnost.

Přesvědčili jsme se o tom drahým způsobem. Při pilotním provozu nástroje pro kontrolu PR vytvořeného pomocí AI prošla jedna změna CI za méně než 4 minuty. O dva dny později zobrazil navazující řídicí panel nemožné teploty. Na jedné cestě kódem, kterou testovací sada nikdy neprověřila, došlo k záměně převodu ze stupňů Celsia na stupně Fahrenheita. CI bylo zelené. Produkt byl chybný. Zelené CI, které nepoloží tu podstatnou otázku, je jen divadlo.

Tento incident zapadá do širšího vzorce. Zpráva CodeRabbit Stav generování kódu pomocí AI ve srovnání s lidmi analyzovala 470 open-source pull requestů na GitHubu (320 vytvořených ve spolupráci s AI, 150 výhradně lidmi). Změny vytvořené pomocí AI vedly celkově přibližně k 1,7× většímu počtu problémů; potíže s logikou a správností se vyskytovaly o 75 % častěji a počet bezpečnostních zjištění byl až 2,74× vyšší. Zpráva Veracode o zabezpečení kódu generovaného AI z roku 2026 testovala modely v různých bezpečnostních úlohách a zjistila průměrnou úspěšnost v bezpečnostních testech 56 %, tedy jen nepatrně vyšší než 55 % v předchozí zprávě. Přibližně 44 % úloh generování kódu pomocí AI přitom vedlo k zavedení známé zranitelnosti. Syntaxi už máme téměř vyřešenou. Bezpečné a správné chování nikoli. Testeři jsou ti, kdo odmítají tyto dvě věci zaměňovat.

Halucinované závislosti jsou problém pro testování

Generování vytváří i smyšlené balíčky. Výzkum USENIX Security 2025 Máme pro vás balíček! vyhodnotil halucinace názvů balíčků u 16 velkých jazykových modelů pro generování kódu a na 576 000 vzorcích. Komerční modely si v průměru vymýšlely balíčky nejméně v 5,2 % případů; u open-source modelů to bylo v průměru 21,7 % případů a vzniklo 205 474 jedinečných smyšlených názvů. Dlouhodobě přetrvávající falešné balíčky vytvářejí snadný cíl pro útoky typu slop squatting: útočníci zaregistrují vymyšlený název a čekají, až si jej vývojář nebo agent nainstaluje.

Kontroly původu závislostí patří na stejnou úroveň jako funkční testy. Pokud agent vymyslí balíček NuGet nebo npm, sloučení změny by se mělo zastavit dřív, než se začne řešit, zda byly jednotkové testy dostatečně důkladné. Ověřování původu není volitelná součást základní hygieny. Je to kvalitativní brána pro změny vytvořené pomocí AI.

Brány, které se škálují spolu s agenty

Když jsme pomocí automatizace s podporou AI provedli v celé organizaci upgrade z .NET 8 na .NET 10 zhruba za dva týdny, měl jsem na starosti kvalitativní brány. Rychlost byla skutečná. Stejně skutečná byla i potřeba kontrol, které slepě nevěří shrnutí od agenta. Mezi brány, které u změněného kódu používám, patří:

• Cílové skóre mutačního testování v rozmezí 60 % až 70 % u upravené logiky, aby testovací sada musela odhalovat skutečné mutanty, nejen pokrývat řádky kódu
• Testy založené na vlastnostech u vysoce rizikové logiky, kde samotné příklady nedostatečně určují očekávané chování
• Kontroly původu závislostí, které brání útokům typu slop squatting a halucinovaným balíčkům
• Ukazatele duplicity a četnosti změn, které odhalují agentní překotné kopírování a vkládání
• Nezávislé ověřování tvrzení agentů, například „migrace dokončena“, protože tvrzení je jen hypotéza, dokud se neobjeví důkazy

Skóre mutačního testování není ukazatel pro parádu. Ukazuje, zda vaše testy zaznamenají záměrně zavedenou chybu. Pokrytí kódu může růst, a přesto může testovací sada přehlédnout cestu převodu ze stupňů Celsia. Testy založené na vlastnostech ověřují, že model systému platí v celém rozsahu hodnot, nejen v jednom ideálním scénáři. Kontroly původu uzavírají dveře ke skladům balíčků. Ukazatele četnosti změn a duplicit odhalují sklon agentů přepisovat tutéž myšlenku třemi různými způsoby. Dohromady tvoří přístup založený na předpokladu, že se agent mýlí, dokud testovací sada neprokáže opak. Tuto zásadu si při kontrole kódu hlídám.

Nic z toho nenahrazuje testování API, ověřování autentizace, testy základního provozu ani automatizaci uživatelského rozhraní. FlaUI a PowerShell stále odhalují problémy, které testům API uniknou. Balení prostřednictvím NuGet, MSI a MSM stále vyžaduje ověření instalace i bezobslužného průběhu. Agentní pracovní postupy zvyšují objem práce. Tyto postupy však nenahrazují.

Více testerů, jiná práce

Obavou je, že testy budou psát agenti a lidé přestanou být potřeba. Agenti mohou navrhovat testovací případy. Neměli by však své vlastní návrhy sami schvalovat. Respondenti Stack Overflow, kteří plánují v budoucnu využívat AI k testování, stále považují nedůvěru lidí za zásadní: když by požádali o pomoc někoho jiného, hlavním důvodem byla nedůvěra k odpovědím AI. Právě tento instinkt je předností této profese.

Je důležité přijímat a podporovat lidi, kteří se k této práci dostali netradiční cestou. Po kariéře v HR provozu a práci s daty jsem přešel do oblasti kvality, v květnu 2024 dokončil magisterské studium informačních systémů na UMBC a dnes se věnuji tomu, aby byly brány pro agentní AI prakticky použitelné. Agentní AI nebude čekat na jediný správný profesní profil. Potřebuje více lidí, kteří dokážou navrhovat důkazy, ne méně lidí, kteří bezmyšlenkovitě schvalují úspěšná sestavení.

Otázka ohledně produktu je jednoduchá. Pokud agenti vydávají změny rychleji, než je vaše ověřování dokáže promyslet, nejde o zvýšení produktivity. Jen odkládáte incident. Investujte do testerů, kteří považují každé tvrzení agenta za podezřelé, začleňují mutační testování a provenienci do CI a zachovávají si nezávislý úsudek právě tam, kde je model nejvýřečnější a nejméně spolehlivý. Agentní AI potřebuje více testerů, ne méně.