FrontierCode Diamond: 13.4% sujungti tinkamų pataisymų 50 sunkių užduočių rinkinyje (2026 m. birželis)

Papildomos medžiagos apie įrankių konfigūravimą pateikiamos Ailoot dokumentacijoje.

Kas yra FrontierCode ir kodėl jis svarbus?#

Cognition yra Devin (pirmojo autonominio AI inžinieriaus, 2024 m. kovas) ir Windsurf (įsigyto 2025 m. liepą) kūrėja. Bendrovė taip pat kuria savo SWE-1.x modelių seriją. Etalonas paskelbtas viešame tinklaraštyje adresu cognition.com/blog/frontier-code.

Svarbiausias pokytis – ne nauji skaičiai. Tai nauja matavimo skalė.

Etalonas turi tris sudėtingumo lygius: Extended (150 užduočių, visas rinkinys), Main (100 sunkiausių, įskaitant Diamond) ir Diamond (50 itin sunkių užduočių). Cognition sąmoningai paliko Diamond „iš esmės neprisotintą“ – net geriausias modelis išsprendžia mažiau nei 15 %. Taip siekiama, kad etalonas turėtų atsargos metams ir nebūtų prisotintas per mėnesį, kaip nutiko HumanEval.

Ką matuoja FrontierCode: „Ar prižiūrėtojas sujungtų šį PR?“#

Šeši vertinimo kriterijai (pagal oficialų Cognition tinklaraštį):

1. Elgsenos teisingumas – ar pataisymas išsprendžia užduotį?
2. Apsauga nuo regresijų – ar jis nesugadina esamo kodo?
3. Techninis tvarkingumas – ar jis įveikia build, lint ir stiliaus patikras?
4. Testų teisingumas – ar agento parašyti testai galioja (testai, kurie praeina su bet kokiu kodu, nesiskaito)?
5. Apimtis – ar pataisymas neliečia failų, kurių nebuvo prašyta keisti?
6. Kodo kokybė – ar kodas laikosi projekto konvencijų ir yra įskaitomas?

Kad pataisymas būtų laikomas tinkamu sujungti, jis turi atitikti visus šešis kriterijus. Užtenka neatitikti vieno, ir jis nebus sujungtas.

Tai ir yra pagrindinis požiūrio pokytis. „Teisingumas dabar yra būtinas minimumas“, – teigia Cognition. Anksčiau etalonai klausė: „Ar kodas išlaikė testus?“ Dabar klausia: „Ar tikras techninis vadovas priimtų šį kodą į projektą?“

Cognition pristatė tris naujus vertinimo metodus:

• Reverse-Classical: agento parašytas testas turi nepraeiti su sugadinta kodo versija. Priešingu atveju testas yra fiktyvus.
• Code Scope: automatinė tikrintuvas patikrina, ar pataisymas neviršija užduočiai sutarto failų sąrašo ir eilučių skaičiaus.
• Adaptive Classical Grading: LLM įrankis „mutagent“ pritaiko griežtus testus tinkamiems sprendimų variantams.

Kodėl senieji etalonai nebeveikia?#

AI agentai HumanEval etalone jau buvo pasiekę puikių rezultatų iki 2024 m. SWE-bench Verified yra panašus: 2025 m. rugpjūtį OpenAI viešai pripažino duomenų užterštumo problemą (modeliai buvo „matę“ duomenų rinkinį mokymo metu). Etalonai prarado gebėjimą atskirti geriausius modelius.

Svarbus tyrimas, pakirtęs senąjį matą, paskelbtas 2026 m. kovą.

Ką jie padarė:

• Atrinko 4 aktyvius prižiūrėtojus iš 3 saugyklų (scikit-learn, Sphinx, pytest).
• Paprašė jų įvertinti 296 AI sugeneruotus PR iš SWE-bench Verified – visi šie PR buvo išlaikę automatinius testus.
• Palygino prižiūrėtojų sprendimus su automatinio vertintojo sprendimais.

Kitaip tariant, etalonas sako „išlaikė“, o prižiūrėtojas – „nesujungs“; vidutiniškai taip nutinka ketvirtadaliu atvejų. Trys svarbiausios atmetimo priežastys, nuo mažiausiai iki rimčiausios:

1. Kodo kokybė – neatitinka saugyklos stiliaus.
2. Sugadinamas kitas kodas – sugadinamas gretimas kodas.
3. Pagrindinės funkcijos trūkumas – užduotis neišsprendžiama iki galo, nors testas sėkmingas.

FrontierCode formalizuoja būtent šią problemą. Cognition perėmė šią idėją ir išplėtė ją į visavertį etaloną, kuriame dalyvauja daugiau nei 20 prižiūrėtojų, o ne 4.

Dar vienas vinis į karstą – 2025 m. gruodžio tyrimas apie AI sugeneruotų pataisų saugumą.

Jame 61 % SWE-Agent sprendimų su Claude 4 Sonnet buvo funkciniu požiūriu teisingi, tačiau saugūs buvo tik 10.5 % jų.

Kodas išlaiko testą, tačiau kas antras pataisymas įveda saugumo spragą. SWE-bench etalonuose to visai nepamatysite – jie saugumo nematuoja. FrontierCode bent jau bando tai aptikti pagal „techninio tvarkingumo“ ir kodo kokybės kriterijus.

Modelių reitingas: Opus 4.8 – 13.4 %, GPT-5.5 – 6.3 %#

Kas išsiskiria lentelėje:

• Vienas aiškus lyderis. Anthropic Opus 4.8 pirmauja maždaug dvigubai prieš artimiausią konkurentą. Atotrūkis, kurį SWE-bench buvo sunku pastebėti, FrontierCode akivaizdus.
• Atvirojo kodo modeliai dar nepasivijo. Kimi K2.6 – geriausias atvirojo kodo modelis – Diamond pogrupyje surinko 3.8%. Tai 3–4 kartus mažiau nei Opus 4.8. Cognition nepaskelbė visų Kimi K2.6 Main ir Extended rezultatų, todėl kol kas nėra palyginimo visame rinkinyje.
• Cognition sąžiningai įtraukė savo modelį į žemesnę lentelės dalį.

Diamond pogrupis sąmoningai paliktas „neprisotintas“. Cognition numatė saugumo atsargą ateinantiems metams. Jei ankstesni etalonai prisotindavo per 12–18 mėnesių, FrontierCode sukurtas taip, kad jo riba būtų aukštesnė.

Ką „13 % tinkamo sujungti“ reiškia vibe coderiui, naudojančiam Claude Code?#

Pirmiausia – svarbus perspektyvos pakeitimas: FrontierCode Diamond rinkinys sąmoningai yra itin sudėtingas. Įprastose užduotyse naujame startuolio projekte, kuriame nėra keturiasdešimties priklausomų modulių, AI agentas pasirodo gerokai geriau. Tas pats Opus 4.8 pasiekia 51.8 % sujungti tinkamų rezultatų Extended rinkinyje (150 užduočių, visas rinkinys). Tai visiškai kitoks vaizdas.

51.8% rezultatas taikomas etalono 150 užduočių Extended rinkiniui. Jis didesnis nei Diamond rezultatas, tačiau nė vienas skaičius neįvertina visų modelių pataisymų sujungiamumo jūsų užduotyse. Trūkstami kitų modelių Main ar Extended balai nesuteikia pagrindo išgalvoti jų našumo.

Ką tai reiškia vibe coderiui, kuris perkelia kodą į gamybinę aplinką:

• Sėkmingas testas jau nereiškia „paruošta sujungti“. Pačios AI parašyti testai gali būti beverčiai – jie praeina su bet kokiu kodu. FrontierCode tai tiesiogiai matuoja per Reverse-Classical: jei testas nepraeina su sugadinta versija, jis nesiskaito.
• Svarbus saugyklos stilius ir konvencijos. Jei projekte nusistovėjęs šablonas, o AI jo nesilaiko, tikras bendradarbis pakeitimo nepriims. Asmeniniuose projektuose be taisyklių tai nėra didelė problema. Komandoje tai svarbiausia problema.
• Testai neišsprendžia saugumo klausimų. Prisiminkite pirmiau minėtą skaičių: saugūs tik 10.5 % pataisymų, nors teisingi yra 61 %. Tai reikia tikrinti atskirai, naudojant įrankius, kurie aptinka tokenus, .env failus ir numatytuosius slaptažodžius.
• Užduoties ribų peržengimas – tipiška AI klaida. Paprašote pataisyti autorizavimo funkciją, o gaunate pataisymą, kuris dar ir perrašė vidinį sluoksnį bei žurnalų registravimą. Tai viena iš 6 FrontierCode vertinimo sričių.

Kokias 6 klaidų kategorijas AI daro atlikdama sudėtingas užduotis?#

Pereikime prie kiekvieno kriterijaus paprastais žodžiais:

1. Elgsenos teisingumas – ar pataisymas išsprendžia užduotį?

Pats pagrindinis kriterijus. AI dažnai parašo kodą, kuris atrodo kaip sprendimas, bet sprendžia ne tą problemą. Paprašau „pridėti prie pranešimo perskaitymo patvirtinimą“ ir gaunu markAsRead funkciją, bet ji neprijungta prie pačios pokalbio komponentės. Funkcijos testas praeina. Verslo užduotis neišspręsta.

2. Apsauga nuo regresijų – ar pataisymas nesugadina gretimo kodo?

AI pakeičia vieną modulį, ir kitas nustoja veikti. Dažniausias atvejis: AI agentas pakeičia funkcijos signatūrą ir pamiršta, kad ji iškviečiama dar 17 vietų. SWE-bench to nepamatysite – ten testuojamas tik vienas failas. FrontierCode vykdo visą saugyklos testų rinkinį.

3. Techninis tvarkingumas – ar pataisymas įveikia build, lint ir stiliaus patikras?

AI gali sukurti kodą, kuris kompiliuojamas vietoje, bet sugenda CI aplinkoje: trūksta importo, naudojami tabuliavimo ženklai vietoj tarpų, palikti du tarpai eilutės gale arba padaryta klaida eslint.config.js. Veikiančiame projekte stilius nėra kaprizas – tai komandos taisyklė.

4. Testų teisingumas – ar AI parašyti testai galioja?

Kebliausias kriterijus. AI parašo testą, kuris praeina. Tačiau jis praeina su bet kokiu kodu, įskaitant sugadintą. Tai mačiau daugybę kartų: testas patikrina „ar skriptas nesukrito“, bet ne „ar grąžino teisingą rezultatą“. FrontierCode Reverse-Classical aptinka būtent tokį atvejį.

5. Apimtis – ar pataisymas neliečia nesusijusių failų?

Paprašau pataisyti vieną funkciją ir gaunu pataisymą 12 failų, įskaitant su užduotimi nesusijusius failus. Būtent tokia AI „iniciatyva“ sugadina gamybinį projektą, pakeisdama dalykus, kurių neprašiau keisti. Šis kriterijus FrontierCode yra absoliuti kliūtis.

6. Kodo kokybė – ar kodas laikosi saugyklos konvencijų?

AI parašo savo funkciją „nuo nulio“ užuot panaudojusi esamas pagalbines funkcijas iš lib/. Arba parenka kintamųjų pavadinimus, neatitinkančius projekto stiliaus. Arba logiką įdeda į netinkamą architektūros sluoksnį. Testo požiūriu viskas veikia. Techninio vadovo požiūriu toks kodas nebus sujungtas.

Kaip patikrinti AI kodą prieš atliekant push: 5 žingsniai#

1. Paleiskite visą testų rinkinį, ne tik su pakeitimu susijusius testus

   AI dažnai pakeičia ir su užduotimi nesusijusį kodą. Problema išryškės gretimuose testuose. Paleidžiu visą testų rinkinį (viena komanda npm test, nenurodydamas kelio), o ne tik konkretaus failo testus. Dideliuose projektuose patogu tai atlikti lygiagrečiai naudojant git worktree (žr. Git worktree Claude Code aplinkoje).

2. Paleiskite lint, stiliaus ir tipų patikras

   Trys komandos iš eilės: eslint ., prettier --check ., tsc --noEmit. AI agentas gali nepastebėti ir tabuliavimo ženklo, ir papildomo tarpo eilutės gale. Jei projekte taikomos griežtos patikros, prieš išleidimą paleiskite jas vietoje.

3. Patikrinkite patį testą

   Svarbiausia iš 5 patikrų. Kode padarau nedidelį „gedimą“ (pakeičiu return true į return false). Testas turėtų nepraeiti. Jei testas nepasiseka, AI jį parašė tik dėl vaizdo, todėl jis bevertis. Ištrinu testą ir paprašau AI jį perrašyti su privaloma sąlyga: testas turi nepraeiti su sugadinta versija.

4. Patikrinkite, kuriuos failus palietė AI

   Komanda git diff --stat parodo, kurie failai pasikeitė ir kiek eilučių. Jei AI, gavusi prašymą „pataisyti kontaktų formą“, palietė 12 failų, ji peržengė užduoties apimtį. Papildomus pakeitimus atšaukiu viena konkretaus failo komanda.

5. Atlikite saugumo patikrą naudodami paruoštą įgūdį

   Testai neaptinka SQL injection ar įrašytų tiesiai į kodą slaptažodžių. Naudoju paruoštą Claude Code saugumo įgūdį (žr. 754 paruošti saugumo įgūdžiai). Bent jau rankiniu būdu projekte paieškokite žodžių „password“, „secret“ ir „key“ kode ir patikrinkite, ar .env.example yra išsamus.

Visi 5 žingsniai apima 5 iš 6 FrontierCode kriterijų (1–5). Šeštasis kriterijus – kodo kokybė – tikrinamas automatiškai vykdant lint ir atliekant žmogaus peržiūrą.

Kas iš tikrųjų padidina tikimybę gauti sujungti tinkamą kodą?#

AI agentas neparuoštame projekte mato tik tą failą, kurį jam atidarėte. Jis nežino jūsų sprendimų istorijos, konvencijų ir modulių žemėlapio. Paprastiems pakeitimams tai nėra didelė problema. Sudėtingiems pakeitimams trūkstamas projekto kontekstas yra rizika, kurią verta mažinti. Etalono 13.4% skaičius neizoliuoja konteksto kokybės kaip šio rezultato priežasties.

Ką reikia padaryti, kad tuos 13 % paverstumėte kažkuo, ką iš tikrųjų galite perkelti į gamybinę aplinką:

1. Projekto taisyklės – kad AI atkurtų jūsų mąstymą, o ne interneto vidurkį.

Tai jūsų paruoštų sprendimų, įpročių ir išmoktų taisyklių rinkinys tokiu formatu, kurį AI agentas perskaito su kiekviena užklausa. Kai taisyklių yra 30+, AI nustoja išgalvoti „pramonės vidurkį“ ir pradeda siūlyti sprendimus jūsų stiliumi. Užduoties ribų peržengimą galima spręsti viena taisyklių eilute: „neliesk failų, kurie nėra aiškiai nurodyti užklausoje.“

2. Projekto žemėlapis – aplankas, kuriame aprašytas projektas.

Čia sudedami produktai, auditorija, ekonomika, metrikos ir sąrankos. Prieš kiekvieną užklausą AI agentas perskaito turinį ir supranta, kurioje verslo dalyje dirba. Tai padeda agentui atsižvelgti į stilių ir regresijų riziką, tačiau abu dalykus reikia patikrinti tikrame pataisyme.

3. Context Engineering – valdymas to, ką AI mato prieš užklausą.

Tai ne „kaip suformuluoti promptą“, o „ką įtraukti į konteksto langą PRIEŠ promptą“. CLAUDE.md, išankstinės sąlygos ir tikslinės nuorodos į failus. Tai padeda pasiruošti elgsenos teisingumo ir kodo kokybės patikroms; jų rezultatus vis tiek reikia patvirtinti.

Šį derinį naudokite pasiruošimui patikroms, o ne kaip įrodymą, kad penki kriterijai jau įvykdyti. Prieš priimdami tikrą pataisymą patikrinkite elgseną, regresijas, testus, apimtį ir kodo kokybę.

Papildomas sluoksnis – peržiūros agentai:

• Cursor Bugbot – peržiūri kiekvieną PR. Pasak Cursor, įrankis apdoroja apie 2 milijonus PR per mėnesį.
• Įdėtiniai subagentai Claude Code v2.1.172 – vienas agentas rašo kodą, antras jį peržiūri, trečias vykdo testus. Tai ta pati FrontierCode idėja: atskirti „rašytojo“ ir „techninio vadovo“ vaidmenis.

Taip pat žr.: Vibe coding saugumas, Kaip sukonfigūruoti Claude Code, kad naktį nesugadintų projekto ir Context Engineering kaip sąvoka.

Daugiau medžiagos apie darbą su įrankiais rasite Ailoot dokumentacijoje.