FrontierCode Diamond: 13.4 % sammenslåbare patcher på 50 vanskelige oppgaver (juni 2026)

Mer materiale om konfigurering av verktøy finnes i Ailoot-dokumentasjonen.

Hva er FrontierCode, og hvorfor er det viktig?#

Cognition er selskapet bak Devin (den første autonome AI-ingeniøren, mars 2024) og Windsurf (kjøpt opp i juli 2025). De utvikler også sin egen modellserie, SWE-1.x. Benchmarken ble publisert på den offentlige bloggen på cognition.com/blog/frontier-code.

Det viktigste skiftet handler ikke om nye tall. Det handler om målestokken vi bruker for å måle ting nå.

Benchmarken har tre vanskelighetsnivåer: Extended (150 oppgaver, hele settet), Main (de 100 vanskeligste, inkludert Diamond) og Diamond (50 beinharde oppgaver). Cognition lot med vilje Diamond være «stort sett umettet» — selv den beste modellen løser færre enn 15 %. Målet er å gi benchmarken et års forsprang og hindre at den mettes på en måned, slik HumanEval gjorde.

Hva måler FrontierCode: «Ville vedlikeholderen slått sammen denne PR-en?»#

De seks evalueringsaksene (fra Cognitions offisielle blogg):

1. Funksjonell korrekthet — løser patchen oppgaven?
2. Regresjonssikkerhet — unngår den å ødelegge eksisterende kode?
3. Teknisk ryddighet — består den bygge-, lint- og stilkontrollene?
4. Testenes korrekthet — er testene agenten har skrevet gyldige (tester som består for all slags kode, teller ikke)?
5. Omfang — unngår patchen å berøre filer som ikke ble etterspurt?
6. Kodekvalitet — følger koden prosjektets konvensjoner, og er den lesbar?

For at en patch skal regnes som klar til sammenslåing, må den bestå alle seks aksene. Stryk på bare én, så blir den ikke slått sammen.

Det er hovedskiftet i perspektiv. «Korrekthet er nå et grunnkrav», som Cognition uttrykker det. Før spurte benchmarkene: «Bestod koden testene?» Nå spør de: «Ville en ekte teknisk leder tatt dette inn i prosjektet?»

Cognition introduserte tre nye vurderingsteknikker:

• Reverse-Classical: En test skrevet av en agent må feile på en ødelagt versjon av koden. Hvis ikke, er testen bare skuebrød.
• Code Scope: En automatisk kontrollør verifiserer at en patch holder seg innenfor filene og antall linjer som ble avtalt for oppgaven.
• Adaptive Classical Grading: LLM-verktøyet «mutagent» tilpasser strenge tester til gyldige løsningsvarianter.

Hvorfor fungerer ikke de gamle benchmarkene lenger?#

AI-agenter hadde allerede knust HumanEval innen 2024. SWE-bench Verified er omtrent det samme: I august 2025 innrømmet OpenAI offentlig problemet med kontaminering (modellene hadde «sett» datasettet under trening). Benchmarkene mistet evnen til å skille mellom de beste modellene.

Studien som undergravde den gamle målestokken, kom i mars 2026.

Dette gjorde de:

• Valgte ut 4 aktive vedlikeholdere fra 3 repositorier (scikit-learn, Sphinx, pytest).
• Lot dem evaluere 296 AI-genererte PR-er fra SWE-bench Verified — alle disse PR-ene bestod automatiserte tester.
• Sammenlignet vedlikeholdernes avgjørelser med avgjørelsene til den automatiske evaluatoren.

Med andre ord sier benchmarken «bestått», mens vedlikeholderen sier «blir ikke slått sammen» — og det skjer i gjennomsnitt i en fjerdedel av tilfellene. De 3 viktigste grunnene til avslag, fra minst til mest alvorlig:

1. Kodekvalitet — samsvarer ikke med stilen i repositoriet.
2. Ødelegger annen kode — ødelegger kode i nærheten.
3. Kjernefunksjonaliteten svikter — løser ikke oppgaven fullt ut, selv om testen er grønn.

FrontierCode formaliserer akkurat dette problemet. Cognition tok denne ideen og utvidet den til en fullstendig benchmark med mer enn 20 vedlikeholdere i stedet for 4.

En annen spiker i kista er en studie fra desember 2025 om sikkerheten i AI-genererte patcher.

I studien var 61 % av SWE-Agent-løsningene med Claude 4 Sonnet funksjonelt korrekte, men bare 10.5 % av dem var trygge.

Koden består testen, og likevel introduserer annenhver patch et sikkerhetshull. Dette ser du ikke i det hele tatt i SWE-bench-benchmarkene — de måler ikke sikkerhet. FrontierCode prøver i det minste å fange det opp gjennom aksene «teknisk ryddighet» og kodekvalitet.

Modellrangering: Opus 4.8 på 13.4 %, GPT-5.5 på 6.3 %#

Dette skiller seg ut i tabellen:

• Én tydelig leder. Opus 4.8 fra Anthropic ligger omtrent dobbelt så langt foran som nærmeste konkurrent. Gapet som var vanskelig å legge merke til på SWE-bench, er tydelig på FrontierCode.
• Åpne modeller har ikke tatt igjen forspranget ennå. Kimi K2.6 — den beste åpne kodemodellen — får 3.8 % på Diamond. Det er 3–4 ganger lavere enn Opus 4.8. Cognition publiserte ikke en fullstendig Kimi K2.6-tabell for Main og Extended, så det finnes ennå ingen sammenligning på hele settet.
• Cognition plasserte ærlig sin egen modell i den nedre delen av tabellen.

Diamond-delmengden ble med vilje holdt «umettet». Cognition bygde inn en sikkerhetsmargin for årene framover. Hvis tidligere benchmarker ble mettet innen 12–18 måneder, er FrontierCode utformet for å ha større takhøyde.

Hva betyr «13 % kan slås sammen» for en vibe-koder som bruker Claude Code?#

Først en viktig nyansering: Diamond-settet til FrontierCode er bevisst ekstremt krevende. På vanlige oppgaver i et nytt startup-prosjekt uten førti avhengige moduler gjør en AI-agent det merkbart bedre. Den samme Opus 4.8 får 51.8 % kode som kan slås sammen på Extended (150 oppgaver, hele settet). Det gir et helt annet bilde.

Resultatet på 51.8 % gjelder benchmarkens Extended-sett med 150 oppgaver. Det er høyere enn Diamond-resultatet, men ingen av tallene anslår sammenslåbarheten til enhver modells patcher på dine oppgaver. Manglende Main- eller Extended-scorer for andre modeller gir ikke grunnlag for å fylle inn ytelsen deres.

Hva dette betyr for en vibe-koder som pusher til produksjon:

• En grønn test betyr ikke lenger «klar til sammenslåing». Tester AI selv har skrevet, kan være verdiløse — de består for all slags kode. FrontierCode måler dette direkte med Reverse-Classical: Hvis en test ikke feiler på en ødelagt versjon, teller den ikke.
• Repository-stil og konvensjoner betyr noe. Hvis et prosjekt har en etablert praksis og AI ikke følger den, vil en ekte samarbeidspartner ikke godta endringen. I soloprosjekter uten regler er ikke dette så viktig. I et team er det problem nummer én.
• Tester løser ikke sikkerhetsproblemer. Husk tallet ovenfor: Bare 10.5 % av patchene er trygge, selv om 61 % er korrekte. Dette må kontrolleres separat med verktøy som fanger opp tokens, .env-filer og standardpassord.
• Å gå utover oppgaven er en typisk AI-feil. Du ber den rette en autorisasjonsfunksjon og får en patch som også skrev om det interne laget og loggingen. Dette er en av de 6 aksene til FrontierCode.

Hvilke 6 typer feil gjør AI på vanskelige oppgaver?#

La oss gå gjennom hver akse i klare ord:

1. Funksjonell korrekthet — løser patchen oppgaven?

Den mest grunnleggende aksen. AI skriver ofte kode som ser ut som en løsning, men løser feil problem. Jeg ber om å «legge til en lesebekreftelse på meldingen» og får en markAsRead-funksjon, men den er ikke koblet til selve chatkomponenten. Funksjonstesten består. Forretningsoppgaven er ikke løst.

2. Regresjonssikkerhet — unngår den å ødelegge kode i nærheten?

AI endrer én modul, og nå fungerer ikke en annen. Det vanligste tilfellet er at en AI-agent endrer en funksjonssignatur og glemmer at den kalles fra 17 andre steder. Dette ser du ikke på SWE-bench — der kjører de bare tester for én fil. På FrontierCode kjører de hele testpakken for repositoriet.

3. Teknisk ryddighet — består den bygge-, lint- og stilkontrollene?

AI kan lage kode som kompilerer lokalt, men feiler i CI: en manglende import, tabulatorer i stedet for mellomrom, to avsluttende mellomrom eller en glipp i eslint.config.js. I et aktivt prosjekt er ikke stil et innfall; det er en teamregel.

4. Testenes korrekthet — er testene AI har skrevet gyldige?

Den vanskeligste aksen. AI skriver en test som består. Men den består for all slags kode, også ødelagt kode. Jeg har sett dette mange ganger: Testen sjekker «kræsjet skriptet?», men ikke «returnerte det riktig resultat?» Reverse-Classical i FrontierCode fanger opp akkurat dette tilfellet.

5. Omfang — unngår patchen å berøre uvedkommende filer?

Jeg ber om å rette én funksjon og får en patch for 12 filer, inkludert filer som ikke har noe med oppgaven å gjøre. Dette er akkurat den typen «initiativ» fra AI som ødelegger et produksjonsprosjekt ved å endre ting jeg ikke ba den endre. Denne aksen er en absolutt blokkering i FrontierCode.

6. Kodekvalitet — følger koden konvensjonene i repositoriet?

AI skriver sin egen funksjon «fra bunnen av» i stedet for å bruke eksisterende hjelpere i lib/. Eller den navngir variabler på en måte som ikke passer stilen i prosjektet. Eller den plasserer logikk i feil arkitekturlag. Fra testens perspektiv fungerer alt. Fra den tekniske lederens perspektiv blir det ikke slått sammen.

Slik sjekker du AI-kode før du pusher: 5 trinn#

1. Kjør hele testpakken, ikke bare tester som gjelder endringen

   AI endrer ofte kode utenfor oppgaven. Problemet dukker opp i tester for nærliggende deler. Jeg kjører hele testpakken (med den ene kommandoen npm test, uten en sti), ikke bare testene for en bestemt fil. I store prosjekter er det praktisk å gjøre dette parallelt med en git worktree (se Git worktree i Claude Code).

2. Kjør lint-, stil- og typesjekker

   Tre kommandoer i rekkefølge: eslint ., prettier --check ., tsc --noEmit. En AI-agent kan overse både tabulatorer og et ekstra avsluttende mellomrom. Hvis prosjektet har strenge kontroller, kjør dem lokalt før lansering.

3. Test selve testen

   Den viktigste av de 5 kontrollene. Gjør en liten «feil» i koden (endre return true til return false). Testen skal feile. Hvis testen ikke feiler, skrev AI den bare for syns skyld, og den er ubrukelig. Jeg sletter testen og ber AI skrive den på nytt med et obligatorisk krav: Testen må feile på den ødelagte versjonen.

4. Sjekk hvilke filer AI har endret

   Kommandoen git diff --stat viser hvilke filer som er endret og hvor mange linjer. Hvis AI endret 12 filer etter forespørselen «fiks kontaktskjemaet», gikk den utover oppgavens omfang. Jeg tilbakestiller de ekstra endringene med én kommando for hver fil.

5. Kjør en sikkerhetskontroll med en ferdig skill

   Tester fanger ikke opp SQL-injeksjoner eller hardkodede passord. Jeg bruker en ferdig sikkerhets-skill for Claude Code (se 754 ferdige sikkerhetsskills). Søk i det minste manuelt gjennom prosjektet etter ordene «password», «secret» og «key», og kontroller at .env.example er komplett.

Alle 5 trinnene dekker 5 av de 6 aksene til FrontierCode (1–5). Den sjette aksen — kodekvalitet — kontrolleres automatisk gjennom linting og en menneskelig gjennomgang.

Hva øker egentlig sjansen for kode som kan slås sammen?#

En AI-agent i et uforberedt prosjekt ser bare filen du har åpnet for den. Den kjenner verken beslutningshistorikken din eller konvensjonene dine, og den har ikke noe kart over modulene dine. Ved enkle endringer er ikke det så farlig. Ved vanskelige endringer er manglende prosjektkontekst en risiko det er verdt å håndtere. Benchmarkens tall på 13.4 % isolerer ikke kontekstkvalitet som årsaken.

Dette må du gjøre for å gjøre de 13 % om til noe du faktisk kan pushe til produksjon:

1. Prosjektregler — slik at AI gjenskaper resonnementet ditt i stedet for gjennomsnittet fra internett.

Dette er et sett med ferdige løsninger, vaner og lærte regler fra deg i et format som AI-agenten leser ved hver forespørsel. Når det er mer enn 30 regler, slutter AI å finne på «bransjens gjennomsnitt» og begynner å foreslå løsninger i din stil. Du kan håndtere avvik fra oppgavens omfang med én linje i reglene: «ikke rør filer utenfor dem som uttrykkelig er nevnt i forespørselen.»

2. Et prosjektkart — en mappe som beskriver prosjektet.

Her legger du produkter, målgruppe, økonomi, måltall og oppsett. Før hver forespørsel leser AI-agenten innholdsfortegnelsen og forstår hvilken del av virksomheten den jobber med. Dette tar automatisk tak i to av avslagsgrunnene nevnt ovenfor: stil og det å ødelegge annen kode.

3. Context Engineering — styring av hva AI ser før forespørselen.

Det handler ikke om «hvordan du formulerer en prompt», men om «hva du legger i kontekstvinduet FØR prompten». CLAUDE.md, forutsetninger og målrettede lenker til filer. Dette tar tak i feil knyttet til funksjonell korrekthet og kodekvalitet.

Bruk kombinasjonen som forberedelse til kontrollene, ikke som bevis for at fem akser allerede består. Kontroller atferd, regresjoner, tester, omfang og kodekvalitet på den faktiske patchen før du godtar den.

Et ekstra lag er review-agenter:

• Cursor Bugbot — gjennomfører en gjennomgang av hver PR. Ifølge Cursor behandler verktøyet rundt 2 millioner PR-er i måneden.
• Nestede underagenter i Claude Code v2.1.172 — én agent skriver koden, en annen gjennomgår den, og en tredje kjører tester. Det er samme idé som i FrontierCode: å skille rollene «skribent» og «teknisk leder».

Se også: Vibe Coding-sikkerhet, Slik konfigurerer du Claude Code så det ikke ødelegger prosjektet ditt om natten og Context Engineering som konsept.

Se Ailoot-dokumentasjonen for mer materiale om bruk av verktøy.