A szám, amiből minden következik
Van egy mérés, ami pontosan azt csinálja, amit ilyenkor kellene: nem tesztet futtat, hanem véletlenszerű bemenetek ezreivel hasonlítja össze az eredeti és az átalakított kód viselkedését. Programonként ezer-kétezer bemenet, fekete dobozként, hat különböző modellel.
| Mit mértek | Érték |
|---|---|
| Funkcionálisan hibás refaktorálás | 18,6–35% |
| Ebből egyszerűbb feladatokon | 22,1% |
| Nehezebb feladatokon | 32,1% |
| A legjobb modell | 18,6% |
| A legrosszabb | ~35% |
| A hibás refaktorálásokból átment minden meglévő teszten | 21,65% |
Az utolsó sor a lényeg. Nem az a baj, hogy a modell hibázik — hanem hogy a hibáinak több mint egyötödét a meglévő tesztkészlet nem fogja meg.
Számoljuk ki, mit jelent ez:
nem-ekvivalens refaktorálás: 22,1%
ebből a tesztkészlet NEM fogja meg: 21,65%
csendben viselkedést változtat ÉS zöld:
0,221 × 0,2165 = 0,0478 -> ~4,8%
nehezebb feladatokon:
0,321 × 0,2165 = 0,0695 -> ~7,0%
(Saját számítás; mindkét alapszám publikált. A mérés preprint.)
Minden huszadik átalakítás csendben mást csinál, mint előtte. Ez az a hibafajta, ami nem összeomlik, hanem rossz számot ad — és hetekkel később derül ki.
A trend javul, de nem nulla
Van egy nagyobb mintás, lektorált vizsgálat is: több mint ezer Java- és Python-kódrészletből 8 096 refaktorált változat, négy modellel.
Az eredmény: 928 refaktorált részlet mutatott viselkedési eltérést, 180 esetben teljes kudarccal. A trend viszont biztató: a 2023-as modelleknél az arány nagyjából 17% volt, a 2025-öseknél 6,06%.
És van egy mért mérséklési stratégia is, ami 17,17%-ról 4,71%-ra vitte le az eltérések arányát — több mint tizenkét százalékpontos javulás.
Hat százalék tehát a mai kiindulópont. Javul, de a nullától messze van — és pont olyan hibáról beszélünk, amit nem vesz észre a felhasználó, csak a könyvelés.
Mekkora diffnél romlik el?
Erre a kérdésre nincs folytonos mérés — aki küszöbszámot mond, kitalálja. Van viszont két jól definiált pont, és a kettő közti különbség beszédes.
- Kicsi, jellemzően egyfájlos javításoknál a legjobb rendszerek megoldási aránya 74% körül jár.
- Nagy diffeken — ahol a feladatok harmada tíznél több fájlt érint és harmada kétszáznál több sort változtat — ugyanezek a modellek 41,2%-ot érnek el. Az itteni referenciajavítások átlagosan 11,4 fájlt és 261,6 sort érintenek; a legösszetettebb eset 182 fájlt.
Ugyanazok a modellek, körülbelül a fele az eredmény.
Ugyanezt megerősíti egy kifejezetten refaktorálásra épített mérés is: 1 099 fejlesztő által írt, viselkedésőrző átalakítás tizennyolc Java-projektből, atomi és összetett esetekre bontva. A legjobb modell 41,6%-ot ért el, a nyílt súlyúak 2% alatt, és egy agent az összetett átalakításokon mindössze 39,4%-ot. A szerzők összefoglalása: a mai modellek „hatékonyak maradnak a helyi, atomi szerkesztéseken, de gyengén teljesítenek a fájlok közti és összetett átalakításokon".
A valódi szűk keresztmetszet: a megtalálás
Itt egy apró, de fontos megkülönböztetés, ami sok félreértést old fel.
Egy eszközgyártó mérésében egy hét fájlt érintő átalakításnál az alap agent két fájlt módosított. Ugyanaz a feladat szimbólumszintű navigációval: mind a hetet.
A korlát tehát nem a szerkesztés, hanem a megtalálás. Az agent azt alakítja át, amit lát — és a hívási helyek egy részét nem látja. Egy refaktorálás, ami öt helyen javít és kettőn nem, rosszabb, mint ha hozzá se nyúltál volna. Hogy hol van ennek a határa, arról az örökölt kódbázis megértése poszt szól.
Miért pont most fontos ez
Egy 623 millió kódváltozást elemző, 2022 és 2026 közötti vizsgálat szerint a refaktorálás mint gyakorlat zuhanórepülésben van:
| Jelzőszám | Változás |
|---|---|
| „Mozgatott" kód — a refaktorálás proxyja | 21% (2022) → 3,8% (2026) |
| Copy/paste a változtatott sorokból | 9,4% → 15,7% |
| Blokk-duplikáció | +81% 2023 óta |
| Függvények közti kapcsoltság | −35% |
| Régi kód karbantartása | −74% |
| Hibaelfedő szerkezetek | +47% |
A cég összegzése: a fejlesztők ma nagyjából négyszer nagyobb eséllyel másolnak, mint mozgatnak.
(Kereskedelmi kódelemző cég adata, nem lektorált; a „mozgatott kód" heurisztika, nem közvetlen mérés. A minta mérete és a trend több jelzőszámon konzisztens iránya viszont komoly.)
A tanulság nem az, hogy az AI nem tud refaktorálni. Hanem hogy olcsóbbnak látszik újat írni — és ezért marad el az átrendezés. A duplikáció számláját viszont valaki ki fogja fizetni.
Az ellenőrzési sorrend
Ez a cikk gyakorlati magja. Hat lépés, és mindegyik mögött ott van a fenti adat.
1. CHARACTERIZATION TEST ELŐSZÖR.
Olyan teszt, ami nem azt rögzíti, AMINEK LENNIE KELLENE,
hanem azt, AMI VAN. A refaktorálás definíció szerint
viselkedésőrző - tehát a jelenlegi viselkedést kell
lebetonozni, mielőtt hozzányúlsz.
2. FORDÍTÁS + TELJES TESZTKÉSZLET.
Szükséges, de NEM elég: a hibás refaktorálások
~21,65%-át ez átengedi.
3. AST-SZINTŰ ELLENŐRZÉS: tényleg a kért átalakítás történt?
Erre van eszköz; Java-n 99% pontossággal és 94%
felidézéssel azonosítja, milyen refaktorálás történt.
Ez fogja meg azt, amikor a modell "javított is egy kicsit".
4. MUTATION TESTING.
Refaktorálásnál ez ÉRTELMES jel - mert a kiindulási
kódot jónak feltételezheted. (Hibakeresésnél nem az.)
5. DIFFERENTIAL TESTING / FUZZING.
Ezer-kétezer bemenet, régi és új kód egymás mellett.
Ez fogja meg azt a ~5%-ot, amit a teszt nem.
6. KIS DIFF.
Konkrét küszöbszám nincs. Amit tudunk: 10+ fájl és
200+ sor mellett a sikerarány 74%-ról 41%-ra esik.
Az első pontnál van egy szép összefüggés, amit érdemes kimondani. Ismert jelenség, hogy ha a meglévő kódot beteszed a promptba, a modell a jelenlegi viselkedésre ír állítást — hibakeresésnél ez katasztrófa, mert a hibát betonozza be. Characterization testnél viszont pontosan ez, amit akarsz. Ugyanaz a hajlam, ellenkező előjellel. A hibakeresés oldaláról a hibakeresés AI-val poszt szól bővebben, a tesztek oldaláról pedig a teszt mint biztonsági háló poszt.
Tipikus félreértések
- „Zöldek a tesztek, tehát nem változott a viselkedés." A hibás refaktorálások több mint egyötöde átmegy a meglévő tesztkészleten.
- „A mai modellek ezt már tudják." A viselkedési eltérés aránya 17%-ról 6%-ra esett három év alatt. Hat százalék nem nulla.
- „Ötszáz sor felett romlik el." Ilyen küszöbre nincs adat. Két mérési pont van: kis egyfájlos javításon ~74%, tíz fájl és kétszáz sor fölött 41%.
- „Az agent nem tud átnevezni mindenhol." Tud — ha megtalálja. A dokumentált korlát a megtalálás, nem a szerkesztés.
- „Majd a code review-ban kiderül." A csendes viselkedésváltozás pont az, ami diff ből nem látszik. Ahhoz futtatni kell.
Amit érdemes elvinni
A refaktorálásnál nem a prompt a kockázat, hanem az ellenőrzés sorrendje. Előbb rögzítsd, mi a jelenlegi viselkedés, aztán engedd hozzá a modellt — és tudd, hogy a teljes tesztkészlet önmagában a hibák egyötödét átengedi. Amit ezen felül érdemes: strukturális ellenőrzés, hogy tényleg a kért átalakítás történt-e, és differenciális futtatás, ami azt a néhány százalékot megfogja, amit semmi más.
A kész változtatás emberi átnézésének lépéseit a generált kód átvizsgálása poszt veszi végig.