FrontierCode Diamond: 13.4% yhdistämiskelpoisia päivityksiä 50 vaikeassa tehtävässä (kesäkuu 2026)

Lisämateriaalia työkalujen määrittämisestä on Ailoot-dokumentaatiossa.

Mikä FrontierCode on, ja miksi sillä on merkitystä?#

Cognition on Devinin (ensimmäinen autonominen tekoälyinsinööri, maaliskuu 2024) ja Windsurfin (ostettu heinäkuussa 2025) taustalla oleva yritys. Se kehittää myös omaa SWE-1.x-mallisarjaansa. Benchmark julkaistiin julkisessa blogissa osoitteessa cognition.com/blog/frontier-code.

Keskeinen muutos ei koske uusia lukuja. Se koskee sitä mittapuuta, jolla asioita nyt mitataan.

Benchmarkissa on kolme vaikeustasoa: Extended (150 tehtävää, koko joukko), Main (100 vaikeinta, mukaan lukien Diamond) ja Diamond (50 erityisen vaikeaa tehtävää). Cognition jätti Diamondin tarkoituksella ”suurelta osin kyllästymättömäksi” – paras mallikin ratkaisee alle 15 %. Tarkoituksena on antaa benchmarkille vuoden verran liikkumavaraa ja estää sitä kyllästymästä kuukaudessa, kuten HumanEvalille kävi.

Mitä FrontierCode mittaa: ”Yhdistäisikö ylläpitäjä tämän PR:n?”#

Kuusi arviointiosa-aluetta (Cognitionin virallisesta blogista):

1. Toiminnallinen oikeellisuus — ratkaiseeko päivitys tehtävän?
2. Regressioturvallisuus — välttääkö se olemassa olevan koodin rikkomisen?
3. Tekninen siisteys — läpäiseekö se koonti-, lint- ja tyylitarkistukset?
4. Testien oikeellisuus — ovatko agentin kirjoittamat testit kelvollisia (testit, jotka läpäisevät millä tahansa koodilla, eivät kelpaa)?
5. Laajuus — välttääkö päivitys sellaisten tiedostojen muokkaamista, joita ei pyydetty?
6. Koodin laatu — noudattaako koodi projektin käytäntöjä ja onko se luettavaa?

Jotta päivitys lasketaan yhdistämiskelpoiseksi, sen täytyy läpäistä kaikki kuusi osa-aluetta. Jos yksikin jää läpäisemättä, sitä ei yhdistetä.

Tämä on tärkein näkökulman muutos. ”Oikeellisuus on nyt lähtötaso”, kuten Cognition asian ilmaisee. Aiemmin benchmarkit kysyivät: ”Läpäisikö koodi testit?” Nyt ne kysyvät: ”Ottaisiko oikea tekninen vetäjä tämän osaksi projektia?”

Cognition esitteli kolme uutta arviointitekniikkaa:

• Reverse-Classical: agentin kirjoittaman testin täytyy epäonnistua koodin rikkinäisessä versiossa. Muuten testi on huijausta.
• Code Scope: automaattinen tarkistin varmistaa, että päivitys pysyy tehtävässä sovituissa tiedostoissa ja rivimäärässä.
• Adaptive Classical Grading: LLM-työkalu ”mutagent” mukauttaa tiukkoja testejä kelvollisiin ratkaisumuunnelmiin.

Miksi vanhat benchmarkit eivät enää toimi?#

Tekoälyagentit olivat jo selvittäneet HumanEvalin loistavasti vuoteen 2024 mennessä. SWE-bench Verified on pitkälti samanlainen: elokuussa 2025 OpenAI myönsi julkisesti kontaminaatio-ongelman (mallit olivat ”nähneet” aineiston koulutuksen aikana). Benchmarkit menettivät kykynsä erotella huippumalleja toisistaan.

Vanhan mittarin kyseenalaistanut keskeinen tutkimus julkaistiin maaliskuussa 2026.

Tutkimuksessa tehtiin näin:

• Valittiin 4 aktiivista ylläpitäjää 3 repositoriosta (scikit-learn, Sphinx, pytest).
• He arvioivat 296 tekoälyn tuottamaa PR:ää SWE-bench Verified -aineistosta — kaikki nämä PR:t läpäisivät automaattiset testit.
• Ylläpitäjien päätöksiä verrattiin automaattisen arvioijan päätöksiin.

Toisin sanoen benchmark sanoo ”läpäisi”, mutta ylläpitäjä sanoo ”ei yhdistetä” — ja näin käy keskimäärin neljäsosassa tapauksista. Kolme yleisintä hylkäyksen syytä vakavimmasta lievimpään:

1. Koodin laatu — ei vastaa repositorion tyyliä.
2. Muun koodin rikkominen — rikkoo viereistä koodia.
3. Ydintoiminnon virhe — ei ratkaise tehtävää kokonaan, vaikka testi menee läpi.

FrontierCode virallistaa juuri tämän ongelman. Cognition otti tämän idean ja laajensi sen täysimittaiseksi benchmarkiksi, jossa on yli 20 ylläpitäjää neljän sijaan.

Toinen naula arkkuun on joulukuussa 2025 julkaistu tutkimus tekoälyn tuottamien korjausten tietoturvasta.

Siinä 61% SWE-Agentin ratkaisuista Claude 4 Sonnetilla oli toiminnallisesti oikeita, mutta vain 10.5% niistä oli turvallisia.

Koodi läpäisee testin, mutta joka toinen päivitys tuo silti mukanaan tietoturva-aukon. Tätä ei näe lainkaan SWE-bench-benchmarkeissa — ne eivät mittaa tietoturvaa. FrontierCode yrittää ainakin havaita sen ”teknisen siisteyden” ja koodin laadun osa-alueilla.

Mallien sijoitukset: Opus 4.8 saa 13.4%, GPT-5.5 6.3%#

Taulukosta erottuu seuraavaa:

• Yksi selkeä johtaja. Anthropicin Opus 4.8 on noin kaksi kertaa edellä lähintä kilpailijaa. Ero, jota oli vaikea huomata SWE-benchissä, näkyy selvästi FrontierCodessa.
• Avoimen koodin mallit eivät ole vielä saavuttaneet kärkeä. Kimi K2.6 — paras avoimen koodin malli — saa Diamondissa 3.8%. Se on 3–4 kertaa vähemmän kuin Opus 4.8. Cognition ei julkaissut Kimi K2.6:n täydellisiä tuloksia Main- ja Extended-osioissa, joten koko joukosta ei ole vielä vertailua.
• Cognition sijoitti rehellisesti oman mallinsa taulukon alaosaan.

Diamond-osajoukko jätettiin tarkoituksella ”kyllästymättömäksi”. Cognition rakensi siihen turvamarginaalin tuleviksi vuosiksi. Jos aiemmat benchmarkit kyllästyivät 12–18 kuukaudessa, FrontierCode suunniteltiin korkeammalle tasolle.

Mitä ”13% yhdistämiskelpoisia” tarkoittaa Claude Codea käyttävälle vibe-koodaajalle?#

Ensin tärkeä näkökulman muutos: FrontierCoden Diamond-joukko on tarkoituksella erittäin vaikea. Tavallisissa tehtävissä uudessa startup-projektissa ilman neljääkymmentä riippuvaa moduulia tekoälyagentti pärjää selvästi paremmin. Sama Opus 4.8 saa Extended-osiossa (150 tehtävää, koko joukko) 51.8% yhdistämiskelpoisia tuloksia. Kuva on aivan toinen.

51.8% tulos koskee benchmarkin 150 tehtävän Extended-joukkoa. Se on Diamond-tulosta korkeampi, mutta kumpikaan luku ei arvioi jokaisen mallin päivitysten yhdistämiskelpoisuutta omissa tehtävissäsi. Muiden mallien puuttuvat Main- tai Extended-tulokset eivät oikeuta täyttämään niiden suorituskykyä oletuksilla.

Mitä tämä tarkoittaa tuotantoon koodia vievälle vibe-koodaajalle:

• Vihreä testi ei enää tarkoita ”valmis yhdistettäväksi”. Tekoälyn itsensä kirjoittamat testit voivat olla hyödyttömiä — ne läpäisevät millä tahansa koodilla. FrontierCode mittaa tämän suoraan Reverse-Classical-menetelmällä: jos testi ei epäonnistu rikkinäisellä versiolla, sitä ei lasketa.
• Repositorion tyylillä ja käytännöillä on merkitystä. Jos projektissa on vakiintunut toimintamalli eikä tekoäly noudata sitä, oikea yhteistyökumppani ei hyväksy muutosta. Yksin tehdyissä projekteissa ilman sääntöjä tällä ei ole suurta merkitystä. Tiimissä se on ongelma numero yksi.
• Testit eivät ratkaise tietoturvaa. Muista yllä mainittu luku: vain 10.5% päivityksistä on turvallisia, vaikka 61% on oikein. Tämä on tarkistettava erikseen työkaluilla, jotka löytävät tokenit, .env-tiedostot ja oletussalasanat.
• Tehtävän ylittäminen on tyypillinen tekoälyvirhe. Pyydät korjaamaan valtuutustoiminnon ja saat päivityksen, joka kirjoitti myös sisäisen kerroksen ja lokituksen uusiksi. Tämä on yksi FrontierCoden 6 osa-alueesta.

Mitä 6 virheluokkaa tekoäly tekee vaikeissa tehtävissä?#

Käydään jokainen osa-alue läpi selkokielellä:

1. Toiminnallinen oikeellisuus — ratkaiseeko päivitys tehtävän?

Perustavin osa-alue. Tekoäly kirjoittaa usein koodia, joka näyttää ratkaisulta mutta ratkaisee väärän ongelman. Pyydän sitä ”lisäämään viestiin lukukuittauksen” ja saan markAsRead-funktion, mutta sitä ei ole yhdistetty itse chat-komponenttiin. Funktiotesti menee läpi. Liiketoiminnan tehtävä jää ratkaisematta.

2. Regressioturvallisuus — välttääkö se viereisen koodin rikkomisen?

Tekoäly muuttaa yhtä moduulia, minkä jälkeen toinen ei enää toimi. Yleisin tapaus: tekoälyagentti muuttaa funktion allekirjoitusta ja unohtaa, että sitä kutsutaan 17 muusta kohdasta. Tätä ei näe SWE-benchissä — siinä testataan vain yhtä tiedostoa. FrontierCodessa ajetaan repositorion koko testipaketti.

3. Tekninen siisteys — läpäiseekö se koonti-, lint- ja tyylitarkistukset?

Tekoäly voi tuottaa koodia, joka kääntyy paikallisesti mutta epäonnistuu CI:ssä: import puuttuu, välilyöntien sijaan on sarkaimia, rivin lopussa on kaksi ylimääräistä välilyöntiä tai eslint.config.js-tiedostossa on virhe. Käynnissä olevassa projektissa tyyli ei ole päähänpisto vaan tiimin sääntö.

4. Testien oikeellisuus — ovatko tekoälyn kirjoittamat testit kelvollisia?

Hankalin osa-alue. Tekoäly kirjoittaa testin, joka läpäisee. Mutta se läpäisee millä tahansa koodilla, myös rikkinäisellä. Olen nähnyt tämän monta kertaa: testi tarkistaa, ”kaatuiko skripti?”, muttei sitä, ”palauttiko se oikean tuloksen?” FrontierCoden Reverse-Classical havaitsee juuri tämän tapauksen.

5. Laajuus — välttääkö päivitys asiaan liittymättömien tiedostojen muuttamisen?

Pyydän sitä korjaamaan yhden funktion ja saan päivityksen 12 tiedostoon, mukaan lukien tiedostoja, joilla ei ole mitään tekemistä tehtävän kanssa. Tämä on juuri sitä tekoälyn ”oma-aloitteisuutta”, joka rikkoo tuotantoprojektin muuttamalla asioita, joita en pyytänyt muuttamaan. Tämä osa-alue on FrontierCodessa ehdoton este.

6. Koodin laatu — noudattaako koodi repositorion käytäntöjä?

Tekoäly kirjoittaa oman funktion ”alusta alkaen” sen sijaan, että käyttäisi olemassa olevia apufunktioita hakemistossa lib/. Tai se nimeää muuttujat tavalla, joka ei vastaa projektin tyyliä. Tai se sijoittaa logiikan väärään arkkitehtuurikerrokseen. Testin näkökulmasta kaikki toimii. Teknisen vetäjän näkökulmasta muutosta ei yhdistetä.

Näin tarkistat tekoälyn koodin ennen pushia: 5 vaihetta#

1. Suorita koko testipaketti, älä vain muutokseen liittyviä testejä

   Tekoäly muuttaa usein tehtävän ulkopuolista koodia. Ongelma näkyy viereisissä testeissä. Suoritan koko testipaketin yhdellä komennolla npm test, ilman polkua, en vain tietyn tiedoston testejä. Suurissa projekteissa tämän voi ajaa kätevästi rinnakkain git worktreen avulla (katso Git worktree Claude Codessa).

2. Suorita lint-, tyyli- ja tyyppitarkistukset

   Kolme komentoa järjestyksessä: eslint ., prettier --check ., tsc --noEmit. Tekoälyagentilta voi jäädä huomaamatta sekä sarkaimet että ylimääräinen välilyönti rivin lopussa. Jos projektissa on tiukat tarkistukset, suorita ne paikallisesti ennen julkaisua.

3. Testaa itse testi

   Tärkein viidestä tarkistuksesta. Teen koodiin pienen ”rikkomuksen” (vaihdan return true muotoon return false). Testin pitäisi epäonnistua. Jos testi ei epäonnistu, tekoäly kirjoitti sen vain näön vuoksi, ja se on hyödytön. Poistan testin ja pyydän tekoälyä kirjoittamaan sen uudelleen pakollisella ehdolla: testin täytyy epäonnistua rikkinäisellä versiolla.

4. Tarkista, mitä tiedostoja tekoäly muokkasi

   Komento git diff --stat näyttää muuttuneet tiedostot ja rivimäärät. Jos tekoäly muutti 12 tiedostoa vastauksena pyyntöön ”korjaa yhteydenottolomake”, se ylitti tehtävän laajuuden. Palautan ylimääräiset muutokset yhdellä kyseistä tiedostoa koskevalla komennolla.

5. Tee tietoturvatarkistus valmiilla skillillä

   Testit eivät havaitse SQL-injektioita tai koodiin kovakoodattuja salasanoja. Käytän valmista tietoturva-skilliä Claude Codea varten (katso 754 valmista tietoturva-skilliä). Etsi vähintään käsin projektin koodista sanat ”password”, ”secret” ja ”key” ja tarkista, että .env.example on kattava.

Kaikki 5 vaihetta kattavat 5 FrontierCoden 6 osa-alueesta (1–5). Kuudes osa-alue — koodin laatu — tarkistetaan automaattisesti linttauksen ja ihmisen tekemän katselmoinnin avulla.

Mikä oikeasti parantaa yhdistämiskelpoisen koodin mahdollisuuksia?#

Valmistautumattomassa projektissa tekoälyagentti näkee vain tiedoston, jonka olet avannut sille. Sillä ei ole tietoa päätöshistoriastasi tai käytännöistäsi eikä karttaa moduuleistasi. Yksinkertaisissa muutoksissa tämä ei haittaa paljon. Vaikeissa muutoksissa puuttuva projektikonteksti on korjattava riski. Benchmarkin 13.4% luku ei eristä kontekstin laatua sen syyksi.

Näin valmistelet muutoksen tarkistettavaksi:

1. Projektin säännöt — jotta tekoäly jäljittelee päättelyäsi internetin keskiarvon sijaan.

Tämä on kokoelma valmiita ratkaisujasi, tapojasi ja opittuja sääntöjä muodossa, jonka tekoälyagentti lukee jokaisen pyynnön yhteydessä. Kun sääntöjä on 30+, tekoäly lakkaa keksimästä ”toimialan keskiarvoa” ja alkaa ehdottaa asioita sinun tyylilläsi. Tehtävän laajuuden ylittämistä voi ehkäistä yhdellä sääntöihin lisättävällä rivillä: ”älä koske muihin kuin pyynnössä nimenomaisesti mainittuihin tiedostoihin.”

2. Projektin kartta — kansio, joka kuvaa projektin.

Tänne laitetaan tuotteet, yleisö, talous, mittarit ja konfiguraatiot. Ennen jokaista pyyntöä tekoälyagentti lukee sisällysluettelon ja ymmärtää, minkä liiketoiminnan osan parissa se työskentelee. Tämä ratkaisee automaattisesti kaksi edellä mainituista hylkäyssyistä: tyylin ja muun koodin rikkomisen.

3. Context Engineering — hallitse sitä, mitä tekoäly näkee ennen pyyntöä.

Kyse ei ole siitä, ”miten prompti muotoillaan”, vaan siitä, ”mitä konteksti-ikkunaan lisätään ENNEN promptia”. CLAUDE.md, esitiedot ja kohdennetut linkit tiedostoihin. Tämä auttaa toiminnallisen oikeellisuuden ja koodin laadun ongelmiin.

Käytä yhdistelmää tarkistuksiin valmistautumiseen, älä näyttönä viiden osa-alueen läpäisystä. Varmista todellisesta päivityksestä toiminta, regressiot, testit, laajuus ja koodin laatu ennen hyväksymistä.

Lisäkerroksena ovat katselmointiagentit:

• Cursor Bugbot — tekee katselmoinnin jokaiselle PR:lle. Cursorin mukaan työkalu käsittelee noin 2 miljoonaa PR:ää kuukaudessa.
• Sisäkkäiset aliagentit Claude Code v2.1.172:ssa — yksi agentti kirjoittaa koodin, toinen arvioi sen ja kolmas suorittaa testit. Idea on sama kuin FrontierCodessa: ”kirjoittajan” ja ”teknisen vetäjän” roolit erotetaan toisistaan.

Katso myös: Vibe Coding Security, Näin määrität Claude Coden niin, ettei se riko projektiasi yöllä ja Context Engineering käsitteenä.

Lisämateriaalia työkalujen käytöstä on Ailoot-dokumentaatiossa.