Ny benchmark viser hvor langt kodeagenter er fra produksjonskode

Kode som virker er ikke alltid kode som bør merges

Cognition har lagt frem FrontierCode, en ny benchmark for kodeagenter som flytter testen fra om koden passerer noen automatiske sjekker, til om en erfaren vedlikeholder faktisk ville akseptert endringen i et produksjonsrepo.

Det er en viktig dreining. De siste to årene har mange målt kodeagenter på oppgaveløsning, antall pull requests og testpassering. Det sier noe. Men det sier ikke nok om kvaliteten ledere faktisk må leve med etterpå: scope, lesbarhet, testkvalitet, stil, vedlikehold og om endringen passer inn i resten av kodebasen.

FrontierCode forsøker å måle nettopp det. Cognition beskriver testen som en vurdering av «mergeability». Spørsmålet er enkelt: Ville maintaineren tatt denne PR-en inn?

Svaret er foreløpig brutalt. På den hardeste delen av testen, FrontierCode Diamond, scorer den beste modellen, Claude Opus 4.8, bare 13,4 prosent. GPT-5.5 får 6,3 prosent. Gemini 3.1 Pro får 4,7 prosent. Kimi K2.6, den beste åpne modellen i testen, får 3,8 prosent på Diamond. På de bredere Main- og Extended-settene ligger Opus 4.8 høyere, med henholdsvis 34,3 og 51,8 prosent, men bildet er det samme: toppmodellene er nyttige, men langt fra autonome seniorutviklere.

For norske ledergrupper er dette mer nyttig enn enda en påstand om at utviklere snart er erstattet. FrontierCode peker på et mer praktisk problem: AI-kode kan se ferdig ut lenge før den er trygg å eie.

Testen treffer et hull i dagens AI-måling

Mange eksisterende kodebenchmarks måler funksjonell korrekthet. Det er naturlig. Koden skal gjøre det den blir bedt om. Problemet er at produksjonskode ikke bare handler om å få riktig output én gang. Den skal tåle neste endring, neste team, neste sikkerhetskrav og neste incident.

Cognition har derfor bygget testen rundt oppgaver laget av åpne kildekode-vedlikeholdere. Over 20 erfarne maintainere har bidratt med realistiske oppgaver fra repoer de faktisk kjenner. Ifølge Cognition er det brukt over 40 timer per oppgave. Hver oppgave vurderes ikke bare med tester, men også med rubrikker og manuell gjennomgang fra Cognition-forskere. Selskapet sier at prosessen gir 81 prosent lavere falsk positiv-rate enn SWE-Bench Pro.

Det er ikke et perfekt mål. Ingen benchmark er det. Men retningen er riktig. Den prøver å fange opp det mange utviklingsteam allerede ser i praksis: AI-verktøy kan produsere mye kode raskt, men kostnaden flyttes ofte til review, opprydding, arkitektur og regresjoner.

Dette er særlig viktig når kodeagenter kobles til større arbeidsflater. En agent som kan lese issues, endre filer, kjøre tester og åpne PR-er kan øke tempoet kraftig. Men hvis målingen stopper ved «testene passerte», kan organisasjonen bygge teknisk gjeld raskere enn før.

CIO og CTO må endre styringsspørsmålet

Den praktiske konsekvensen er at styring av kodeagenter ikke bør starte med spørsmålet «hvor mye raskere leverer vi?». Det bør starte med «hvilken kvalitet slipper vi gjennom?».

Det betyr at ledergruppen må se på kodeagentene som produksjonskapasitet, ikke bare som personlige assistenter. Når verktøyene brukes i kjerneprodukter, bør de inn i samme kontrollregime som annen utviklingskapasitet: kodeeierskap, reviewkrav, sikkerhetssjekker, testdekning, endringslogg, sporbarhet og måling av feil som oppstår etter merge.

Målt feil blir også annerledes. Det holder ikke å spørre hvor mange oppgaver agenten løste. Man må måle hvor mange av endringene som ble avvist i review, hvor ofte de måtte skrives om, hvor mye ekstra testarbeid de utløste, og om de økte feilraten i produksjon.

For virksomheter som allerede betaler for Cursor, Claude Code, Codex, GitHub Copilot eller interne agentløp, er dette et godt tidspunkt å stramme inn målemodellen. Produktivitetstall uten kvalitetsmål er farlige. De kan få AI-programmet til å se bedre ut akkurat når risikoen øker.

Kort vei til bedre praksis

FrontierCode gjør ikke kodeagenter mindre interessante. Tvert imot. Testen viser at de beste modellene allerede kan løse deler av reelle oppgaver, og at forskjellene mellom modellene er store. GPT-5.5 bruker ifølge Cognition opptil fire ganger færre tokens enn Opus 4.8 i noen sammenligninger, selv om Opus scorer høyere. Det peker mot et mer modent innkjøpsspørsmål: Ikke bare hvilken modell som er smartest, men hvilken kombinasjon av modell, kostnad, review og risikoprofil som gir best utviklingsøkonomi.

Den beste bruken nå er ikke å la agenten eie hele endringsløpet alene. Den beste bruken er å bruke agenten der den forkorter arbeid uten å fjerne menneskelig ansvar: forberedelse av PR-er, testforslag, refaktorering med tydelige rammer, dokumentasjon, migreringer og avgrensede feilrettinger.

For de fleste norske virksomheter bør konklusjonen være enkel: Kodeagenter skal rulles ut, men med kvalitetsmåling fra dag én. Ellers blir gevinsten et tall i en presentasjon, mens regningen havner hos utviklerne, sikkerhetsteamet og drift.

FrontierCode gir et bedre språk for den diskusjonen. Ikke «kan AI skrive kode?». Det kan den. Spørsmålet er om koden er god nok til å bli en del av systemene selskapet skal leve av. Foreløpig er svaret: noen ganger, men langt sjeldnere enn tempo-hypen tilsier.

Kilder og medier

Primærkilde: Cognition, «Introducing FrontierCode», publisert 08.06.2026. Source: https://cognition.ai/blog/frontier-code

Kildekreditering: Cognition.

Thumbnail: OpenAI Image 2 / hogby.ai