A 32 ezer tokenes fal
Ez a cikk legfontosabb száma, és egy 2025-ös akadémiai mérésből jön, ami kifejezetten kódmegértést vizsgált — nem prózát.
Nyolc feladattípus, négy dimenzió (kódegység felismerése, egységen belüli megértés, egységek közti kapcsolatok, hosszú dokumentáció), kilenc hosszú kontextusú modell. A megállapítás szó szerint:
Minden vizsgált modell teljesítménye meredeken esik, amint a kód hossza meghaladja a 32 ezer tokent — éles ellentétben a hirdetett 128 ezer–egymilliós kontextusablakkal.
És a részletekben van a lényeg: 64 és 128 ezer token között a függőség- és kapcsolatelemzés gyakorlatilag nullára esik. Vagyis a modell még „látja" a kódot, de már nem érti, mi hogyan kapcsolódik — pont azt nem, amiért egy örökölt kódbázishoz nyúlnál.
| Amit egyszerre kell megértenie | Mi működik |
|---|---|
| ~32K token alatt (nagyjából 2–4 ezer sor) | a teljes kontextus — ez a legjobb |
| 32K fölött | látszólag befér, de a kapcsolatok megértése romlik |
| kb. 400 ezer sor fölött | a puszta keresés és olvasás sem elég |
A gyakorlati szabály ebből: ne a repót add oda, hanem egy szálat.
Az „átírnám inkább" torzítás
Van egy 2026-os mérés, ami kifejezetten azt vizsgálta, mennyire érti a modell egy ismeretlen repó architektúráját. A kérdéseket valódi fejlesztői beszélgetésekből merítették, és nem pontszámmal, hanem ellenőrzőlistával értékeltek.
Két megállapítása van, és mindkettő fontos.
Az egyik a szerkesztési torzítás: a modellek „idő előtt kódmódosítást javasolnak ahelyett, hogy megértenék a meglévő repó architektúráját". Kérdezel, és javítást kapsz.
A másik az, ami ennél is alattomosabb: „tartós rés van a magas érthetőség és a bizonyítékalapú technikai helyesség között". Magyarul: a válasz világos, tagolt, magabiztos — és nincs a kódhoz kötve.
Ezért nem szabad azt kérni, hogy „értsd meg a repót". Ilyenkor egy jól hangzó összefoglalót kapsz, aminek az ellenőrzése több munka, mint amennyit megspórolt.
Amit a modell tud — és amit valójában honnan tud
Ez a rész eldönti, mire számíthatsz egy céges, zárt kódbázisban.
Egy 2026-os vizsgálat 1 318 valódi fejlesztői kérdést és elfogadott választ gyűjtött össze 134 nyílt forrású projektből, és két erős modellt mért rajtuk. Az alappontszámok tízes skálán 6,6 és 7,0 körül alakultak — tisztes, de nem lenyűgöző.
A döntő eredmény viszont máshol van. Amikor megtiltották a modelleknek a belső tudásuk használatát, romlott a teljesítményük. A tanítás i adathatár utáni kérdéseknél pedig drasztikusan esett: az egyik modellnél 6,59-ről 5,44-re, a másiknál 6,97-ről 5,97-re. A szerzők szó szerinti közösségi válaszreprodukciót is dokumentáltak.
Vagyis a modell jórészt azon teljesít jól, amit már látott. Egy zárt, céges, soha nem publikált repóban pontosan ez az előny hiányzik.
A bontás is használható: erős az API-használati kérdésekben, gyenge a konfigurációban, az integrációban és a lekérdezésekben. Sajnos az örökölt rendszerekben a fájdalom jellemzően az utóbbi háromban van.
Hogyan találja meg a kódot? Három stratégia
Szemantikus index. A fájlokat darabokra vágja, azokból vektorokat képez, és jelentés szerint keres. Előnye, hogy természetes nyelvű kérdésre akkor is talál, ha a keresett szó nem szerepel a kódban. Hátránya, hogy külön indexet kell karbantartani, a friss változás csak indexelés után látszik, és a darabolás szétvághatja az összetartozó részeket.
Keresésalapú felderítés. Nincs index: fájlmintára keres, aztán tartalomra, aztán elolvassa a fájlt. Az egyik nagy eszköz készítője erről szokatlanul őszintén nyilatkozott: a korai változataik vektoradatbázissal működtek, de azt tapasztalták, hogy a keresésalapú felderítés általában jobban működik — és ez őket is meglepte.
Ennek van egy költségprofilja, amit érdemes ismerni: a fájlminta-keresés gyakorlatilag ingyen van, a tartalomkeresés olcsó, a teljes fájl elolvasása viszont fájlonként 500–5 000 tokenbe kerül. Aki „olvasd el az egész mappát" utasítást ad, a kontextusablakát égeti.
Teljes kontextus. A legjobb, amíg belefér — de a fenti 32 ezres korlát itt csattan.
Egy gyakori félreidézés, amit érdemes helyretenni: kering egy tanulmány arról, hogy a kulcsszavas keresés eléri a vektoros megoldások teljesítményének 90%-át. Ez igaz — de általános kérdés-válaszra mérték, nem kódra. Aki ezzel bizonyítja a kódolós eszközök döntését, túllő a célon.
A 400 ezer soros küszöb
Egy eszközgyártó saját mérése 1 281 értékelt agent-futást vizsgált több mint negyven nagy nyílt forrású repóban, kilenc nyelven. A megállapítás: a kizárólag helyi eszközöket — keresést és fájlolvasást — használó agentek nagyjából 400 ezer kódsor fölött kezdenek rendszeresen elakadni.
Egy konkrét példa ugyaninnen: egy 1,4 millió soros, 22 ezer fájlos projektben kódkereső eszköz nélkül 6 000 másodperc után sem született kimenet; indexelt kereséssel 89 másodperc alatt megvolt, jó minőségben. Többfájlos refaktorálásnál az alap agent hétből két fájlt módosított, a kiegészített mind a hetet.
És a részlet, ami a leghasznosabb: 400 ezer sor alatt a kódintelligencia-eszköz hozzáadása rontott az eredményen. Vagyis a nagy kódbázisra való megoldás kicsin felesleges bonyolítás.
(Gyártói mérés, a saját termékéről, nem lektorált — a nagyságrendi küszöb viszont így is jól használható.)
Egy meglepetés: a komment néha zaj
Egy másik mérés — 500 kódkeresési feladat, ötven repó, öt nyelv — azt vizsgálta, megtalálja-e a modell természetes nyelvű leírás alapján a keresett függvényt.
A mellékeredménye elgondolkodtató: a kommentek eltávolításával a modellek teljesítménye javult (egyetlen modellcsalád kivételével).
Az örökölt kódbázisokban ez nem meglepő. A tízéves, elavult, félrevezető komment nem segítség, hanem zaj — és a modell épp úgy megvezethető vele, mint az ember.
A recept
1. NE KÉRD, HOGY "ÉRTSD MEG A REPÓT".
Magabiztos, jól tagolt, kódhoz nem kötött választ kapsz.
2. KÉRDEZZ EGY SZÁLAT, KONKRÉTAN.
"Hogyan jut el a kérés a /checkout végponttól az adatbázisig?
Sorold fel a fájlokat és a sorszámokat."
-> a fájl- és sorszámkérés az, ami bizonyítékhoz köti a választ
3. TARTSD 32K TOKEN ALATT, amit egyszerre kell megértenie.
Egy modul, egy folyamat, egy réteg - nem az egész.
4. A FELDERÍTÉST KÜLÖN SUBAGENTBE.
Külön kontextusablakban fut, összefoglalót ad vissza,
a fő munkamenet tiszta marad. A "nézz körül" utasítás
kontextus nélkül több száz fájlt olvastat el.
5. HASZNÁLD A VERZIÓTÖRTÉNETET.
"Nézd át ennek az osztálynak a git-történetét, és foglald
össze, hogyan alakult ki az API-ja." A commit-üzenet
olyan szándékot hordoz, ami a kódban nincs benne.
6. NAGY REPÓNÁL (400 ezer sor felett) KELL SZIMBÓLUMSZINTŰ
NAVIGÁCIÓ. Kicsiben viszont ront - ne vezesd be előre.
7. AMIT MEGÉRTETTÉL, ÍRD LE - de a helyére, és nem mindent.
És a COBOL?
Az örökölt kódbázisról szóló beszélgetés előbb-utóbb ideér, ezért érdemes pontosan mondani, mi az állás.
A nagy szállítók termékei átnevezésen mentek át 2026 elején — aki a régi terméknevet keresi, elavult dokumentációt talál. Adoptációs vagy eredményszámot viszont egyik gyártó sem publikál.
A leghasznosabb, idézhető szakmai megállapítás 2026-ból: az AI-eszközök felgyorsítják a kódelemzési és átalakítási fázist, de nem kezelik azt a teljes programterjedelmet, ami eldönti, hogy egy migráció sikerül-e.
És a konkrét hiányzó darab: nincs viselkedési ekvivalencia-ellenőrző eszköz. Vagyis semmi nem bizonyítja, hogy az új rendszer tényleg ugyanazt csinálja, mint a régi. Szabályozott környezetben ez blokkoló hiány.
A tézis tehát: az AI a megértés fázisában hoz valódi értéket — függőségtérkép, dokumentálás, kódfelderítés. A migráció szűk keresztmetszete nem a fordítás, hanem a bizonyítás. Ehhez kapcsolódik, hogy mit érdemes egyáltalán biztonságosan átalakítani: erről a biztonságos refaktorálás poszt szól.
Tipikus félreértések
- „Egymilliós a kontextusablak, tehát befér a repó." Befér, de 32 ezer token fölött a kapcsolatok megértése romlik, 64–128 ezer között gyakorlatilag megszűnik.
- „Megkérdezem, hogyan épül fel a projekt." Mért torzítás, hogy a modell inkább javítást javasol, és a válasza világos, de nincs a kódhoz kötve.
- „A modell úgyis ismeri az ilyen rendszereket." Azt ismeri, amit látott. A tanítási határ utáni kérdéseknél a pontszáma egy ponttal esik, zárt repóban pedig nincs mire támaszkodnia.
- „Adok neki mindent, a kommentekkel együtt." Egy mérésben a kommentek eltávolítása javította a találati arányt. Az elavult komment zaj.
- „Kell egy kódkereső index." 400 ezer sor felett igen. Alatta a mérés szerint ront.
Amit érdemes elvinni
Egy örökölt kódbázist nem „megértetni" kell a modellel, hanem egy szálat végigkövettetni vele, fájl- és sorszámokkal. Tartsd 32 ezer token alatt, amit egyszerre kell átlátnia, a felderítést tedd külön subagentbe, és használd a verziótörténetet — a commit-üzenetben ott a szándék, ami a kódból hiányzik. A modell azon erős, amit már látott; a te zárt repódban ez az előny nincs meg.
Hogy amit megértettél, hogyan érdemes leírni — és mennyit ér ez valójában —, arról a dokumentáció, amit frissítesz poszt szól; az ellenőrzés oldaláról pedig a teszt mint biztonsági háló poszt.