FrontierCode Diamond: 13.4% patches, der kan flettes ind, på 50 svære opgaver (juni 2026)

Yderligere materiale om konfiguration af værktøjer findes i Ailoot-dokumentationen.

Hvad er FrontierCode, og hvorfor er det vigtigt?#

Cognition er virksomheden bag Devin (den første autonome AI-ingeniør, marts 2024) og Windsurf (opkøbt i juli 2025). De udvikler også deres egen modelserie SWE-1.x. Benchmarken blev udgivet på den offentlige blog på cognition.com/blog/frontier-code.

Det afgørende skifte handler ikke om nye tal. Det handler om den målestok, man bruger nu.

Benchmarken har tre sværhedsgrader: Extended (150 opgaver, hele sættet), Main (de 100 sværeste, inklusive Diamond) og Diamond (50 ekstremt svære opgaver). Cognition lod bevidst Diamond være “stort set umættet” — selv den bedste model løser færre end 15%. Det skal give benchmarken et års råderum og forhindre, at den bliver mættet på en måned, som HumanEval blev.

Hvad måler FrontierCode: “Ville vedligeholderen slå denne PR sammen?”#

De seks evalueringsakser (fra Cognitions officielle blog):

1. Adfærdsmæssig korrekthed — løser patchen opgaven?
2. Regressionssikkerhed — undgår den at ødelægge eksisterende kode?
3. Mekanisk renhed — består den build-, lint- og stilkontrollerne?
4. Testenes korrekthed — er de tests, agenten har skrevet, gyldige (tests, der består med vilkårlig kode, tæller ikke)?
5. Omfang — undgår patchen at ændre filer, der ikke blev bedt om?
6. Kodekvalitet — følger koden projektets konventioner, og er den læsbar?

For at en patch kan tælle som klar til sammenfletning, skal den bestå alle seks akser. Dumper den blot på én, bliver den ikke flettet ind.

Det er det væsentligste perspektivskifte. “Korrekthed er nu en selvfølge,” som Cognition udtrykker det. Før spurgte benchmarks: “Bestod koden testene?” Nu spørger de: “Ville en rigtig teknisk leder tage den ind i projektet?”

Cognition introducerede tre nye bedømmelsesteknikker:

• Reverse-Classical: En test skrevet af en agent skal fejle på en ødelagt version af koden. Ellers er testen snyd.
• Code Scope: En automatisk kontrollør verificerer, at en patch holder sig inden for de filer og det linjeantal, der er aftalt for opgaven.
• Adaptive Classical Grading: LLM-værktøjet “mutagent” tilpasser strenge tests til gyldige løsningsvarianter.

Hvorfor fungerer de gamle benchmarks ikke længere?#

AI-agenter havde allerede klaret HumanEval med bravur i 2024. SWE-bench Verified er stort set det samme: I august 2025 erkendte OpenAI offentligt kontamineringsproblemet (modellerne havde “set” datasættet under træningen). Benchmarks mistede deres evne til at skelne mellem topmodeller.

Det afgørende studie, der underminerede den gamle målestok, udkom i marts 2026.

Det gjorde de:

• Udvalgte 4 aktive vedligeholdere fra 3 repositories (scikit-learn, Sphinx, pytest).
• Lod dem evaluere 296 AI-genererede PR'er fra SWE-bench Verified — alle disse PR'er bestod automatiserede tests.
• Sammenlignede vedligeholdernes beslutninger med den automatiske evaluators.

Med andre ord siger benchmarken “bestået”, mens vedligeholderen siger “bliver ikke flettet ind” — og det sker i gennemsnit i en fjerdedel af tilfældene. De 3 vigtigste årsager til afvisning, fra mindst til mest alvorlig:

1. Kodekvalitet — passer ikke til repositoryets stil.
2. Ødelægger anden kode — bryder kode i nærheden.
3. Fejl i kernefunktionaliteten — løser ikke opgaven helt, selvom testen er grøn.

FrontierCode formaliserer netop dette problem. Cognition tog denne idé og udvidede den til en fuld benchmark med mere end 20 vedligeholdere i stedet for 4.

Endnu et søm i kisten er et studie fra december 2025 om sikkerheden i AI-genererede patches.

I studiet var 61% af SWE-Agent-løsningerne med Claude 4 Sonnet funktionelt korrekte, men kun 10.5% af dem var sikre.

Koden består testen, men hver anden patch indfører alligevel et sikkerhedshul. Det kan man slet ikke se på SWE-bench-benchmarks — de måler ikke sikkerhed. FrontierCode forsøger i det mindste at fange det gennem akserne “mekanisk renhed” og kodekvalitet.

Sådan rangerer modellerne: Opus 4.8 på 13.4%, GPT-5.5 på 6.3%#

Det, der springer i øjnene i tabellen:

• Én tydelig leder. Anthropics Opus 4.8 er omtrent dobbelt så langt foran som nærmeste konkurrent. Forskellen, der var svær at få øje på i SWE-bench, er tydelig i FrontierCode.
• Åbne modeller er ikke fulgt med endnu. Kimi K2.6 — den bedste model med åben kode — scorer 3.8% på Diamond. Det er 3–4 gange lavere end Opus 4.8. Cognition offentliggjorde ikke en komplet Kimi K2.6-tabel for Main og Extended, så der er endnu ingen sammenligning på hele sættet.
• Cognition placerede ærligt sin egen model i den nederste del af tabellen.

Diamond-delmængden blev bevidst holdt “umættet”. Cognition indbyggede en sikkerhedsmargin for årene fremover. Hvis tidligere benchmarks blev mættet på 12–18 måneder, er FrontierCode designet med et højere loft.

Hvad betyder “13% kan flettes ind” for en vibe-koder, der bruger Claude Code?#

Først en vigtig omformulering: FrontierCodes Diamond-sæt er bevidst ekstremt svært. På almindelige opgaver i et nyt startup-projekt uden fyrre afhængige moduler klarer en AI-agent sig mærkbart bedre. Den samme Opus 4.8 scorer 51.8% sammenfletteligt på Extended (150 opgaver, hele sættet). Det er et helt andet billede.

Resultatet på 51.8% gælder benchmarkens Extended-sæt med 150 opgaver. Det er højere end Diamond-resultatet, men ingen af tallene anslår sammenfletningsegnethed for alle modellers patches på dine egne opgaver. Manglende Main- eller Extended-scorer for andre modeller giver ikke grundlag for at udfylde deres præstation.

Det betyder følgende for en vibe-koder, der sender til produktion:

• En grøn test betyder ikke længere “klar til sammenfletning”. Tests skrevet af AI selv kan være dårlige — de består med hvilken som helst kode. FrontierCode måler det direkte gennem Reverse-Classical: Hvis en test ikke fejler på en ødelagt version, tæller den ikke.
• Repositoryets stil og konventioner betyder noget. Hvis et projekt har et etableret mønster, og AI ikke følger det, accepterer en rigtig samarbejdspartner ikke ændringen. I soloprojekter uden regler er det ikke noget stort problem. På et team er det problem nummer ét.
• Tests løser ikke sikkerhedsproblemer. Husk tallet ovenfor: Kun 10.5% af patchene er sikre, selvom 61% er korrekte. Det skal kontrolleres separat med værktøjer, der finder tokens, .env-filer og standardadgangskoder.
• At gå ud over opgaven er en typisk AI-fejl. Du beder den rette en autorisationsfunktion, og får en patch, der også omskrev det interne lag og logningen. Det er en af FrontierCodes 6 akser.

Hvilke 6 kategorier af fejl laver AI på svære opgaver?#

Lad os gennemgå hver akse i almindeligt sprog:

1. Adfærdsmæssig korrekthed — løser patchen opgaven?

Den mest grundlæggende akse. AI skriver ofte kode, der ligner en løsning, men løser det forkerte problem. Jeg beder den “tilføje en læsekvittering til beskeden” og får en markAsRead-funktion, men den er ikke koblet til selve chatkomponenten. Funktionstesten består. Forretningsopgaven er ikke løst.

2. Regressionssikkerhed — undgår den at ødelægge kode i nærheden?

AI ændrer et modul, og nu virker et andet ikke. Det mest almindelige tilfælde: En AI-agent ændrer en funktions signatur og glemmer, at den kaldes fra 17 andre steder. Det kan man ikke se på SWE-bench — dér køres der kun tests for én fil. På FrontierCode køres hele repositoryets testpakke.

3. Mekanisk renhed — består den build-, lint- og stilkontrollerne?

AI kan producere kode, der kompilerer lokalt, men fejler i CI: et manglende import, tabulatorer i stedet for mellemrum, to efterfølgende mellemrum eller en fejl i eslint.config.js. I et aktivt projekt er stil ikke et indfald; det er en teamregel.

4. Testenes korrekthed — er de tests, AI har skrevet, gyldige?

Den vanskeligste akse. AI skriver en test, der består. Men den består med hvilken som helst kode, også ødelagt kode. Jeg har set det mange gange: Testen kontrollerer “crashede scriptet?” i stedet for “returnerede det det rigtige resultat?” FrontierCodes Reverse-Classical fanger præcis dette tilfælde.

5. Omfang — undgår patchen at ændre uvedkommende filer?

Jeg beder den rette én funktion og får en patch til 12 filer, inklusive filer, der ikke har noget med opgaven at gøre. Det er netop den “initiativrigdom” fra AI, der ødelægger et produktionsprojekt ved at ændre ting, jeg ikke bad den om at ændre. Denne akse er en hård stopklods i FrontierCode.

6. Kodekvalitet — følger koden repositoryets konventioner?

AI skriver sin egen funktion “fra bunden” i stedet for at bruge eksisterende hjælpefunktioner i lib/. Eller den navngiver variabler på en måde, der ikke passer til projektets stil. Eller den placerer logikken i det forkerte arkitekturlag. Set fra testens perspektiv fungerer alt. Set fra den tekniske leders perspektiv bliver det ikke flettet ind.

Sådan kontrollerer du AI-kode før push: 5 trin#

1. Kør hele testpakken, ikke kun tests relateret til ændringen

   AI ændrer ofte kode uden for opgaven. Problemet vil vise sig i nærliggende tests. Jeg kører hele testpakken (med den ene kommando npm test, uden en sti), ikke kun tests for en bestemt fil. I store projekter er det praktisk at gøre dette parallelt med en git worktree (se Git worktree i Claude Code).

2. Kør lint-, stil- og typekontroller

   Tre kommandoer i rækkefølge: eslint ., prettier --check ., tsc --noEmit. En AI-agent kan overse både tabulatorer og et ekstra efterfølgende mellemrum. Hvis projektet har strenge kontroller, så kør dem lokalt før release.

3. Test selve testen

   Den vigtigste af de 5 kontroller. Jeg laver et lille “brud” i koden (ændrer return true til return false). Testen skal fejle. Hvis testen ikke fejler, skrev AI den kun for syns skyld, og den er ubrugelig. Jeg sletter testen og beder AI skrive den om med et obligatorisk krav: Testen skal fejle på den ødelagte version.

4. Kontrollér, hvilke filer AI har ændret

   Kommandoen git diff --stat viser, hvilke filer der er ændret, og hvor mange linjer. Hvis AI ændrede 12 filer som svar på “ret kontaktformularen”, gik den ud over opgavens omfang. Jeg ruller de ekstra ændringer tilbage med én kommando for filen.

5. Kør et sikkerhedstjek med en færdig skill

   Tests fanger ikke SQL-injektioner eller hardkodede adgangskoder. Jeg bruger en færdig sikkerheds-skill til Claude Code (se 754 færdige sikkerheds-skills). Som minimum søger jeg manuelt i projektets kode efter ordene “password”, “secret” og “key” og kontrollerer, at .env.example er komplet.

Alle 5 trin dækker 5 af FrontierCodes 6 akser (1–5). Den sjette akse — kodekvalitet — kontrolleres automatisk gennem linting plus en menneskelig gennemgang.

Hvad forbedrer faktisk chancerne for kode, der kan flettes ind?#

En AI-agent i et uforberedt projekt ser kun den fil, du har åbnet for den. Den har ingen historik over dine beslutninger, ingen af dine konventioner og intet kort over dine moduler. Det er ikke noget stort problem ved enkle ændringer. Ved svære ændringer er manglende projektkontekst en risiko, der er værd at håndtere. Benchmarkens tal på 13.4% isolerer ikke kontekstkvalitet som årsagen.

Det skal du gøre for at forvandle de 13% til noget, du faktisk kan sende i produktion:

1. Projektregler — så AI gengiver din tankegang i stedet for internettets gennemsnit.

Det er et sæt af dine færdige løsninger, vaner og indlærte regler i et format, som AI-agenten læser ved hver forespørgsel. Når der er 30+ regler, holder AI op med at opfinde “branchens gennemsnit” og begynder at komme med forslag i din stil. At gå ud over opgavens omfang kan håndteres med én linje i reglerne: “rør ikke filer uden for dem, der udtrykkeligt er nævnt i forespørgslen.”

2. Et projektkort — en mappe, der beskriver projektet.

Her lægger du produkter, målgruppe, økonomi, målinger og opsætninger. Før hver forespørgsel læser AI-agenten indholdsfortegnelsen og forstår hvilken del af virksomheden den arbejder med. Det håndterer automatisk to af de afvisningsårsager, der er nævnt ovenfor: stil og ødelæggelse af anden kode.

3. Context Engineering — styring af, hvad AI ser før forespørgslen.

Det handler ikke om “hvordan man formulerer en prompt”, men om “hvad man lægger i kontekstvinduet FØR prompten”. CLAUDE.md, forudsætninger og målrettede links til filer. Det adresserer fejl i adfærdsmæssig korrekthed og kodekvalitet.

Brug kombinationen som forberedelse til kontrollerne, ikke som bevis for, at fem akser allerede består. Verificér adfærd, regressioner, tests, omfang og kodekvalitet på den faktiske patch, før du accepterer den.

Et ekstra lag er review-agenter:

• Cursor Bugbot — gennemgår hver PR. Ifølge Cursor behandler værktøjet omkring 2 millioner PR'er om måneden.
• Indlejrede underagenter i Claude Code v2.1.172 — én agent skriver koden, en anden gennemgår den, og en tredje kører tests. Det er samme idé som FrontierCode: at adskille rollerne “skribent” og “teknisk leder”.

Se også: Vibe Coding Security, Sådan konfigurerer du Claude Code, så det ikke ødelægger dit projekt om natten og Context Engineering som begreb.

Se Ailoot-dokumentationen for yderligere materiale om arbejde med værktøjer.