Kód psaný AI: co říkají data o bezpečnosti, kvalitě a proč je úzkým hrdlem code review

Bezpečnost: modely píší lépe, ale ne bezpečněji

Nejcitovanějším zdrojem je GenAI Code Security Report společnosti Veracode z července 2025. Testoval přes 100 jazykových modelů na úlohách v Javě, Pythonu, C# a JavaScriptu a došel k závěru, že 45 % ukázek kódu neprošlo bezpečnostními testy a obsahovalo zranitelnost z OWASP Top 10. Nejhůř dopadla Java se 72 % neúspěšných ukázek, u cross-site scriptingu (CWE-80) modely selhaly v 86 % relevantních případů.

Podstatnější než samotné číslo je trend. Zpráva konstatuje, že modely se zlepšovaly ve funkční správnosti kódu, ale bezpečnost zůstávala plochá bez ohledu na velikost modelu a propracovanost tréninku.

Aktualizace z března 2026, která zahrnula i tehdy nejnovější vlajkové modely, to potvrzuje: úspěšnost v bezpečnostních testech zůstává přibližně na 55 %. Rozdíly jsou hlavně mezi typy chyb a jazyky:

Jedinou výraznější výjimkou jsou podle téže aktualizace modely zaměřené na reasoning, které dosáhly 70–72 %.

Kvalita a udržovatelnost: víc kopírování, méně refaktoringu

Druhá otázka je, co AI dělá s kódovou bází v čase. Společnost GitClear ve zprávě The Maintainability Gap (2026) analyzovala 623 milionů změn kódu z let 2023–2026. Ukazatel duplikovaných bloků (na milion změněných řádků) vzrostl z 40,3 v roce 2023 na 73,0 v roce 2026, tedy o 81 %. Podíl přesouvaného kódu, který autoři používají jako znak refaktoringu, klesl z 13 % změněných řádků v roce 2023 na 3,8 % v roce 2026, zatímco podíl copy/paste vzrostl z 9,4 % v roce 2022 na 15,7 % v první polovině roku 2026. Zrychlení intenzivních uživatelů AI oproti jejich vlastní minulosti přitom zpráva vyčísluje na 25 %.

I tady platí opatrnost: GitClear je dodavatel analytického nástroje a jde o korelaci v čase, ne o experiment. Směr je ale konzistentní s tím, jak asistenti fungují – přidat nový blok je pro model snazší než najít a znovu použít existující funkci. Dluh se neprojeví v den merge, ale při první větší změně.

Na úrovni dodávky to potvrzuje DORA report 2025 (téměř 5 000 respondentů, září 2025). AI v práci používá 90 % dotázaných a přes 80 % věří, že jim zvýšila produktivitu. Oproti předchozímu roku už výzkum vidí pozitivní vztah mezi AI a propustností dodávky, ale vztah ke stabilitě dodávky zůstává negativní. Vysvětlení autorů: AI zrychluje vývoj a větší objem změn odhalí slabiny dál v řetězci – bez silného automatického testování, zralé správy verzí a rychlé zpětné vazby vede k nestabilitě.

Produktivita: méně jistoty, než tvrdí titulky

Studie METR z července 2025 se stala argumentem skeptiků: 16 zkušených vývojářů velkých open-source projektů řešilo 246 úloh a s povolenými AI nástroji jim práce trvala o 19 % déle. Předem přitom čekali zrychlení o 24 % a i po skončení věřili, že je AI zrychlila o 20 %.

Méně známé je pokračování. V aktualizaci z 24. února 2026 METR uvádí novější data: u deseti vývojářů z původní studie vyšel odhad −18 % (interval spolehlivosti −38 % až +9 %), u 47 nově zapojených −4 % (−15 % až +9 %); záporné číslo zde znamená kratší čas s AI. Zároveň ale METR design experimentu mění, protože přestal být spolehlivý: 30–50 % vývojářů přiznalo, že některé úlohy do studie vůbec nezadávali, protože je bez AI dělat nechtěli. Výsledek proto sám označuje jen za velmi slabý důkaz o velikosti zrychlení.

Pro vedení z toho plynou dvě věci. Zaprvé, subjektivní pocit zrychlení není měření – v původní studii se od reality lišil o desítky procentních bodů. Zadruhé, ani nejlepší dostupný výzkum dnes neumí říct, o kolik přesně AI zrychluje zkušený tým na vlastním kódu. Rozhodovat podle jedné studie, ať už vyzněla jakkoli, je chyba.

Proč se úzkým hrdlem stalo review

Když psaní kódu zlevní, fronta se přesune tam, kde kapacita zůstala stejná. Telemetrie společnosti Faros AI z více než 10 000 vývojářů v 1 255 týmech (AI Productivity Paradox, 2025) to ukazuje přímo: vývojáři v týmech s vysokou adopcí AI dokončí o 21 % víc úkolů a sloučí o 98 % víc pull requestů, ale doba review roste o 91 %, průměrná velikost PR o 154 % a počet chyb na vývojáře o 9 %. Na úrovni celé firmy přitom autoři významnou korelaci mezi adopcí AI a zlepšením nenašli.

Se stejným mechanismem pracuje i DORA ve zprávě o návratnosti AI z roku 2026. Podle shrnutí serveru InfoQ popisuje dočasný propad produktivity po zavedení AI (křivka J) a jako jednu z jeho tří příčin uvádí „verification tax“ – daň za ověřování AI generovaného kódu při review. Ukázková kalkulace ve zprávě počítá s růstem podílu neúspěšných změn z 5 na 6 %.

Že je ověřování skutečnou prací, a ne formalitou, vědí i sami vývojáři. Ve Stack Overflow Developer Survey 2025 AI používalo nebo plánovalo používat 84 % respondentů, ale přesnosti výstupů nedůvěřovalo 46 % a důvěřovalo 33 %. Nejčastější frustrací (66 %) byla řešení, která jsou „skoro správně, ale ne úplně“; 45 % uvedlo, že ladění AI kódu zabere víc času.

Ročník 2026, zveřejněný 6. října 2026, se ptal jinak a výsledek je výmluvný: 48 % respondentů AI věří tehdy, když mohou výstup snadno ověřit. Jen 7 % jí věří u mnoha úkolů včetně důležitých pracovních rozhodnutí a 12 % jí u většiny pracovních úkolů nevěří. Stack Overflow z toho vyvozuje, že „nějakou míru důvěry“ má přes 87 % lidí oproti 31 % o rok dříve; protože se ale změnily nabízené odpovědi, je meziroční srovnání jen orientační. Praktický závěr je jiný: důvěra je podmíněná ověřitelností. A ověřitelnost je vlastnost procesu, ne modelu.

Automatické gates: co má stroj zachytit dřív než člověk

Reviewer by neměl hledat SQL injection ani zapomenutý token – to umí nástroje levněji a spolehlivěji. Minimální sada kontrol, které mají blokovat merge:

• Secrets scanning – už v pre-commit hooku a znovu v pipeline.
• SAST – s pravidly pro třídy chyb, kde modely selhávají nejčastěji (XSS, log injection, neošetřené vstupy).
• SCA a kontrola závislostí – známé zranitelnosti, licence a každá nově přidaná závislost. Podrobněji v článku o skenování závislostí.
• Testy a pokrytí změněného kódu – ne globální procento, ale pokrytí diffu.
• Sken IaC a kontejnerů – pokud agent generuje i Terraform, Dockerfile nebo manifesty.

Kostra takové pipeline (ilustrativně, v syntaxi GitHub Actions; konkrétní nástroje zvolte podle svého stacku):

name: pr-gates
on: pull_request

jobs:
  gates:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<commit-sha>
      - name: Secrets
        run: gitleaks detect --redact
      - name: SAST
        run: semgrep scan --config auto --error
      - name: Závislosti (SCA)
        run: trivy fs --scanners vuln --exit-code 1 --severity HIGH,CRITICAL .
      - name: Testy
        run: make test
      - name: Velikost PR
        run: ./scripts/check-pr-size.sh 400   # vlastní skript, limit řádků diffu

Gates musí být povinné (branch protection) a platit stejně pro lidi i pro agenty. Jak je poskládat do celku, popisuje stránka ideální pipeline a článek o bezpečnosti CI/CD.

Slopsquatting: závislost, která neexistuje

Specifickým rizikem AI kódu jsou vymyšlené balíčky. Studie prezentovaná na USENIX Security 2025 vygenerovala 576 000 ukázek kódu z 16 modelů: komerční modely doporučily neexistující balíček nejméně v 5,2 % případů, open-source modely ve 21,7 %. Výzkumníci nasbírali 205 474 unikátních vymyšlených názvů. Útočníkovi stačí takový název zaregistrovat ve veřejném registru a počkat, až ho někdo nainstaluje.

Obrana je procesní: instalace jen z lockfile, nové závislosti přes interní proxy registr nebo allowlist, review každého nového balíčku (stáří, autor, počet stažení) a zákaz, aby agent instaloval balíčky bez schválení.

Malé PR, testy a pravidla pro agenty

Automatika zachytí známé třídy chyb. Zbytek – zda změna dělá to, co má, a zda zapadá do architektury – zůstává na lidech. Aby to stíhali, musí se změnit vstup do review.

Malé dávky

Agent bez omezení vyprodukuje velký PR stejně snadno jako malý. Nastavte limit velikosti diffu a nechte agenta práci dělit: jedna změna, jeden záměr. Refaktoring a změnu chování nemíchejte v jednom PR.

Testy jako specifikace

Test napsaný stejným modelem ve stejném kroku jako implementace často jen potvrzuje, co kód dělá, ne co dělat má. Užitečnější je, když akceptační kritéria nebo testy vzniknou předem a reviewer čte nejdřív je.

Pravidla v repozitáři

Soubor s instrukcemi pro agenta (například AGENTS.md nebo obdoba podle nástroje) by měl obsahovat to, co se jinak předává ústně: jak spustit testy a linter, které knihovny používat pro validaci vstupů, šifrování a logování, co agent nesmí (přidávat závislosti, měnit CI, sahat na migrace bez pokynu). Instrukce nejsou bezpečnostní hranice – model je může ignorovat –, proto musí stejná pravidla vynucovat pipeline.

Odpovědnost autora

Kdo PR otevírá, ručí za něj, ať ho psal sám, nebo agent. V popisu PR má být, co se změnilo, proč a jak to bylo ověřeno. AI review jako první průchod pomůže odfiltrovat zjevné chyby, ale nenahrazuje schválení člověkem, který kód vlastní.

Kdy tato doporučení neplatí a co říkají kritici

• Prototypy a jednorázové skripty. U kódu, který nepůjde do produkce a nepracuje s citlivými daty, je plná sada gates zbytečná režie. Hranici ale definujte předem – prototypy mají tendenci v produkci skončit.
• Laboratorní benchmarky nejsou vaše kódová báze. S kontextem projektu, bezpečnostními instrukcemi a zpětnou vazbou z nástrojů mohou být výsledky lepší než u Veracode. Ověřit to lze jen vlastním měřením.
• Většinu dat publikují dodavatelé. Veracode, GitClear i Faros AI prodávají nástroje, které popsaný problém řeší. Nezávislé zdroje (DORA, METR, USENIX) míří stejným směrem, ale s menší jistotou ohledně velikosti efektu.
• Příliš přísné gates škodí. Když pipeline blokuje falešnými nálezy, lidé ji začnou obcházet. Začněte s blokováním vysokých závažností a pravidla laďte.
• Čísla rychle stárnou. Modely i nástroje se mění po měsících; samo METR přiznává, že jeho metoda přestala stačit. Platnost má spíš mechanismus (rychlejší psaní → tlak na ověření) než konkrétní procenta.

Co udělat v pondělí

Klíčové poznatky

• Bezpečnost AI kódu stagnuje. Podle Veracode projde bezpečnostními testy zhruba 55 % ukázek i u modelů z roku 2026; nejslabší jsou XSS, log injection a Java.
• Úzké hrdlo se přesunulo. Víc PR a větší PR znamenají delší review; zisk jednotlivce se na úrovni organizace nemusí projevit.
• Produktivitu nikdo neumí přesně změřit. Pocit zrychlení není důkaz a i METR své novější výsledky označuje za slabé.
• Důvěra stojí na ověřitelnosti. Skoro polovina vývojářů věří AI jen tehdy, když výstup snadno ověří – a to zajišťuje pipeline, ne model.
• Stroj má chytat známé chyby, člověk posuzovat záměr. Secrets, SAST, SCA a testy jako povinné gates; lidské review pro architekturu a logiku.
• Závislosti jsou nový vektor. Vymyšlené balíčky nejsou kuriozita, ale měřitelný a zneužitelný jev.