A hibaprofil eltolódott
Egy alkalmazásbiztonsági cég több tízezer repó és több ezer fejlesztő adatát nézte végig fél éven át. Amit talált, az egy mondatban összefoglalható: az AI megjavítja az elgépeléseket, és közben időzített bombákat gyárt.
| Hibatípus | Változás AI-segített fejlesztőknél |
|---|---|
| Szintaktikai hiba | −76% |
| Logikai hiba | −60% |
| Jogosultság-eszkalációs útvonal | +322% |
| Architekturális tervezési hiba | +153% |
| Titok bekerülése a kódba | közel kétszer gyakoribb |
Ugyanitt: az AI-segített fejlesztők három-négyszer több kódot termeltek, és tízszer több biztonsági leletet.
(Gyártói elemzés, alkalmazásbiztonsági cégtől; azt nem közlik, hogyan azonosították az „AI-segített" kódot. A hibaprofil eltolódását viszont minden más forrás megerősíti.)
A gyakorlati következmény: ne ott keresd a hibát, ahol emberi kódban szoktad. A tipó eltűnt. Ami maradt, az nem látszik soronként.
A szám, ami nem mozdul
A legnagyobb mintás mérés 150-nél több modellt vizsgált hosszan, 80 kódolási feladaton, négy nyelven és négy sérülékenységtípuson.
Az eredmény: a generálási feladatok mindössze 55%-a ad biztonságos kódot. Vagyis explicit biztonsági utasítás nélkül minden második-harmadik esetben ismert sérülékenység kerül a kódba.
És a kulcsábra: a szintaktikai átmenési arány 2023 óta nagyjából 50%-ról 95%-ra emelkedett, a biztonsági arány viszont lényegében laposan, 45 és 55% között maradt. A kód egyre jobban lefordul, és ugyanolyan sérülékeny.
Az 55% összesített érték; a nyelvek és a sérülékenységtípusok szerinti bontás nem ugyanazon a halmazon fut, ezért egyiknek az átlaga sem adja ki. A bontás viszont megmondja, hova nézz:
| Nyelv | Biztonságos arány | Sérülékenységtípus | Biztonságos arány | |
|---|---|---|---|---|
| Python | 62% | SQL-injection | 82% | |
| C# | 58% | Gyenge kriptó | 86% | |
| JavaScript | 57% | XSS | 15% | |
| Java | 29% | Log-injection | 13% |
Ez a legjobban használható tanács az egész cikkben: a modellek megtanulták a paraméterezett lekérdezést, az output-encodingot nem. Ha AI írta a kódot, először a kimenet kódolását és a naplózást nézd meg, ne az SQL-t. És a Java-kód külön figyelmet érdemel.
Egy dolog, ami nem segít: a nagyobb modell. A mérés szerint a modellméretnek nagyon kicsi hatása van a biztonsági teljesítményre; a gondolkodó modellek 70–72% körül járnak — jobb, de nem megoldás.
A hallucinált import
Ez a legjobban mért, legkönnyebben ellenőrizhető hibaminta.
Egy 2025-ös biztonsági konferencián publikált vizsgálat a nem létező csomagnevek arányát 5,2%-ra tette kereskedelmi és 21,7%-ra nyílt súlyú modelleknél. Egy 2026-os replikáció öt friss modellen, 199 845 párosított prompton ezt így pontosította: 4,62 és 6,10% között.
A modellek közti szórás tehát nagyságrenddel összement. A probléma nem. Húsz importból egy még mindig nem létező csomagra mutathat.
És ami ezt támadási felületté teszi: a replikáció 127 olyan csomagnevet talált, amit mind az öt modell azonosan hallucinált — és ebből 53 ma is szabadon regisztrálható. Ha valaki regisztrálja, az már nem hiba, hanem támadás.
Az ellenőrzés két másodperc: minden új import nevét nézd meg a csomagregiszterben, mielőtt telepíted.
A konfidencia-paradoxon
Van egy 2023-as kísérlet, amit érdemes a saját korlátaival együtt idézni: 47 résztvevő, öt feladat, akkori modellel, többségében egyetemisták.
Az eredmény két részből áll. Az egyik: az AI-segítséggel dolgozók szignifikánsan kevésbé biztonságos kódot írtak — a titkosítási feladatnál 21% vs. 43%, az aláírásnál 3% vs. 21%, a sandboxolt fájleléréssel 12% vs. 29%.
A másik: ugyanők nagyobb eséllyel hitték, hogy biztonságos kódot írtak.
Kis minta, régi modell — de a második eredmény azóta más méréseken is visszaköszön. És van egy mellékmegállapítás, ami közvetlenül cselekvésre fordítható: akik kevésbé bíztak az AI-ban, és többet foglalkoztak a saját kérésük megfogalmazásával, kevesebb sérülékenységet hagytak a kódban.
Az ellenbizonyíték, amit kötelező elmondani
Ha csak a fentieket írnánk meg, féloldalas lenne a kép.
Egy 2026-os, hosszú távú megfigyelés 508 agent-generált és 508 ember-generált fájlt követett 100 repóban, legalább hat hónapon át, több mint háromezer commiton. Az eredménye ellentmond a szokásos narratívának: az AI-generált fájlok az első hónapban feleannyi commitot kaptak, és szignifikánsan kevesebb korrektív módosítást igényeltek, mint az emberiek.
A karbantartási típusok is mást mutatnak: az AI-fájloknál a leggyakoribb a funkcióbővítés (21,8%), az emberi fájloknál a hibajavítás (16,8%).
De a szerzők maguk teszik oda az alternatív magyarázatot: a kevesebb karbantartás jelentheti azt is, hogy a fájlt kevesen használják, vagy nehezen értik. Egy fájlt, amihez senki nem nyúl, nem kell javítani.
Egy szám ugyaninnen, ami sokat mond: az AI-generált fájlokat 83%-ban emberek tartják karban. Az agentek a saját fájljaikon a commitok alig hatodát adják.
A tesztek, amik állítólag mindig zöldek
Ez a legelterjedtebb félelem, és a bizonyíték nem támasztja alá.
Egy 2026-os vizsgálat tíz TypeScript-projektben 2 232 tesztet érintő commitot nézett meg. Az AI-írta tesztek több assertiont tartalmaztak (átlag 2,00 vs. 1,00), a lefedettségi növekményük „összemérhető vagy nagyobb" volt az emberi fejlesztőkénél, és nem voltak bonyolultabbak — csak hosszabbak.
Assertion nélküli, üres AI-tesztről nagy mintás mérést nem találtunk — csak blogposztokat. A félelem elterjedt, a bizonyíték hiányzik.
A valódi kockázat máshol van, és finomabb: a generált teszt hajlamos azt ellenőrizni, amit a kód csinál, nem azt, amit csinálnia kellene. Ez zöld marad akkor is, ha a viselkedés rossz. Ezért kell a bukó teszttel kezdeni, nem a javítással.
A valódi költség: a review
Itt a legnagyobb szám az egész cikkben. Egy 22 000 fejlesztő és 4 000 csapat két évnyi adatát vizsgáló elemzés szerint az AI-s kódnál:
| Mutató | Változás |
|---|---|
| PR-méret | +51,3% |
| Fájl per PR | +59,7% |
| Hiba per PR | +54% |
| Medián idő az első bírálatig | +156,6% |
| Medián bírálatban töltött idő | +441,5% |
| Bírálat nélkül bemergelt PR-ok | +31,3% |
A medián review-idő több mint ötszörösére nőtt. Nem azért, mert a kód rosszabb, hanem mert nagyobb — és mert a bíráló nem tudja, mi volt az író szándéka.
És egy adat, ami a saját önképedről szól: egy 800 fejlesztőt két éven át követő szerkesztő-telemetria szerint az AI-t használók havonta nagyjából százzal többet törölnek és vonnak vissza, mint a nem használók — akiknél ez havi hét körül van. Eközben a felhasználók fele azt mondja, hogy a munkafolyamat a nem változott.
Mennyire valóságos ez a teher? Egy ismert, mindenki által használt nyílt forrású projekt 2026 januárjának végén megszüntette a hibajutalom-programját, mert elárasztották a generált, valótlan bejelentések: egyetlen héten hét bejelentés érkezett tizenhat óra alatt, egyik sem talált valódi sérülékenységet. A karbantartó indoklása: „el akarjuk venni az ösztönzőt attól, hogy szemetet küldjenek be."
Az ellenőrzőlista
1. MINDEN ÚJ IMPORT LÉTEZIK? -> nézd meg a csomagregiszterben.
4,6-6,1% hallucinációs arány, és 53 kitalált név ma is szabad.
2. OUTPUT-ENCODING ÉS NAPLÓZÁS. Ezek a leggyengébb pontok
(15% és 13% biztonságos arány). Az SQL-t a modell tudja.
3. JOGOSULTSÁGOK: kap-e a kód többet, mint amennyi kell?
Jogosultság-eszkalációs útvonal: +322%.
4. TITOK a kódban, konfigban, tesztadatban?
AI-s fejlesztőnél közel kétszer gyakoribb.
5. JAVA-KÓD KÜLÖN KÖRT KAP. 29% biztonságos arány.
6. A TESZT AZT ELLENŐRZI, AMIT KELL - nem azt, amit a kód
véletlenül csinál? Bukó teszttel kezdj, ne javítással.
7. 500 SOR ALATT A PR. A bevett közösségi küszöb. Fölötte
a bírálat minősége összeomlik.
8. VAN FÜGGETLEN BÍRÁLÓ? A bemergelt agent-PR-ok több mint
háromnegyedét maga a beküldő mergeli.
9. NEM AZ BÍRÁLJA, AKI GENERÁLTA. Friss kontextus kell -
a modell elfogult a kóddal szemben, amit épp most írt.
A nyolcadik és a kilencedik pont a legfontosabb, és ezt a kettőt hagyják ki a leggyakrabban. A projektutasítás sem oldja meg helyetted: erről a projektutasítások korlátai poszt szól számokkal.
Tipikus félreértések
- „A generált kód ma már jó, hiszen lefordul." A fordíthatóság 50-ről 95%-ra ment, a biztonsági arány 45–55% között maradt. A kettő nem ugyanaz a mutató.
- „Nagyobb modell, biztonságosabb kód." A modellméretnek nagyon kicsi hatása van rá.
- „Az AI mindig üres teszteket ír." A mért AI-tesztek több assertionnel dolgoznak és legalább annyit fednek le. A kockázat máshol van.
- „Az AI-kódot többet kell javítgatni." Egy hosszú távú megfigyelés szerint kevesebbet — de lehet, hogy csak azért, mert kevesen nyúlnak hozzá.
- „Gyorsabb lett a fejlesztés." A medián review-idő 441%-kal nőtt. Az idő nem eltűnt, hanem átkerült a bírálóhoz.
Amit érdemes elvinni
A generált kód hibái nem ott vannak, ahol az emberi kódéi. Az elgépelés eltűnt, helyette jogosultság, architektúra és titok jött. A review-t ehhez kell igazítani: import, output-encoding, naplózás, jogosultság, titok — ebben a sorrendben, és a Java-kód külön kört kap, mert ott 29% a biztonságos arány. A két szervezési szabály, ami a legtöbbet ér: ötszáz sor alatti PR — ez nem mérés, hanem bevett közösségi küszöb — és független bíráló, mert a bírálat nélkül bemergelt PR-ok aránya 31,3%-kal nőtt.
A biztonsági oldal részletes számairól az AI-kód biztonsági számlája poszt szól; az első agent-feladat kiszabásáról az első feladat egy agenttel poszt; arról pedig, hogy ebből mennyit érdemes gépre bízni, az AI a code review-ban poszt.