# FrontierCode Diamond: 13,4 % sammanslagningsbara patchar på 50 svåra uppgifter (juni 2026)
> FrontierCode-resultaten från juni 2026: 13,4 % på Diamonds 50 svåra uppgifter mot 51,8 % på Extended, och hur du granskar en AI-genererad patch.
Source: https://ailoot.ai/blog/sv/frontiercode-benchmark-mergeable-ai-code/
Canonical: https://ailoot.ai/blog/sv/frontiercode-benchmark-mergeable-ai-code/
Language: sv
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-173
Revision: sha256-08a9f120543f20f579c37e763da9aad98936196d5c1c647824ab1528edb80670
Det viktigaste
Den 8 juni 2026 lanserade Cognition FrontierCode, en benchmark som mäter om en verklig underhållare av ett open source-repo skulle gå med på att slå samman AI-genererad kod i sitt projekt. Huvudresultatet: även Claude Opus 4.8, branschens bästa modell, klarar bara 13,4 % av de 50 svåraste uppgifterna. Äldre benchmarker som HumanEval och SWE-bench mätte ”fungerar koden”; den nya mäter ”skulle underhållaren ta in den här PR:en?”. Det här förändrar perspektivet för alla som driver AI-genererad kod till produktion.
Mer material om hur verktyg konfigureras finns i [Ailoot-dokumentationen](https://ailoot.ai/docs/).
[Ailoot-guider](https://ailoot.ai/docs/)
## Vad är FrontierCode, och varför är det viktigt?
Det viktigaste
FrontierCode är en benchmark för AI-kodkvalitet från Cognition, publicerad den 8 juni 2026. Den utvärderar om en patch uppfyller benchmarkens kriterier för sammanslagning ur underhållarens perspektiv. Det är ett definierat benchmarkresultat, inte en allmän produktionsklarhetsgrad för all AI-kod. Fler än 20 underhållare av stora open source-projekt lade över 40 timmar på varje uppgift för att sätta samman scenarier som kräver inte bara korrekthet, utan också stil, säkerhet och tester.
Cognition är företaget bakom Devin (den första autonoma AI-ingenjören, mars 2024) och Windsurf (förvärvat i juli 2025). De utvecklar också sin egen modellserie SWE-1.x. Benchmarken publicerades på den offentliga bloggen på `cognition.com/blog/frontier-code`.
Den viktiga förändringen handlar inte om nya siffror. Den handlar om **skalan som används för att mäta saker nu**.
Benchmarken har tre svårighetsnivåer: **Extended** (150 uppgifter, hela uppsättningen), **Main** (de 100 svåraste, inklusive Diamond) och **Diamond** (50 riktigt svåra uppgifter). Cognition lämnade medvetet Diamond ”i stort sett omättad” – inte ens den bästa modellen löser färre än 15 %. Syftet är att ge benchmarken ett års marginal och hindra den från att mättas på en månad, som HumanEval gjorde.
## Vad mäter FrontierCode: ”Skulle underhållaren slå samman den här PR:en?”
Det viktigaste
FrontierCode bedömer varje lösning utifrån 6 axlar: om patchen löser uppgiften, undviker att förstöra annan kod, klarar bygg- och lintkontrollerna, har giltiga tester, håller sig inom omfattningen och har läsbar kod. För att en patch ska räknas som möjlig att slå samman måste den klara alla 6. Misslyckas den med bara en, slås PR:en inte samman. Det flyttar måttet från automatiserade tester till en verklig underhållares beslut.
De sex utvärderingsaxlarna (från Cognitions officiella blogg):
1. **Beteendemässig korrekthet** — löser patchen uppgiften?
2. **Regressionssäkerhet** — undviker den att förstöra befintlig kod?
3. **Mekanisk renhet** — klarar den bygg-, lint- och stilkontrollerna?
4. **Testernas korrekthet** — är testerna som agenten skrivit giltiga (tester som klarar sig med vilken kod som helst räknas inte)?
5. **Omfattning** — undviker patchen att ändra filer som inte efterfrågades?
6. **Kodkvalitet** — följer koden projektets konventioner, och är den läsbar?
För att en patch ska räknas som möjlig att slå samman måste den klara **alla sex axlar**. Misslyckas den med bara en, slås den inte samman.
Det är den huvudsakliga perspektivförändringen. ”Korrekthet är nu grundkravet”, som Cognition uttrycker det. Tidigare frågade benchmarker: ”Klarade koden testerna?” Nu frågar de: ”Skulle en verklig teknisk ledare ta in detta i projektet?”
Cognition introducerade tre nya bedömningstekniker:
- **Reverse-Classical**: ett test som skrivits av en agent måste fallera på en trasig version av koden. Annars är testet en bluff.
- **Code Scope**: en automatisk kontroll verifierar att en patch håller sig inom de filer och det radantal som avtalats för uppgiften.
- **Adaptive Classical Grading**: LLM-verktyget ”mutagent” anpassar strikta tester till giltiga lösningsvarianter.
## Varför fungerar de gamla benchmarkerna inte längre?
Det viktigaste
HumanEval (Codex, 2021) och SWE-bench kontrollerar om kod klarar automatiserade tester. De upptäcker inte fall där testet går igenom men ingen accepterar PR:en: koden är ful, förstör närliggande moduler eller går utanför uppgiftens omfattning. I mars 2026 utvärderade en oberoende studie 296 AI-genererade PR:er från SWE-bench Verified tillsammans med 4 verkliga underhållare: underhållarnas beslut låg i genomsnitt 24 procentenheter under den automatiska utvärderarens. Det betyder att ungefär hälften av de ”lyckade” PR:erna inte skulle slås samman i ett verkligt repo.
AI-agenter hade redan klarat HumanEval med bravur 2024. SWE-bench Verified är ungefär likadant: i augusti 2025 erkände OpenAI offentligt kontamineringsproblemet (modellerna hade ”sett” datasetet under träningen). Benchmarkerna förlorade sin förmåga att skilja de främsta modellerna åt.
Den viktiga studien som undergrävde det gamla måttet kom i mars 2026.
Så här gjorde de:
- Valde ut 4 aktiva underhållare från 3 kodförråd (scikit-learn, Sphinx, pytest).
- Lät dem utvärdera 296 AI-genererade PR:er från SWE-bench Verified – alla dessa PR:er klarade automatiserade tester.
- Jämförde underhållarnas beslut med den automatiska utvärderarens.
Med andra ord säger benchmarken ”godkänd”, medan underhållaren säger ”slås inte samman” – och det händer i genomsnitt i en fjärdedel av fallen. De tre främsta skälen till avslag, från minst till mest allvarliga:
1. **Kodkvalitet** — följer inte kodförrådets stil.
2. **Förstör annan kod** — bryter närliggande kod.
3. **Fel i kärnfunktionaliteten** — löser inte uppgiften helt, trots att testet är grönt.
FrontierCode formaliserar precis det här problemet. Cognition tog denna idé och utökade den till en fullständig benchmark med fler än 20 underhållare i stället för 4.
Ytterligare en spik i kistan är en studie från december 2025 om säkerheten i AI-genererade patchar.
I studien var 61 % av SWE-Agent-lösningarna med Claude 4 Sonnet funktionellt korrekta, men bara 10,5 % av dem var säkra.
Koden klarar testet, och ändå inför varannan patch ett säkerhetshål. Det går inte alls att se på SWE-bench-benchmarkerna – de mäter inte säkerhet. FrontierCode försöker åtminstone fånga det genom axlarna ”mekanisk renhet” och kodkvalitet.
## Så rankas modellerna: Opus 4.8 på 13,4 %, GPT-5.5 på 6,3 %
Det viktigaste
Cognition publicerade en resultatlista med 12 modeller över tre delmängder. Claude Opus 4.8 från Anthropic leder på Diamond med 13,4 %. Därefter kommer GPT-5.5 på 6,3 %, Claude Opus 4.7 på 5,2 % och Googles Gemini 3.1 Pro på 4,7 %. Den bästa modellen med öppen kod är Kimi K2.6 från Moonshot på 3,8 %. Cognitions egen modell SWE-1.6 ligger i den nedre delen av tabellen på 2,5 %. Detta är ett viktigt argument mot anklagelser om att de gör reklam för sig själva.
| Modell | Diamond (50) | Main (100) | Extended (150) |
|---------------------------------|--------------|------------|----------------|
| **Claude Opus 4.8** (Anthropic) | **13,4 %** | 34,3 % | 51,8 % |
| GPT-5.5 (OpenAI) | 6,3 % | \- | \- |
| Claude Opus 4.7 (Anthropic) | 5,2 % | \- | \- |
| Gemini 3.1 Pro (Google) | 4,7 % | \- | \- |
| GPT-5.4-mini (OpenAI) | 4,6 % | \- | \- |
| Kimi K2.6 (bästa modellen med öppen kod) | 3,8 % | \- | \- |
| Claude Sonnet 4.6 | 3,5 % | \- | \- |
| **SWE-1.6** (Cognition) | **2,5 %** | \- | \- |
| MiniMax M2.7 | 2,4 % | \- | \- |
| MiniMax M2.5 | 1,1 % | \- | \- |
| Kimi K2.5 | 1,0 % | \- | \- |
| Gemini 3.1 Flash Lite | 0,7 % | \- | \- |
Det här sticker ut i tabellen:
- **En tydlig ledare.** Anthropics Opus 4.8 ligger ungefär dubbelt så långt fram som närmaste konkurrent. Skillnaden som var svår att se på SWE-bench syns tydligt på FrontierCode.
- **Öppna modeller har inte kommit ikapp än.** Kimi K2.6 – den bästa modellen med öppen kod – får 3,8 % på Diamond. Det är 3–4 gånger lägre än Opus 4.8. Cognition publicerade inte en fullständig Kimi K2.6-tabell för Main och Extended, så det finns ännu ingen jämförelse för hela uppsättningen.
- **Cognition placerade ärligt sin egen modell** i den nedre delen av tabellen.
Diamond-delmängden lämnades avsiktligt ”omättad”. Cognition byggde in en säkerhetsmarginal för flera år framåt. Om tidigare benchmarker mättades på 12–18 månader är FrontierCode utformad för att ha högre tak.
## Vad betyder ”13 % går att slå samman” för en vibe-kodare som använder Claude Code?
Det viktigaste
För den rapporterade Opus 4.8-körningen på Diamonds 50 utvalda svåra uppgifter uppfyllde 13,4 % av patcharna benchmarkens sammanslagningskriterier och 86,6 % gjorde det inte. Det fastställer inte att alla avvisade patchar såg korrekta ut eller att samma andel gäller vanligt projektarbete. I praktiken med vibe-kodning betyder det att du inte kan nöja dig med att se ett grönt test och sedan skicka iväg ändringen när du gör svåra ändringar. Enkla ändringar i ett nytt projekt är en annan sak; AI klarar dem bra. Gränsen för ”när man ska skicka och när man ska finslipa för hand” har flyttats.
Först en viktig omformulering: FrontierCodes **Diamond**-uppsättning är avsiktligt extremt svår. På vanliga uppgifter i ett nystartat projekt utan fyrtio beroende moduler presterar en AI-agent märkbart bättre. Samma Opus 4.8 får 51,8 % patchar som går att slå samman på Extended (150 uppgifter, hela uppsättningen). Det är en helt annan bild.
Resultatet på 51,8 % gäller benchmarkens Extended-uppsättning med 150 uppgifter. Det är högre än Diamond-resultatet, men inget av talen uppskattar sammanslagningsbarheten för varje modells patchar på dina egna uppgifter. Saknade Main- eller Extended-poäng för andra modeller motiverar inte att fylla i deras prestanda.
Det här betyder det för en vibe-kodare som skickar kod till produktion:
- **Ett grönt test betyder inte längre ”redo att slås samman”.** Tester som AI själv har skrivit kan vara värdelösa – de klarar sig med vilken kod som helst. FrontierCode mäter detta direkt genom Reverse-Classical: om ett test inte fallerar på en trasig version räknas det inte.
- **Kodförrådets stil och konventioner spelar roll.** Om ett projekt har ett etablerat mönster och AI inte följer det accepterar en verklig samarbetspartner inte ändringen. I soloprojekt utan regler spelar det ingen större roll. I ett team är det problem nummer ett.
- **Tester löser inte säkerheten.** Kom ihåg siffran ovan: bara 10,5 % av patcharna är säkra trots att 61 % är korrekta. Detta måste kontrolleras separat, med verktyg som hittar token, `.env`-filer och standardlösenord.
- **Att gå utanför uppgiften är ett typiskt AI-misstag.** Du ber den fixa en behörighetsfunktion och får en patch som också skrev om det interna lagret och loggningen. Detta är en av FrontierCodes 6 axlar.
[Ailoot-guider](https://ailoot.ai/docs/)
## Vilka 6 kategorier av fel gör AI på svåra uppgifter?
Det viktigaste
De 6 FrontierCode-axlarna motsvarar 6 typer av fel som AI-agenter regelbundet gör. Det här är förutsägbara mönster av svaga resultat. Om du tar en slumpmässig patch från Claude eller Codex och bedömer den utifrån dessa 6 axlar accepterar en verklig teknisk ledare den inte om ens en enda punkt fallerar. För att tryggt kunna skicka kod till produktion behöver du själv kontrollera dessa 6 axlar före sammanslagning.
Vi går igenom varje axel på vanlig svenska:
**1. Beteendemässig korrekthet — löser patchen uppgiften?**
Den mest grundläggande axeln. AI skriver ofta kod som **ser** ut som en lösning men löser fel problem. Jag ber den ”lägga till en läskvittofunktion i meddelandet” och får en `markAsRead`-funktion, men den har inte kopplats till själva chattkomponenten. Funktionstestet går igenom. Affärsuppgiften är inte löst.
**2. Regressionssäkerhet — undviker den att förstöra närliggande kod?**
AI ändrar en modul, och nu fungerar inte en annan. Det vanligaste fallet: en AI-agent ändrar en funktions signatur och glömmer att den anropas från 17 andra ställen. Det syns inte på SWE-bench – där körs tester bara för en fil. På FrontierCode kör de **hela kodförrådets testsvit**.
**3. Mekanisk renhet — klarar den bygg-, lint- och stilkontrollerna?**
AI kan ta fram kod som kompilerar lokalt men fallerar i CI: en import saknas, tabbar i stället för mellanslag, två avslutande mellanslag eller ett misstag i `eslint.config.js`. I ett aktivt projekt är stil ingen nyck; den är en teamregel.
**4. Testernas korrekthet — är testerna som AI skrivit giltiga?**
Den knepigaste axeln. AI skriver ett test som går igenom. Men det **går igenom med vilken kod som helst, även trasig kod**. Jag har sett det många gånger: testet kontrollerar ”kraschade skriptet?” i stället för ”returnerade det rätt resultat?”. FrontierCodes Reverse-Classical fångar precis det här fallet.
**5. Omfattning — undviker patchen att ändra orelaterade filer?**
Jag ber den fixa en funktion och får en patch för 12 filer, däribland filer som inte har med uppgiften att göra. Det är just den ”initiativförmåga” från AI som förstör ett produktionsprojekt genom att ändra saker som jag inte bad den ändra. Den här axeln är ett definitivt hinder i FrontierCode.
**6. Kodkvalitet — följer koden kodförrådets konventioner?**
AI skriver sin egen funktion ”från grunden” i stället för att använda befintliga hjälpfunktioner i `lib/`. Eller så namnger den variabler på ett sätt som inte följer projektets stil. Eller så placerar den logik i fel arkitekturlager. Ur testets perspektiv fungerar allt. Ur den tekniska ledarens perspektiv slås det inte samman.
## Så kontrollerar du AI-kod före push: 5 steg
Det viktigaste
En checklista i 5 steg som täcker de 6 FrontierCode-axlarna och en säkerhetskontroll. Gå igenom den för varje patch från Claude eller Codex före release. Det är få steg och varje steg tar några minuter. Det lönar sig: lägg 10 minuter på checklistan i stället för 4 timmar på att återställa ett produktionsprojekt med git rewind och återställa databasen från en säkerhetskopia.
1. ### Kör hela testsviten, inte bara tester som hör till ändringen
AI ändrar ofta kod utanför uppgiften. Problemet kommer att synas i närliggande tester. Jag kör hela testsviten (med det enda kommandot `npm test`, utan sökväg), inte bara tester för en viss fil. I stora projekt är det praktiskt att göra detta parallellt med en git worktree (se [Git worktree i Claude Code](https://ailoot.ai/blog/sv/claude-code-git-worktree/)).
2. ### Kör kontroller för lint, stil och typer
Tre kommandon i ordning: `eslint .`, `prettier --check .`, `tsc --noEmit`. En AI-agent kan missa både tabbar och ett extra avslutande mellanslag. Om projektet har strikta kontroller ska du köra dem lokalt före release.
3. ### Testa själva testet
Den viktigaste av de 5 kontrollerna. Jag gör en liten ”ändring” i koden (ändrar `return true` till `return false`). Testet ska fallera. Om testet **inte fallerar** skrev AI det bara för syns skull, och det är värdelöst. Jag tar bort testet och ber AI skriva om det med ett obligatoriskt villkor: testet måste fallera på den trasiga versionen.
4. ### Kontrollera vilka filer AI ändrade
Kommandot `git diff --stat` visar vilka filer som ändrats och hur många rader. Om AI ändrade 12 filer som svar på ”fixa kontaktformuläret” gick den utanför uppgiftens omfattning. Jag återställer extrafilerna med ett enda kommando för filen.
5. ### Kör en säkerhetskontroll med en färdig skill
Tester upptäcker inte SQL-injektioner eller hårdkodade lösenord. Jag använder en färdig säkerhets-skill för Claude Code (se 754 färdiga säkerhets-skills). Sök åtminstone manuellt i projektet efter orden ”password”, ”secret” och ”key” i koden, och kontrollera att `.env.example` är fullständig.
De 5 stegen förbereder kontroller av FrontierCodes axlar 1–5; de bevisar inte att axlarna godkänns. Kontrollera också den sjätte axeln, kodkvalitet, med lintning och mänsklig granskning av den faktiska patchen.
## Vad förbättrar faktiskt chanserna till kod som går att slå samman?
Det viktigaste
FrontierCode beskriver problemet. Lösningen ligger i metodiken för att arbeta med AI; att byta själva modellen gör praktiskt taget ingen skillnad här. Tre arbetssätt gör skillnaden: projektregler, en projektkarta och kontextteknik. Utan dem producerar även Opus 4.8 trovärdigt skräp. De ger agenten tydligare begränsningar, men svåra ändringar behöver fortfarande kodförrådets kontroller och granskning före sammanslagning.
En AI-agent i ett oförberett projekt ser **bara filen du har öppnat åt den**. Den har ingen historik över dina beslut, inga av dina konventioner och ingen karta över dina moduler. Det spelar ingen större roll för enkla ändringar. För svåra ändringar är saknad projektkontext en risk att hantera. Benchmarkens 13,4 % isolerar inte kontextkvalitet som orsak.
Förbered följande för att sedan kunna verifiera om din egen patch kan accepteras:
**1. Projektregler — så att AI återger ditt resonemang i stället för internets genomsnitt.**
Det här är en uppsättning färdiga lösningar, vanor och inlärda regler i ett format som AI-agenten läser vid varje förfrågan. När det finns 30+ regler slutar AI hitta på ”branschgenomsnittet” och börjar komma med förslag i din stil. Att gå utanför uppgiftens omfattning kan hanteras med en rad i reglerna: ”ändra inte filer utanför dem som uttryckligen nämns i förfrågan.”
**2. En projektkarta — en mapp som beskriver projektet.**
Här lägger du produkter, målgrupp, ekonomi, nyckeltal och konfigurationer. Före varje förfrågan läser AI-agenten innehållsförteckningen och förstår **vilken del av verksamheten den arbetar med**. Detta hanterar automatiskt två av avslagsorsakerna som nämns ovan: stil och att förstöra annan kod.
**3. Context Engineering — hantera vad AI ser innan förfrågan.**
Det handlar inte om ”hur man formulerar en prompt”, utan om ”vad man placerar i kontextfönstret FÖRE prompten”. CLAUDE.md, förutsättningar och riktade länkar till filer. Detta åtgärdar brister i beteendemässig korrekthet och kodkvalitet.
Använd kombinationen som förberedelse för kontrollerna, inte som bevis på att fem axlar redan är godkända. Verifiera beteende, regressioner, tester, omfattning och kodkvalitet på den faktiska patchen innan du accepterar den.
Ett ytterligare lager är granskningsagenter:
- **Cursor Bugbot** — granskar varje PR. Enligt Cursor hanterar verktyget omkring 2 miljoner PR:er i månaden.
- **Nästlade underagenter i Claude Code v2.1.172** — en agent skriver koden, en andra granskar den och en tredje kör tester. Det är samma idé som FrontierCode: att separera rollerna ”skribent” och ”teknisk ledare”.
Se även: [Vibe Coding Security](https://ailoot.ai/blog/sv/vibe-coding-security/), [Så konfigurerar du Claude Code så att det inte saboterar projektet på natten](https://ailoot.ai/blog/sv/claude-code-safe-overnight-setup/) och Context Engineering som begrepp.
### Källor
- [Cognition - Introduktion av FrontierCode (8 juni 2026)](https://cognition.com/blog/frontier-code)
- [Cursor Bugbot - kodgranskningsagent](https://cursor.com/bugbot)
För mer material om att arbeta med verktyg, se [Ailoot-dokumentationen](https://ailoot.ai/docs/).
[Ailoot-guider](https://ailoot.ai/docs/)
[Gå till Ailoot](https://ailoot.ai/)
## Frågor om FrontierCode Diamond och sammanslagningsbara AI-patchar
### Betyder 13,4 % att bara den andelen av all AI-kod är produktionsklar?
Nej. Det är det rapporterade resultatet för sammanslagningsbarhet för Opus 4.8 på FrontierCode Diamonds 50 utvalda svåra uppgifter. Samma tabell rapporterar 51,8 % på Extendeds 150 uppgifter; inget av talen mäter all AI-genererad kod.
### Varför räcker inte ett godkänt test för att slå samman en patch?
Benchmarken kontrollerar också regressioner, bygg och stil, om testerna upptäcker en trasig implementation, omfattning och kodkvalitet. Granska den faktiska diffen och kör kodförrådets acceptanskontroller; ett grönt test ensamt fastställer inte alla dessa villkor.
## Ailoot · Företaget och dess projektportfölj
Ailoot bygger på etablerad driftserfarenhet, en stor kundbas, stabil service och löpande KPI-kontroll.
Företaget och dess projektportfölj: miljontals kunder; månatlig försäljning för miljarder.
Ailoot använder denna driftserfarenhet för API-åtkomst till AI-funktioner i kundernas produkter, agenter, applikationer och automatiseringar.