FrontierCode Diamond: 13.4% samenvoegbare patches op 50 moeilijke taken (juni 2026)

Aanvullend materiaal over het configureren van tools staat in de Ailoot-documentatie.

Wat is FrontierCode en waarom is het belangrijk?#

Cognition is het bedrijf achter Devin (de eerste autonome AI-ingenieur, maart 2024) en Windsurf (overgenomen in juli 2025). Het ontwikkelt ook een eigen modellenreeks, SWE-1.x. De benchmark werd gepubliceerd op de openbare blog op cognition.com/blog/frontier-code.

De belangrijkste verschuiving zit niet in nieuwe cijfers. Het gaat om de maatstaf waarmee we dingen nu beoordelen.

De benchmark heeft drie moeilijkheidsniveaus: Extended (150 taken, de volledige set), Main (de 100 moeilijkste, inclusief Diamond) en Diamond (50 loodzware taken). Cognition liet Diamond bewust “grotendeels onverzadigd” — zelfs het beste model lost minder dan 15% op. Zo moet de benchmark nog een jaar vooruit kunnen en niet binnen een maand verzadigd raken, zoals HumanEval.

Wat meet FrontierCode: “Zou de maintainer deze PR samenvoegen?”#

De zes beoordelingsassen (volgens de officiële blog van Cognition):

1. Functionele correctheid — lost de patch de taak op?
2. Regressieveiligheid — voorkomt de patch dat bestaande code stukgaat?
3. Technische netheid — doorstaat de patch de build-, lint- en stijlcontroles?
4. Correctheid van tests — zijn de tests die de agent heeft geschreven geldig (tests die op elke code slagen, tellen niet mee)?
5. Scope — voorkomt de patch dat bestanden worden aangepast die niet zijn gevraagd?
6. Codekwaliteit — volgt de code de conventies van het project en is die leesbaar?

Om als samenvoegbaar te gelden, moet een patch alle zes assen doorstaan. Zakt hij er ook maar op één, dan wordt hij niet samengevoegd.

Dat is de belangrijkste verschuiving in perspectief. “Correctheid is nu een basisvereiste,” zoals Cognition het zegt. Vroeger vroegen benchmarks: “Is de code geslaagd voor de tests?” Nu vragen ze: “Zou een echte tech lead dit in het project opnemen?”

Cognition introduceerde drie nieuwe beoordelingstechnieken:

• Reverse-Classical: een test die door een agent is geschreven, moet falen op een defecte versie van de code. Anders is de test schijnvertoning.
• Code Scope: een automatische controleur verifieert of een patch binnen de voor de taak afgesproken bestanden en het afgesproken aantal regels blijft.
• Adaptive Classical Grading: de LLM-tool “mutagent” past strikte tests aan geldige oplossingsvarianten aan.

Waarom werken de oude benchmarks niet meer?#

AI-agenten hadden HumanEval in 2024 al met vlag en wimpel gehaald. SWE-bench Verified is grotendeels hetzelfde verhaal: in augustus 2025 erkende OpenAI publiekelijk het probleem van contaminatie (modellen hadden de dataset tijdens de training “gezien”). Benchmarks verloren hun vermogen om topmodellen van elkaar te onderscheiden.

Het onderzoek dat de oude maatstaf ondermijnde, verscheen in maart 2026.

Wat ze deden:

• Ze selecteerden 4 actieve maintainers uit 3 repositories (scikit-learn, Sphinx, pytest).
• Ze lieten hen 296 AI-gegenereerde PR’s uit SWE-bench Verified beoordelen — al deze PR’s waren geslaagd voor geautomatiseerde tests.
• Ze vergeleken de beslissingen van de maintainers met die van de geautomatiseerde evaluator.

Met andere woorden: de benchmark zegt “geslaagd”, terwijl de maintainer zegt “ik voeg dit niet samen” — en dat gebeurt gemiddeld in een kwart van de gevallen. De 3 belangrijkste redenen voor afwijzing, van minst tot meest ernstig:

1. Codekwaliteit — sluit niet aan bij de stijl van de repository.
2. Breekt andere code — maakt aangrenzende code kapot.
3. Kernfunctionaliteit werkt niet — lost de taak niet volledig op, hoewel de test groen is.

FrontierCode formaliseert precies dit probleem. Cognition nam dit idee over en breidde het uit tot een volledige benchmark met meer dan 20 maintainers in plaats van 4.

Een andere nagel aan de doodskist is een onderzoek uit december 2025 naar de veiligheid van door AI gegenereerde patches.

Daarin was 61% van de SWE-Agent-oplossingen met Claude 4 Sonnet functioneel correct, maar slechts 10.5% ervan was veilig.

De code slaagt voor de test, maar toch introduceert één op de twee patches een beveiligingslek. Dat kun je helemaal niet zien in SWE-bench-benchmarks — die meten de beveiliging niet. FrontierCode probeert dit tenminste te ondervangen met de assen “technische netheid” en codekwaliteit.

De modellen gerangschikt: Opus 4.8 op 13.4%, GPT-5.5 op 6.3%#

Wat opvalt in de tabel:

• Eén duidelijke leider. Opus 4.8 van Anthropic staat ongeveer twee keer zo ver voor als de naaste concurrent. De kloof die op SWE-bench moeilijk te zien was, is op FrontierCode duidelijk zichtbaar.
• Open modellen hebben de achterstand nog niet ingelopen. Kimi K2.6 — het beste open-code-model — scoort 3.8% op Diamond. Dat is 3–4 keer lager dan Opus 4.8. Cognition publiceerde geen volledige Kimi K2.6-tabel voor Main en Extended, dus een vergelijking over de volledige set is er nog niet.
• Cognition plaatste zijn eigen model eerlijk lager in de tabel.

De Diamond-subset werd bewust “onverzadigd” gehouden. Cognition bouwde een veiligheidsmarge voor de komende jaren in. Als eerdere benchmarks binnen 12–18 maanden verzadigd raakten, is FrontierCode ontworpen met een hogere bovengrens.

Wat betekent “13% samenvoegbaar” voor een vibe coder die Claude Code gebruikt?#

Eerst een belangrijke nuance: de Diamond-set van FrontierCode is bewust extreem moeilijk. Bij gewone taken in een nieuw startupproject zonder veertig afhankelijke modules presteert een AI-agent merkbaar beter. Dezelfde Opus 4.8 scoort 51.8% samenvoegbaar op Extended (150 taken, de volledige set). Dat geeft een heel ander beeld.

Het resultaat van 51.8% geldt voor de Extended-set van 150 taken. Het is hoger dan het Diamond-resultaat, maar geen van beide percentages schat hoe goed patches van elk model op je eigen taken kunnen worden samengevoegd. Ontbrekende Main- of Extended-scores van andere modellen rechtvaardigen niet dat je hun prestaties invult.

Wat dit betekent voor een vibe coder die code naar productie pusht:

• Een groene test betekent niet langer “klaar om samen te voegen”. Tests die de AI zelf heeft geschreven, kunnen ondeugdelijk zijn — ze slagen bij elke code. FrontierCode meet dit rechtstreeks met Reverse-Classical: als een test niet faalt op een defecte versie, telt hij niet mee.
• De stijl en conventies van de repository zijn belangrijk. Als een project een vaste aanpak heeft en de AI die niet volgt, accepteert een echte samenwerkingspartner de wijziging niet. In soloprojecten zonder regels is dit geen groot probleem. In een team is dit probleem nummer één.
• Tests lossen beveiligingsproblemen niet op. Denk aan het cijfer hierboven: slechts 10.5% van de patches is veilig, terwijl 61% correct is. Dit moet apart worden gecontroleerd, met tools die tokens, .env-bestanden en standaardwachtwoorden opsporen.
• Buiten de taak treden is een typische AI-fout. Je vraagt om een autorisatiefunctie te repareren en krijgt een patch die ook de interne laag en logging herschrijft. Dit is een van de 6 assen van FrontierCode.

Welke 6 soorten fouten maakt AI bij moeilijke taken?#

Laten we elke as in gewone taal doornemen:

1. Functionele correctheid — lost de patch de taak op?

De meest basale as. AI schrijft vaak code die op een oplossing lijkt, maar het verkeerde probleem oplost. Ik vraag om “een leesbevestiging aan het bericht toe te voegen” en krijg een functie markAsRead, maar die is niet gekoppeld aan de chatcomponent zelf. De functietest slaagt. De zakelijke taak is niet opgelost.

2. Regressieveiligheid — voorkomt de patch dat aangrenzende code stukgaat?

AI wijzigt één module en nu werkt een andere niet meer. Het vaakst verandert een AI-agent de handtekening van een functie en vergeet daarbij dat die op 17 andere plekken wordt aangeroepen. Op SWE-bench zie je dit niet — daar worden alleen tests voor één bestand uitgevoerd. Op FrontierCode draaien ze de volledige testsuite van de repository.

3. Technische netheid — doorstaat de patch de build-, lint- en stijlcontroles?

AI kan code opleveren die lokaal compileert maar faalt in CI: een ontbrekende import, tabs in plaats van spaties, twee afsluitende spaties of een foutje in eslint.config.js. In een liveproject is stijl geen gril; het is een teamregel.

4. Correctheid van tests — zijn tests die AI heeft geschreven geldig?

De lastigste as. AI schrijft een test die slaagt. Maar die slaagt op elke code, ook op defecte code. Ik heb dit vaak gezien: de test controleert “is het script gecrasht?” maar niet “heeft het het juiste resultaat teruggegeven?” Reverse-Classical van FrontierCode vangt precies dit geval op.

5. Scope — voorkomt de patch dat niet-gerelateerde bestanden worden aangepast?

Ik vraag om één functie te repareren en krijg een patch voor 12 bestanden, waaronder bestanden die niets met de taak te maken hebben. Dat is precies het soort “initiatief” van AI dat een productieproject kapotmaakt door dingen te wijzigen waar ik niet om heb gevraagd. Deze as is een absolute blokkade in FrontierCode.

6. Codekwaliteit — volgt de code de conventies van de repository?

AI schrijft zijn eigen functie “vanaf nul” in plaats van bestaande helpers in lib/ te gebruiken. Of het geeft variabelen namen die niet passen bij de stijl van het project. Of het plaatst logica in de verkeerde architectuurlaag. Vanuit het perspectief van de test werkt alles. Vanuit het perspectief van de tech lead wordt de code niet samengevoegd.

AI-code controleren voordat je pusht: 5 stappen#

1. Voer de volledige testsuite uit, niet alleen tests die bij de wijziging horen

   AI wijzigt vaak code buiten de taak. Het probleem komt dan naar voren in tests van aangrenzende onderdelen. Ik voer de volledige testsuite uit (met het ene commando npm test, zonder pad), niet alleen de tests voor een specifiek bestand. Bij grote projecten is het handig dit parallel te doen met een git worktree (zie Git worktree in Claude Code).

2. Voer lint-, stijl- en typecontroles uit

   Drie commando’s op volgorde: eslint ., prettier --check ., tsc --noEmit. Een AI-agent kan zowel tabs als een extra afsluitende spatie over het hoofd zien. Als het project strenge controles heeft, voer ze dan lokaal uit voordat je code uitbrengt.

3. Test de test zelf

   De belangrijkste van de 5 controles. Breng een kleine “breuk” aan in de code (verander return true in return false). De test moet falen. Als de test niet faalt, heeft AI hem alleen voor de vorm geschreven en is hij nutteloos. Ik verwijder de test en vraag AI hem opnieuw te schrijven met de verplichte voorwaarde dat de test moet falen op de defecte versie.

4. Controleer welke bestanden AI heeft aangepast

   Het commando git diff --stat toont welke bestanden zijn gewijzigd en hoeveel regels. Als AI 12 bestanden heeft aangepast nadat je om “het contactformulier te repareren” vroeg, is het buiten de scope van de taak gegaan. Ik draai de extra wijzigingen met één commando per bestand terug.

5. Voer een beveiligingscontrole uit met een kant-en-klare skill

   Tests sporen geen SQL-injecties of hardgecodeerde wachtwoorden op. Ik gebruik een kant-en-klare beveiligingsskill voor Claude Code (zie 754 kant-en-klare beveiligingsskills). Zoek op zijn minst handmatig in het project naar de woorden “password”, “secret” en “key” en controleer of .env.example volledig is.

Alle 5 stappen dekken 5 van de 6 assen van FrontierCode (1–5). De zesde as — codekwaliteit — wordt automatisch gecontroleerd met linting plus een menselijke beoordeling.

Wat vergroot de kans op code die kan worden samengevoegd echt?#

Een AI-agent in een onvoorbereid project ziet alleen het bestand dat je voor hem hebt geopend. Hij kent je beslissingsgeschiedenis niet, kent je conventies niet en heeft geen kaart van je modules. Bij eenvoudige wijzigingen is dat geen groot probleem. Bij moeilijke wijzigingen is ontbrekende projectcontext een risico dat aandacht verdient. Het benchmarkcijfer van 13.4% isoleert contextkwaliteit niet als oorzaak.

Wat je moet doen om die 13% om te zetten in iets wat je daadwerkelijk naar productie kunt pushen:

1. Projectregels — zodat AI jouw redenering nabootst in plaats van het gemiddelde van het internet.

Dit is een verzameling kant-en-klare oplossingen, gewoonten en geleerde regels van jou, in een formaat dat de AI-agent bij elk verzoek leest. Zodra er meer dan 30 regels zijn, stopt AI met het verzinnen van het “gemiddelde in de sector” en begint het suggesties in jouw stijl te doen. Buiten de scope van de taak gaan kun je aanpakken met één regel: “raak geen bestanden aan buiten de bestanden die uitdrukkelijk in het verzoek worden genoemd.”

2. Een projectkaart — een map die het project beschrijft.

Hierin zet je producten, doelgroep, economie, statistieken en configuraties. Vóór elk verzoek leest de AI-agent de inhoudsopgave en begrijpt hij aan welk deel van het bedrijf hij werkt. Dit pakt automatisch twee van de hierboven genoemde redenen voor afwijzing aan: stijl en het breken van andere code.

3. Context Engineering — beheren wat AI vóór het verzoek te zien krijgt.

Het gaat niet om “hoe formuleer je een prompt?”, maar om “wat zet je vóór de prompt in het contextvenster?” CLAUDE.md, vereisten en gerichte links naar bestanden. Dit pakt fouten in functionele correctheid en codekwaliteit aan.

Gebruik de combinatie als voorbereiding op controles, niet als bewijs dat vijf assen al slagen. Controleer gedrag, regressies, tests, scope en codekwaliteit op de echte patch voordat je die accepteert.

Een extra laag bestaat uit reviewagenten:

• Cursor Bugbot — voert bij elke PR een review uit. Volgens Cursor verwerkt de tool ongeveer 2 miljoen PR’s per maand.
• Geneste subagenten in Claude Code v2.1.172 — de ene agent schrijft de code, de tweede beoordeelt die en de derde voert tests uit. Dat is hetzelfde idee als bij FrontierCode: de rollen van “schrijver” en “tech lead” scheiden.

Zie ook: Vibe Coding-beveiliging, Claude Code zo instellen dat het je project ’s nachts niet kapotmaakt en Context Engineering als concept.

Voor aanvullend materiaal over het werken met tools, zie de Ailoot-documentatie.