FrontierCode Diamond: 13.4% egyesíthető javítás 50 nehéz feladaton (2026. június)

Az eszközök konfigurálásáról további anyagokat találsz az Ailoot dokumentációjában.

Mi az a FrontierCode, és miért fontos?#

A Cognition a Devin (az első autonóm AI-mérnök, 2024. március) és a Windsurf (2025 júliusában felvásárolt) mögött álló vállalat. Saját SWE-1.x modellcsaládjukat is fejlesztik. A benchmark a nyilvános blogon, a cognition.com/blog/frontier-code címenjelent meg.

A lényegi változás nem az új számokról szól. Hanem arról a mércéről, amellyel mostantól mérünk.

A benchmarknak három nehézségi szintje van: Extended (150 feladat, a teljes készlet), Main (a 100 legnehezebb feladat, köztük a Diamond), valamint Diamond (50 különösen nehéz feladat). A Cognition szándékosan hagyta a Diamondot „nagyrészt telítetlenül”—még a legjobb modell is 15%-nál kevesebb feladatot old meg. Ezzel egy évnyi mozgásteret akarnak adni a benchmarknak, hogy ne telítődjön egy hónap alatt, ahogy a HumanEval történt.

Mit mér a FrontierCode: „Egyesítené ezt a PR-t a karbantartó?”#

A hat értékelési tengely (a Cognition hivatalos blogja alapján):

1. Viselkedési helyesség — megoldja-e a javítás a feladatot?
2. Regresszióbiztonság — elkerüli-e a már meglévő kód törését?
3. Technikai tisztaság — átmegy-e a build-, lint- és stílusellenőrzéseken?
4. A tesztek helyessége — érvényesek-e az ügynök által írt tesztek (azok a tesztek, amelyek bármilyen kódon átmennek, nem számítanak)?
5. Hatókör — elkerüli-e a javítás a nem kért fájlok módosítását?
6. Kódminőség — követi-e a kód a projekt konvencióit, és olvasható-e?

Ahhoz, hogy egy javítás egyesíthetőnek minősüljön, mind a hat tengelyen át kell mennie. Ha akár egyen elbukik, nem egyesítik.

Ez a szemléletváltás lényege. „A helyesség mára alapkövetelménnyé vált” — fogalmaz a Cognition. Korábban a benchmarkok azt kérdezték: „Átment a kód a teszteken?” Most azt: „Bevenné ezt egy valódi technikai vezető a projektbe?”

A Cognition három új értékelési technikát vezetett be:

• Reverse-Classical: az ügynök által írt tesztnek el kell buknia a kód hibás változatán. Ellenkező esetben a teszt csak színjáték.
• Code Scope: egy automatikus ellenőrző igazolja, hogy a javítás a feladathoz megállapodott fájlok és sorszámkeret között marad.
• Adaptive Classical Grading: a „mutagent” nevű LLM-eszköz az érvényes megoldásváltozatokhoz igazítja a szigorú teszteket.

Miért nem működnek már a régi benchmarkok?#

Az AI-ügynökök már 2024-re kiválóan teljesítettek a HumanEvalon. A SWE-bench Verified nagyjából ugyanez: 2025 augusztusában az OpenAI nyilvánosan elismerte a kontamináció problémáját (a modellek a tanítás során már „látták” az adatkészletet). A benchmarkok elvesztették azt a képességüket, hogy különbséget tegyenek a legjobb modellek között.

A régi mércét aláásó legfontosabb tanulmány 2026 márciusában jelent meg.

Amit tettek:

• Kiválasztottak 4 aktív karbantartót 3 adattárból (scikit-learn, Sphinx, pytest).
• Megkérték őket, hogy értékeljék a SWE-bench Verified 296, AI által generált PR-jét — ezek mindegyike átment az automatikus teszteken.
• Összevetették a karbantartók döntéseit az automatikus értékelő eredményével.

Más szóval a benchmark azt mondja, „átment”, a karbantartó pedig azt, „nem egyesítem”—és az esetek átlagosan negyedében ez történik. Az elutasítás 3 leggyakoribb oka, a legenyhébbtől a legsúlyosabbig:

1. Kódminőség — nem illeszkedik az adattár stílusához.
2. Más kód törése — megtöri a szomszédos kódot.
3. Az alapfunkció hibája — nem oldja meg teljesen a feladatot, még akkor sem, ha a teszt zöld.

A FrontierCode pontosan ezt a problémát formalizálja. A Cognition átvette ezt az ötletet, és teljes benchmarkká bővítette, 4 helyett több mint 20 karbantartóval.

Egy újabb szög a koporsóba egy 2025. decemberi tanulmány az AI által generált javítások biztonságáról.

Ebben a Claude 4 Sonnettel készült SWE-Agent-megoldások 61%-a funkcionálisan helyes volt, de mindössze 10.5%-uk volt biztonságos.

A kód átmegy a teszten, mégis minden második javítás biztonsági rést vezet be. Ezt a SWE-bench benchmarkokon egyáltalán nem lehet észrevenni — azok nem mérik a biztonságot. A FrontierCode legalább megpróbálja észlelni ezt a „technikai tisztaság” és a kódminőség tengelyén.

Hol végeznek a modellek: Opus 4.8 13.4%-kal, GPT-5.5 6.3%-kal#

Ami feltűnik a táblázatból:

• Egyértelmű éllovas. Az Anthropic Opus 4.8 modellje nagyjából kétszer olyan messze jár, mint a legközelebbi versenytársa. A SWE-ben nehezen észrevehető különbség a FrontierCode-on világosan látszik.
• A nyílt modellek még nem érték utol. A Kimi K2.6 — a legjobb nyílt kódmodell — 3.8%-ot ér el a Diamondon. Ez 3–4-szer alacsonyabb az Opus 4.8 eredményénél. A Cognition nem tett közzé teljes Kimi K2.6-os eredménysort a Main és az Extended részhalmazon, ezért egyelőre nincs összehasonlítás a teljes készleten.
• A Cognition őszintén a saját modelljét is a táblázat alsó részére tette.

A Diamond részhalmazt szándékosan hagyták „telítetlenül”. A Cognition évekre előre beépített biztonsági tartalékot. Ha a korábbi benchmarkok 12–18 hónap alatt telítődtek, a FrontierCode-ot magasabb felső határral tervezték.

Mit jelent a „13% egyesíthető” annak, aki Claude Code-dal vibe codingol?#

Először is fontos újrakeretezni: a FrontierCode Diamond készlete szándékosan brutálisan nehéz. Egy új startupprojekt hétköznapi feladatainál, negyven egymástól függő modul nélkül, az AI-ügynök lényegesen jobban teljesít. Ugyanaz az Opus 4.8 az Extended részhalmazon (150 feladat, a teljes készlet) 51.8%-ban készít egyesíthető kódot. Ez teljesen más képet mutat.

Az 51.8%-os eredmény a benchmark 150 feladatos Extended készletére vonatkozik. Magasabb a Diamond-eredménynél, de egyik szám sem becsüli minden modell javításainak egyesíthetőségét a saját feladataidon. Más modellek hiányzó Main- vagy Extended-pontszáma nem ad alapot teljesítményük kitöltésére.

Mit jelent ez annak, aki vibe codinggal juttat kódot éles környezetbe:

• A zöld teszt már nem jelenti azt, hogy „készen áll az egyesítésre”. Előfordulhat, hogy az AI saját tesztjei semmit sem érnek — bármilyen kódon átmennek. A FrontierCode ezt közvetlenül méri a Reverse-Classical segítségével: ha egy teszt nem bukik el a hibás változaton, nem számít.
• Az adattár stílusa és konvenciói számítanak. Ha egy projektnek kialakult mintája van, és az AI nem követi, egy valódi munkatárs nem fogadja el a változtatást. Szabályok nélküli, egyéni projektnél ez nem nagy ügy. Csapatban ez az első számú probléma.
• A tesztek nem oldják meg a biztonsági problémákat. Emlékezz a fenti adatra: annak ellenére, hogy a javítások 61%-a helyes, csak 10.5%-uk biztonságos. Ezt külön kell ellenőrizni olyan eszközökkel, amelyek kiszűrik a tokeneket, a .env fájlokat és az alapértelmezett jelszavakat.
• A feladat túllépése tipikus AI-hiba. Megkéred, hogy javítson ki egy jogosultságkezelő függvényt, erre olyan javítást kapsz, amely a belső réteget és a naplózást is átírta. Ez a FrontierCode 6 tengelyének egyike.

Milyen 6 hibakategóriát vét az AI a nehéz feladatoknál?#

Vegyük sorra az egyes tengelyeket közérthetően:

1. Viselkedési helyesség — megoldja-e a javítás a feladatot?

Ez a legalapvetőbb tengely. Az AI gyakran olyan kódot ír, amely megoldásnak látszik, de rossz problémát old meg. Megkérem, hogy „adjon olvasási visszajelzést az üzenethez”, és kapok egy markAsRead függvényt, de az nincs összekötve magával a csevegőkomponenssel. A függvény tesztje átmegy. Az üzleti feladat nincs megoldva.

2. Regresszióbiztonság — elkerüli-e a szomszédos kód törését?

Az AI módosít egy modult, és egy másik már nem működik. A leggyakoribb eset: az AI-ügynök megváltoztatja egy függvény aláírását, megfeledkezve arról, hogy még 17 másik helyről hívják. A SWE-ben ezt nem látni — csak egyetlen fájl tesztjeit futtatják. A FrontierCode-on a teljes adattár tesztcsomagját futtatják.

3. Technikai tisztaság — átmegy-e a build-, lint- és stílusellenőrzéseken?

Az AI olyan kódot állíthat elő, amely helyben lefordul, de megbukik a CI-ben: hiányzó import, tabulátor szóköz helyett, két záró szóköz vagy egy apró hiba az eslint.config.js fájlban. Egy aktív projektben a stílus nem szeszély; csapatszabály.

4. A tesztek helyessége — érvényesek-e az AI által írt tesztek?

A legtrükkösebb tengely. Az AI ír egy tesztet, amely átmegy. De bármilyen kódon átmegy, még a hibás kódon is. Sokszor láttam már ilyet: a teszt azt ellenőrzi, hogy „összeomlott-e a szkript?”, de azt nem, hogy „a megfelelő eredményt adta-e vissza?”. A FrontierCode Reverse-Classical értékelése pontosan ezt az esetet fogja meg.

5. Hatókör — elkerüli-e a javítás a nem kapcsolódó fájlok módosítását?

Megkérem, hogy javítson ki egy függvényt, erre kapok egy 12 fájlt érintő javítást, amely a feladathoz nem kapcsolódó fájlokat is tartalmaz. Pontosan ez az AI-féle „kezdeményezőkészség”, amely tönkretesz egy éles projektet azzal, hogy olyan dolgokat módosít, amelyeket nem kértem. A FrontierCode-ban ez a tengely abszolút kizáró ok.

6. Kódminőség — követi-e a kód az adattár konvencióit?

Az AI a meglévő lib/ segédfüggvények használata helyett a saját függvényét írja meg „a nulláról”. Vagy a projekt stílusától eltérően nevezi el a változókat. Vagy rossz architekturális rétegbe helyezi a logikát. A teszt szempontjából minden működik. A technikai vezető szemszögéből nem fogják egyesíteni.

Hogyan ellenőrizd az AI-kódot feltöltés előtt: 5 lépés#

1. Futtasd a teljes tesztcsomagot, ne csak a módosításhoz kapcsolódó teszteket

   Az AI gyakran a feladaton túl is módosítja a kódot. A probléma a szomszédos teszteknél bukkan majd elő. A teljes tesztcsomagot futtatom (az egyetlen npm test paranccsal, útvonal megadása nélkül), nem csak egy adott fájl tesztjeit. Nagy projektekben ezt kényelmes párhuzamosan, git worktree segítségével futtatni (lásd: Git worktree a Claude Code-ban).

2. Futtass lint-, stílus- és típusellenőrzéseket

   Három parancs sorrendben: eslint ., prettier --check ., tsc --noEmit. Egy AI-ügynök a tabulátorokat és a sorvégi extra szóközt is elvétheti. Ha a projekt szigorú ellenőrzéseket használ, futtasd le őket helyben a kiadás előtt.

3. Teszteld magát a tesztet

   Az 5 ellenőrzés közül ez a legfontosabb. Egy apró „hibát” viszek a kódba (a return true értékét return false-ra változtatom). A tesztnek el kell buknia. Ha a teszt nem bukik el, az AI csak a látszat kedvéért írta, így használhatatlan. Törlöm a tesztet, és megkérem az AI-t, hogy írja újra a kötelező feltétellel: a tesztnek el kell buknia a hibás változaton.

4. Ellenőrizd, mely fájlokat módosította az AI

   A git diff --stat parancs megmutatja, mely fájlok változtak, és hány sorral. Ha az AI 12 fájlt érintett arra a kérésre, hogy „javítsd meg a kapcsolatfelvételi űrlapot”, túllépte a feladat hatókörét. A felesleges módosításokat egyetlen, az adott fájlra vonatkozó paranccsal visszavonom.

5. Futtass biztonsági ellenőrzést egy kész skill segítségével

   A tesztek nem veszik észre az SQL-injekciókat vagy a kódba írt jelszavakat. Kész biztonsági skillt használok a Claude Code-hoz (lásd: 754 kész biztonsági skill). Legalább kézzel keress rá a projektben a „password”, „secret” és „key” szavakra, és ellenőrizd, hogy a .env.example teljes-e.

Mind az 5 lépés lefedi a FrontierCode 6 tengelyéből 5-öt (1–5). A hatodik tengelyt — a kódminőséget — automatikusan ellenőrzi a lintelés, valamint emberi felülvizsgálat.

Mi javítja valójában az egyesíthető kód esélyét?#

Egy előkészítetlen projektben az AI-ügynök csak azt a fájlt látja, amelyet megnyitottál neki. Nincs meg a döntéseid története, nem ismeri a konvencióidat, és nincs térképe a moduljaidról. Egyszerű módosításoknál ez nem nagy ügy. Nehéz módosításoknál a hiányzó projektkontextus kezelendő kockázat. A benchmark 13.4%-os értéke nem különíti el a kontextus minőségét mint okot.

Amit meg kell tenned, hogy a 13%-ból olyasmi legyen, amit valóban éles környezetbe lehet juttatni:

1. A projekt szabályai — hogy az AI az internet átlagos gondolkodása helyett a te érvelésedet másolja.

Ez a kész megoldásaid, szokásaid és elsajátított szabályaid gyűjteménye olyan formában, amelyet az AI-ügynök minden kérésnél beolvas. Ha már 30+ szabály van benne, az AI nem találja ki többé az „iparági átlagot”, hanem a te stílusodban kezd javaslatokat tenni. A feladat hatókörének túllépése egyetlen szabállyal kezelhető: „ne módosíts olyan fájlt, amelyet a kérés kifejezetten nem nevez meg.”

2. Projekttérkép — egy mappa, amely leírja a projektet.

Ide kerülnek a termékek, a közönség, a gazdasági adatok, a mérőszámok és a beállítások. Minden kérés előtt az AI-ügynök elolvassa a tartalomjegyzéket, és megérti, a vállalkozás melyik részén dolgozik. Ez automatikusan kezeli a fent felsorolt elutasítási okok közül kettőt: a stílust és más kódok megtörését.

3. Context Engineering — annak kezelése, amit az AI a kérés előtt lát.

Nem az a kérdés, hogy „hogyan fogalmazd meg a promptot”, hanem az, hogy „mit tegyél a kontextusablakba a prompt ELŐTT”. CLAUDE.md, előfeltételek és célzott hivatkozások a fájlokra. Ez kezeli a viselkedési helyesség és a kódminőség hibáit.

A kombinációt az ellenőrzések előkészítésére használd, ne bizonyítékként öt tengely teljesülésére. Elfogadás előtt a tényleges javításon igazold a viselkedést, a regressziók hiányát, a teszteket, a terjedelem betartását és a kódminőséget.

Egy további réteg a felülvizsgáló ügynököké:

• Cursor Bugbot — minden PR-en felülvizsgálatot futtat. A Cursor szerint az eszköz havonta körülbelül 2 millió PR-t dolgoz fel.
• Beágyazott alügynökök a Claude Code v2.1.172-ben — az egyik ügynök írja a kódot, a második felülvizsgálja, a harmadik pedig teszteket futtat. Ugyanaz az elképzelés, mint a FrontierCode-nál: különválasztani az „író” és a „technikai vezető” szerepét.

Lásd még: Vibe Coding biztonság, A Claude Code konfigurálása, hogy ne tegye tönkre a projektedet éjszaka, valamint a Context Engineering mint fogalom.

Az eszközhasználatról további anyagokat az Ailoot dokumentációjában találsz.