FrontierCode Diamond: 13.4% popravkov primernih za združitev pri 50 zahtevnih nalogah (junij 2026)

Dodatno gradivo o nastavitvi orodij je na voljo v dokumentaciji Ailoot.

Kaj je FrontierCode in zakaj je pomemben?#

Cognition je podjetje, ki stoji za Devinom (prvim avtonomnim inženirjem UI, marec 2024) in Windsurfom (prevzet julija 2025). Razvijajo tudi lastno družino modelov SWE-1.x. Merilo so objavili na javnem blogu cognition.com/blog/frontier-code.

Ključni premik ni v novih številkah. Gre za merilo, s katerim zdaj ocenjujemo stvari.

Merilo ima tri težavnostne ravni: Extended (150 nalog, celoten nabor), Main (100 najtežjih, vključno z Diamond) in Diamond (50 zelo zahtevnih nalog). Cognition je Diamond namerno pustil »večinoma nenasičen« — tudi najboljši model reši manj kot 15 % nalog. Namen je, da bo merilo uporabno še eno leto in se ne bo nasičilo v enem mesecu, kot se je HumanEval.

Kaj meri FrontierCode: »Bi vzdrževalec združil ta PR?«#

Šest meril ocenjevanja (po uradnem blogu Cognition):

1. Pravilnost delovanja — ali popravek reši nalogo?
2. Varnost pred regresijami — ali prepreči okvare obstoječe kode?
3. Tehnična urejenost — ali prestane build, lint in preverjanje sloga?
4. Pravilnost testov — ali so testi, ki jih napiše agent, veljavni (testi, ki uspejo pri kateri koli kodi, ne štejejo)?
5. Obseg — ali se popravek izogne spreminjanju datotek, ki niso bile zahtevane?
6. Kakovost kode — ali koda sledi konvencijam projekta in je berljiva?

Da se popravek šteje za primernega za združitev, mora izpolniti vseh šest meril. Če odpove že pri enem, ne bo združen.

To je glavni premik v perspektivi. »Pravilnost je zdaj osnovni pogoj,« pravi Cognition. Prej so merila spraševala: »Ali je koda prestala teste?« Zdaj sprašujejo: »Bi jo pravi tehnični vodja vključil v projekt?«

Cognition je uvedel tri nove tehnike ocenjevanja:

• Reverse-Classical: test, ki ga napiše agent, mora spodleteti pri pokvarjeni različici kode. Sicer je test navidezen.
• Code Scope: samodejni preverjevalnik potrdi, da popravek ostane znotraj dogovorjenih datotek in števila vrstic za nalogo.
• Adaptive Classical Grading: orodje LLM »mutagent« prilagodi stroge teste veljavnim različicam rešitve.

Zakaj stara merila ne delujejo več?#

Agenti UI so HumanEval že do leta 2024 obvladali z odliko. SWE-bench Verified ni bistveno drugačen: avgusta 2025 je OpenAI javno priznal težavo kontaminacije (modeli so med učenjem že »videli« nabor podatkov). Merila so izgubila sposobnost razlikovanja med najboljšimi modeli.

Ključna študija, ki je spodkopala staro merilo, je izšla marca 2026.

Kaj so naredili:

• Izbrali so 4 aktivne vzdrževalce iz 3 repozitorijev (scikit-learn, Sphinx, pytest).
• Ocenili so 296 PR-jev, ustvarjenih z UI, iz nabora SWE-bench Verified — vsi ti PR-ji so prestali samodejne teste.
• Primerjali so odločitve vzdrževalcev z odločitvami samodejnega ocenjevalnika.

Z drugimi besedami: merilo pravi »uspešno«, vzdrževalec pa »ne bom združil« — in to se zgodi v povprečno četrtini primerov. Trije najpogostejši razlogi za zavrnitev, od najmanj do najbolj resnega:

1. Kakovost kode — ne ustreza slogu repozitorija.
2. Okvara druge kode — pokvari sosednjo kodo.
3. Nedelujoča osnovna funkcionalnost — naloge ne reši v celoti, čeprav je test zelen.

FrontierCode to težavo formalizira. Cognition je prevzel to zamisel in jo razširil v celovito merilo z več kot 20 vzdrževalci namesto 4.

Še en žebelj v krsto je študija iz decembra 2025 o varnosti popravkov, ki jih ustvari UI.

V njej je bilo 61 % rešitev SWE-Agent s Claude 4 Sonnet funkcionalno pravilnih, varnih pa le 10.5 %.

Koda prestane test, vendar vsak drugi popravek uvede varnostno luknjo. Tega pri merilih SWE-bench sploh ne moreš opaziti — varnosti ne merijo. FrontierCode jo vsaj poskuša zaznati z meriloma »tehnična urejenost« in kakovost kode.

Uvrstitev modelov: Opus 4.8 z 13.4 %, GPT-5.5 s 6.3 %#

Kaj izstopa v tabeli:

• En jasen vodilni. Opus 4.8 podjetja Anthropic je približno dvakrat boljši od najbližjega tekmeca. Razlika, ki jo je bilo na SWE-bench težko opaziti, je na FrontierCode jasno vidna.
• Odprti modeli še niso dohiteli najboljših. Kimi K2.6 — najboljši odprtokodni model za kodiranje — dosega 3.8 % na Diamond. To je 3–4-krat manj od Opus 4.8. Cognition ni objavil celotne lestvice za Kimi K2.6 na Main in Extended, zato primerjave na celotnem naboru še ni.
• Cognition je pošteno uvrstil svoj model v spodnji del tabele.

Podnabor Diamond so namerno pustili »nenasičen«. Cognition je vgradil varnostno rezervo za prihodnja leta. Če so se prejšnja merila nasičila v 12–18 mesecih, je FrontierCode zasnovan z višjo zgornjo mejo.

Kaj pomeni »13 % primernih za združitev« za vibe coderja, ki uporablja Claude Code?#

Najprej pomembna omejitev: nabor Diamond v FrontierCode je namenoma zelo zahteven. Isti Opus 4.8 dosega 51.8% rešitev, primernih za združitev, na naboru Extended s 150 nalogami. Primerjava opisuje ta dva izbrana nabora, ne napovedi uspeha pri običajnih nalogah novega projekta.

Rezultat 51.8% velja za nabor Extended s 150 nalogami tega primerjalnega testa. Višji je od rezultata Diamond, vendar nobena številka ne ocenjuje primernosti za združitev popravkov vseh modelov pri vaših nalogah. Manjkajoče ocene Main ali Extended za druge modele ne upravičujejo dopolnjevanja njihovih rezultatov.

Kaj to pomeni za vibe coderja, ki pošilja kodo v produkcijo:

• Zelen test ne pomeni več »pripravljeno za združitev«. Testi, ki jih napiše sam UI, so lahko zanič — uspejo pri kateri koli kodi. FrontierCode to meri neposredno z Reverse-Classical: če test ne spodleti pri pokvarjeni različici, se ne šteje.
• Slog in konvencije repozitorija so pomembni. Če projekt uporablja ustaljen vzorec, UI pa mu ne sledi, sodelavec tega ne bo sprejel. V samostojnih projektih brez pravil to ni velika težava. V ekipi je to težava številka ena.
• Testi ne rešijo varnostnih vprašanj. Spomni se podatka zgoraj: varnih je le 10.5 % popravkov, čeprav jih je 61 % pravilnih. To je treba preveriti posebej, z orodji, ki zaznajo žetone, datoteke .env in privzeta gesla.
• Preseganje obsega naloge je tipična napaka UI. Prosiš ga, naj popravi funkcijo za avtorizacijo, dobiš pa popravek, ki je prepisal tudi notranji sloj in beleženje. To je eno od 6 meril FrontierCode.

Katere 6 kategorij napak dela UI pri zahtevnih nalogah?#

Poglejmo posamezna merila v preprostem jeziku:

1. Pravilnost delovanja — ali popravek reši nalogo?

Najosnovnejše merilo. UI pogosto napiše kodo, ki je videti kot rešitev, vendar rešuje napačno težavo. Prosim ga, naj »doda potrdilo o branju sporočila«, in dobim funkcijo markAsRead, vendar ni povezana s samo komponento klepeta. Test funkcije uspe. Poslovna naloga ni rešena.

2. Varnost pred regresijami — ali prepreči okvare sosednje kode?

UI spremeni en modul, zdaj pa drug ne deluje. Najpogostejši primer: agent UI spremeni podpis funkcije in pozabi, da jo kliče še 17 drugih mest. Tega na SWE-bench ne vidiš — testi se izvajajo le za eno datoteko. Pri FrontierCode izvajajo celoten nabor testov repozitorija.

3. Tehnična urejenost — ali prestane build, lint in preverjanje sloga?

UI lahko ustvari kodo, ki se lokalno prevede, v CI pa odpove: manjka uvoz, namesto presledkov so uporabljeni tabulatorji, na koncu vrstic sta dva odvečna presledka ali pa je prišlo do napake v eslint.config.js. V aktivnem projektu slog ni kaprica; je ekipno pravilo.

4. Pravilnost testov — ali so testi, ki jih napiše UI, veljavni?

Najzahtevnejše merilo. UI napiše test, ki uspe. Toda uspe pri kateri koli kodi, tudi pri pokvarjeni. To sem videl že velikokrat: test preverja »ali se je skript sesul?«, ne pa »ali je vrnil pravilen rezultat?«. Reverse-Classical v FrontierCode zazna prav ta primer.

5. Obseg — ali se popravek izogne spreminjanju nepovezanih datotek?

Prosim ga, naj popravi eno funkcijo, in dobim popravek za 12 datotek, med katerimi so tudi nepovezane z nalogo. To je tista »iniciativnost« UI, ki pokvari produkcijski projekt s spreminjanjem stvari, za katere nisem prosil. Pri FrontierCode je to merilo absolutna ovira.

6. Kakovost kode — ali koda sledi konvencijam repozitorija?

UI napiše svojo funkcijo »iz nič«, namesto da bi uporabil obstoječe pomožne funkcije v lib/. Ali poimenuje spremenljivke drugače, kot narekuje slog projekta. Ali pa logiko postavi v napačen arhitekturni sloj. Z vidika testa vse deluje. Z vidika tehničnega vodje popravek ne bo združen.

Kako preveriti kodo UI pred potiskom: 5 korakov#

1. Zaženi celoten nabor testov, ne le testov, povezanih s spremembo

   UI pogosto spreminja kodo zunaj obsega naloge. Težava se bo pokazala v sosednjih testih. Zaženem celoten nabor testov (z enim samim ukazom npm test, brez poti), ne le testov za določeno datoteko. Pri velikih projektih je to priročno izvesti vzporedno z git worktree (glej Git worktree v Claude Code).

2. Zaženi preverjanja lintanja, sloga in tipov

   Trije ukazi po vrsti: eslint ., prettier --check ., tsc --noEmit. Agent UI lahko spregleda tako tabulatorje kot dodaten presledek na koncu vrstice. Če ima projekt stroga preverjanja, jih pred izdajo zaženi lokalno.

3. Preizkusi sam test

   Najpomembnejši od 5 pregledov. V kodo vnesem majhno »napako« (spremenim return true v return false). Test mora spodleteti. Če ne spodleti, ga je UI napisal le za videz in je neuporaben. Test izbrišem in prosim UI, naj ga napiše znova z obveznim pogojem: test mora spodleteti pri pokvarjeni različici.

4. Preveri, katerih datotek se je dotaknil UI

   Ukaz git diff --stat pokaže, katere datoteke so se spremenile in koliko vrstic. Če se je UI dotaknil 12 datotek kot odgovor na »popravi kontaktni obrazec«, je presegel obseg naloge. Dodatne spremembe povrnem z enim samim ukazom za datoteko.

5. Izvedi varnostni pregled z že pripravljeno veščino

   Testi ne zaznajo vbrizgavanja SQL ali trdo kodiranih gesel. Uporabljam že pripravljeno varnostno veščino za Claude Code (glej 754 že pripravljenih varnostnih veščin). Najmanj, kar lahko narediš, je, da v kodi ročno poiščeš besede »password«, »secret« in »key« ter preveriš, ali je .env.example popoln.

Vseh 5 korakov pokriva 5 od 6 meril FrontierCode (1–5). Šesto merilo — kakovost kode — se preveri samodejno z lintanjem in človeškim pregledom.

Kaj v resnici izboljša možnosti za kodo, primerno za združitev?#

Agent UI v nepripravljenem projektu vidi samo datoteko, ki si jo odprl zanj. Nima zgodovine tvojih odločitev, ne pozna tvojih konvencij in nima zemljevida tvojih modulov. Pri preprostih spremembah to ni velika težava. Pri zahtevnih spremembah je manjkajoči projektni kontekst tveganje, ki ga je vredno odpraviti. Številka 13.4% iz primerjalnega testa ne izolira kakovosti konteksta kot vzroka.

Kaj moraš narediti, da teh 13 % spremeniš v nekaj, kar lahko dejansko potisneš v produkcijo:

1. Pravila projekta — da UI posnema tvoje razmišljanje, ne povprečja z interneta.

Gre za zbirko tvojih že pripravljenih rešitev, navad in naučenih pravil v obliki, ki jo agent UI prebere ob vsaki zahtevi. Ko se nabere 30+ pravil, UI neha izumljati »povprečje panoge« in začne predlagati rešitve v tvojem slogu. Preseganje obsega naloge lahko omejiš z eno vrstico v pravilih: »ne spreminjaj datotek zunaj tistih, ki so izrecno navedene v zahtevi«.

2. Zemljevid projekta — mapa, ki opisuje projekt.

Sem shraniš izdelke, občinstvo, ekonomiko, metrike in nastavitve. Pred vsako zahtevo agent UI prebere kazalo in razume, na katerem delu poslovanja dela. To samodejno naslovi dva od zgoraj navedenih razlogov za zavrnitev: slog in okvaro druge kode.

3. Context Engineering — upravljanje tega, kar UI vidi pred zahtevo.

Ne gre za »kako oblikovati prompt«, temveč za »kaj dodati v kontekstno okno PRED promptom«. CLAUDE.md, predpogoji in ciljno usmerjene povezave do datotek. To naslavlja napake pri pravilnosti delovanja in kakovosti kode.

Kombinacijo uporabi kot pripravo na preverjanja, ne dokaz, da je pet meril že izpolnjenih. Pred sprejemom na dejanskem popravku preveri vedenje, regresije, teste, obseg in kakovost kode.

Dodatni sloj so pregledovalni agenti:

• Cursor Bugbot — pregleda vsak PR. Po navedbah Cursorja orodje obdela približno 2 milijona PR-jev na mesec.
• Gnezdeni podagenti v Claude Code v2.1.172 — en agent napiše kodo, drugi jo pregleda, tretji pa zažene teste. Gre za isto zamisel kot pri FrontierCode: ločiti vlogi »pisca« in »tehničnega vodje«.

Oglej si tudi: Varnost pri Vibe Codingu, Kako nastaviti Claude Code, da ponoči ne pokvari tvojega projekta in Context Engineering kot koncept.

Dodatno gradivo o delu z orodji najdeš v dokumentaciji Ailoot.