AI által generált kód = új QA kihívások


Az AI asszisztensek (a GitHub Copilottól a különféle nagy nyelvi modellekig) néhány év alatt a szoftverfejlesztés mindennapi eszközévé váltak. Egy funkció, amelynek megírása korábban órákba telt, ma percek alatt elkészül. A fejlesztői produktivitás növekedése valós és mérhető.


Csakhogy a sebesség önmagában megtévesztő mutató. A kód gyorsabb megírása ugyanis nem jelenti azt, hogy a kód jobb lett, sőt, az eddigi adatok épp az ellenkezőjére figyelmeztetnek. Az AI nem eltünteti a minőségbiztosítás szükségességét, hanem átalakítja és felértékeli azt. Ez a cikk arról szól, hogy pontosan milyen új kockázatokat hoz az AI által generált kód, és miért lesz emiatt a független QA szerepe fontosabb, nem pedig kevésbé fontos.


Gyorsabb kód, több ismétlés: mit mutatnak az adatok?


Az egyik leggyakoribb tévhit, hogy az AI asszisztens „tapasztalt szenior fejlesztőként” dolgozik. A valóságban az AI a betanított mintázatok alapján a statisztikailag legvalószínűbb kódot állítja elő, ami nem feltétlenül a legkarbantarthatóbb vagy a projektbe legjobban illeszkedő megoldás.


A GitClear 2025-ös kutatása, amely 211 millió sornyi kódváltozást elemzett 2020 és 2024 vége között, konkrét számokkal támasztja alá ezt az aggodalmat:

  • A másolt és beillesztett kód aránya megugrott, az újrahasznosításé pedig visszaesett. A „mozgatott” (azaz újrahasznosított, refaktorált) kód aránya 25%-ról 10% alá csökkent 2021 és 2024 között, míg a másolt és beillesztett kódé 8,3%-ról 12,3%-ra nőtt. 2024-ben a másolt kód először előzte meg az újrahasznosítottat, ami a karbantarthatóság romlásának egyik klasszikus jele.
  • Ugrásszerűen nőtt a kódduplikáció: 2024-ben nyolcszorosára emelkedett azoknak a beadott változtatásoknak a száma, amelyek öt vagy több sornyi duplikált kódblokkot tartalmaztak.
  • Nőtt a „kódégés” (code churn): a rövid időn belül átírt vagy visszavont kód aránya a 2021-es 3,3%-ról 5,7%-ra emelkedett 2024-re, közel a duplájára. Vagyis egyre több frissen megírt kódot kell szinte azonnal korrigálni.


Üzleti nyelvre lefordítva: az AI felgyorsítja a kódírást, de ezzel párhuzamosan gyorsabban termeli a technikai adósságot is. A ma megspórolt fejlesztői óra könnyen holnapi karbantartási költséggé válik, és ahogy azt a Mennyi pénzbe kerül egy későn megtalált hiba? című cikkünkben bemutattuk, minél később derül ki egy probléma, annál drágább a javítása.


A veszélyes csapda: a magabiztosság, amit nem fed le tudás


Az AI által generált kód legalattomosabb kockázata nem az, hogy hibás. Hanem az, hogy meggyőzően néz ki.


A hagyományos, kézzel írt hibás kód gyakran „gyanús”, a fejlesztő érzi, hogy valami nem stimmel. Az AI viszont szintaktikailag tökéletes, jól formázott, magabiztos kódot ad, amely elsőre teljesen rendben lévőnek tűnik, miközben logikailag hibás lehet, elavult könyvtárat használ, vagy biztonsági rést tartalmaz. Ez felerősíti a „másolás és beillesztés” kultúrát: a fejlesztők mély megértés nélkül fogadnak el bonyolult kódblokkokat, mert működni látszanak.


És itt jön a legfontosabb adat, amelyet minden technológiai vezetőnek ismernie kellene.


A Veracode 2025-ös GenAI Code Security elemzése több mint 100 nagy nyelvi modellt tesztelt 80 valós kódolási feladaton, négy programozási nyelven. Az eredmény kijózanító: az AI által generált kód 45%-a tartalmazott ismert biztonsági sérülékenységet, például SQL injekciót, cross-site scriptinget vagy gyenge titkosítást. De a legfontosabb tanulság a trendben van, nem a pillanatképben:

  • Az AI ma már a kódok több mint 95%-át szintaktikailag helyesen állítja elő, vagyis „működik” és jól néz ki.
  • A biztonsági megfelelés viszont makacsul ~55%-on stagnál, gyakorlatilag változatlanul két éve, miközben a modellek funkcionális képessége közben látványosan javult.


Magyarra fordítva: az újabb, nagyobb, „okosabb” modellek nem írnak biztonságosabb kódot. A Veracode 2026 tavaszi frissítése ugyanezt erősítette meg. A képesség nő, a biztonsági érettség nem követi, épp ezért nem lehet a minőség kérdését „majd a következő modell megoldja” alapon elhalasztani.


Van azonban egy még alattomosabb hatás, amely nem a kódról, hanem a fejlesztőről szól. A METR 2025-ös randomizált, kontrollált kísérletében tapasztalt fejlesztők valós feladatokon dolgoztak, saját, jól ismert projektjeiken. Azt várták, hogy az AI ~24%-kal gyorsítja őket. A valóságban 19%-kal lassabbak lettek vele, utólag mégis úgy érezték, hogy 20%-kal gyorsabbak voltak. A becslés és a mérés között tátongó szakadék a cikk lényege: az AI nemcsak a hibák valószínűségét növelheti, hanem elaltatja az éberséget is. Rosszabb (vagy épp lassabban készülő) eredmény, nagyobb magabiztossággal: ez a kombináció az, ami vezetői szemmel a legveszélyesebb, mert éppen a belső önellenőrzést gyengíti.


(A teljesség kedvéért: a METR kísérlet kis mintás [16 fejlesztő], és maga a kutatócsoport is jelezte, hogy az azóta fejlődött eszközökkel a kép változhatott. A tanulság nem az, hogy „az AI lassít”, hanem hogy a saját gyorsaságunkról alkotott érzésünk megbízhatatlan. Épp ez teszi kockázatossá.)


„De a legújabb modellek sokkal jobbak, ez nem oldja meg a gondot?”


Jogos ellenvetés, és őszintén kell rá válaszolni. 2025 vége óta a vezető modellek (a Claude és a Gemini legújabb generációi) ugrásszerűen fejlődtek: a nyilvános kódolási benchmarkokon (például a SWE-bench Verified méréseken) ma a valós fejlesztői feladatok túlnyomó többségét megoldják, szemben az egy évvel korábbi jóval alacsonyabb aránnyal. A kontextusablak a milliós nagyságrendbe nőtt, és a modellek „megértése” érezhetően javult. A saját fejlesztéseink tapasztalata is ez: az AI ma jobb minőségű kódot ad, mint egy éve. Ezt nincs értelme tagadni.


A kérdés viszont nem az, hogy jobb lett-e a kód, hanem hogy csökken-e emiatt a tesztelési igény. A 2026-os adatok szerint épp az ellenkezője igaz:

  • A szervezeti kód 61%-a ma már AI által generált vagy AI-jal segített (2026-os felmérés).
  • A pull requestek, amelyek korábban 50 sorosak voltak, ma gyakran 500 sorosak. A reviewer átfutja, a hiba pedig átcsúszik.
  • Az AI-jal segített fejlesztés 1,7-szer annyi logikai és helyességi hibát termel, mint a hagyományos.
  • A megkérdezett QA mérnökök 70%-a szerint ma a tesztkészlet karbantartása nagyobb teher, mint magának a kódnak a megírása.
  • A GitClear 2026-os kutatása szerint a kódduplikáció 81%-kal magasabb, mint 2023-ban.


A jobb modell tehát nem kiváltja a tesztelést, hanem megnöveli a mennyiséget, amit tesztelni kell. Több kód, gyorsabban, ez nagyobb tesztelendő felületet és több hibalehetőséget jelent, nem kevesebbet. A funkcionális képesség közben látványosan nőtt, a biztonsági érettség viszont (ahogy a Veracode adatai mutatják) nem tartott vele lépést. A minőség kérdése így nem eltűnik, hanem áttolódik: a „működik-e egyáltalán” kérdésről a „biztonságos, karbantartható, és tényleg azt csinálja-e, amit az üzlet akar” kérdésre.


Mi változik a QA-ban? Megnő a felület, csökken az éberség


Az AI két ellentétes irányból is nyomást helyez a minőségbiztosításra:

  • Nő a tesztelendő felület. Ha ugyanannyi fejlesztő egységnyi idő alatt többszörös mennyiségű kódot termel, akkor a tesztelendő kódmennyiség (és vele a lehetséges hibák száma) is együtt nő. Több kód, több integrációs pont, több potenciális töréspont.
  • Csökken a beépített önellenőrzés. Ahogy a METR kísérlet mutatja, a fejlesztői magabiztosság épp akkor nő, amikor a legnagyobb szükség lenne a kételkedésre. Az a „négy szem elve”, amely eddig a fejlesztő saját éberségére is támaszkodott, meggyengül.


A kettő együtt egyértelmű következtetéshez vezet: az AI korában a független, külső minőségellenőrzés nem luxus, hanem szükségszerűség. Épp azért, mert a kódot generáló eszköz és az azt elfogadó fejlesztő ugyanabba a magabiztossági csapdába eshet, kell egy olyan szereplő, aki kívülről, elfogulatlanul kérdez rá: tényleg azt csinálja ez a kód, amit gondolunk róla? A megerősítési torzítás és a vakfoltok természetéről a Miért nem szabad a fejlesztőnek a saját kódját tesztelnie? című cikkünkben írtunk részletesen: az AI ezt a jelenséget nem megszünteti, hanem felerősíti.


Mi marad továbbra is emberi feladat?


Fontos leszögezni: ez a cikk nem az AI ellen szól. Az AI kiváló eszköz, de eszköz, nem mérnök. Vannak területek, amelyeket belátható ideig nem fog átvenni:

  • Az üzleti kontextus megértése. Az AI nem ismeri a vállalat egyedi üzleti logikáját, a szabályozási környezetet, a valós felhasználói igényeket. Egy kód lehet technikailag hibátlan, miközben rossz üzleti szabályt valósít meg.
  • A rendszerszintű összefüggések átlátása. Az AI jellemzően lokálisan, egy adott feladatra optimalizál. Azt, hogy egy változtatás milyen hatással van a teljes rendszerre, az integrációkra és a harmadik felekre, továbbra is emberi mérnöki ítélőképesség dönti el.
  • A felhasználói élmény (UX) megítélése. Hogy egy funkció valóban használható, érthető és kényelmes-e a végfelhasználónak, az emberi megítélés kérdése marad.
  • A kritikus kételkedés. A tesztelő alapállása („hol és hogyan törhet el ez?“) pontosan az az emberi szemlélet, amelyet az AI a magabiztos kimeneteivel a leginkább kikezd.


Az AI tehát nem kiváltja, hanem átrendezi a szerepeket: az emberi fókusz a monoton kódgenerálásról a felülvizsgálat, a kontextus és a kritikus ellenőrzés felé tolódik.


Összegzés


Az AI által generált kód nem rosszabb annál, hogy használjuk, de más, és más kockázatokkal jár. Gyorsabban készül, ugyanakkor gyorsabban termel technikai adósságot; meggyőzően néz ki, miközben elaltathatja az éberséget; és felduzzasztja a tesztelendő felületet, épp amikor a beépített önellenőrzés gyengül.


A helyes vezetői válasz nem az AI elutasítása, és nem is a fenntartás nélküli lelkesedés. Hanem annak felismerése, hogy minél gyorsabban termeljük a kódot, annál fontosabb a független minőségellenőrzés: az a külső szem, amelyet sem a modell, sem az azt használó fejlesztő magabiztossága nem tud pótolni.


Források

  • Veracode: 2025 GenAI Code Security Report (80 feladat, 100+ nagy nyelvi modell; a biztonsági megfelelés stagnálásáról). Elérhető: veracode.com; 2026 tavaszi frissítés: veracode.com/blog
  • METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (2025), randomizált kontrollált kísérlet a produktivitásról és az önértékelés torzításáról. Elérhető: metr.org
  • GitClear: AI Copilot Code Quality 2025 kutatás (211 millió sornyi kódváltozás elemzése, 2020 és 2024 között). Elérhető: gitclear.com
  • GitClear: The Maintainability Gap: 2026 AI Code Quality Research (a kódduplikáció 2026-os alakulásáról). Elérhető: gitclear.com
  • A modellek kódolási képességének méréséhez: SWE-bench Verified nyilvános benchmark, valamint 2026-os iparági QA felmérések az AI által generált kód tesztelési hatásairól

Megosztás

Kérsz értesítést a legújabb cikkekről?

Kapcsolódó cikkek

Mit jelent egy sikeres release a CIO szemével?

Kérdezz meg egy fejlesztőt, mikor volt sikeres egy kiadás, és nagy eséllyel ezt hallod: „lefutott a pipeline, a kód bement a main ágba, nem dobott hibát a telepítés.” Technikailag tökéletes válasz. És egy CIO számára mégis szinte irreleváns. Mert egy vezető nézőpontjából a release nem akkor sikeres, amikor a kód kiment. Hanem akkor, ha másnap

Shift Left már nem elég: merre tart a modern szoftvertesztelés?

Van egy elv, amelyet a szoftvertesztelésben évek óta bölcsességként adnak tovább: „tesztelj korán és gyakran”. Ez a Shift Left szemlélet lényege, és sokáig ez jelentette a modern minőségbiztosítás csúcsát. A logikája megcáfolhatatlan: minél korábban találjuk meg a hibát, annál olcsóbb kijavítani. Csakhogy a mai szoftverek már nem úgy néznek ki, mint húsz éve. Egy modern

Miért nem szabad a fejlesztőnek a saját kódját tesztelnie?

A fejlesztő megírja a funkciót. Megírja hozzá a teszteket is – alaposan, lelkiismeretesen. Minden teszt zöld. A kód átmegy a pipeline-on, kimegy élesbe. Két héttel később a rendszer elhasal egy olyan eseten, amire senki nem gondolt. A tesztek nem hazudtak. Egyszerűen nem a jó kérdést tették fel. Ez a cikk nem arról szól, hogy a

Scroll to Top