Vibe coding testen begint niet bij de vraag of de app start. Dat is de ondergrens. De betere vraag is: kan iemand deze AI-code reviewen, aanpassen en veilig mergen zonder de hele boel opnieuw te moeten bouwen?
Cognition raakt met FrontierCode precies dit punt. De benchmark meet volgens Cognition niet alleen of code werkt, maar of een maintainer de pull request zou accepteren. Voor iedereen die met Cursor, Codex, Claude Code, Lovable of Bolt bouwt, is dat een nuttiger criterium dan “de demo doet het”.
Bronnen en leeswijzer
- Cognition: Introducing FrontierCode
- Cognition FrontierCode result data JSON
- SWE-bench official leaderboards
- METR: Many SWE-bench-passing PRs would not be merged
- Terminal-Bench
De aanleiding
Cognition introduceerde FrontierCode als nieuwe coding eval voor moeilijkheid en kwaliteit. De taken zijn volgens Cognition gebouwd met open-source maintainers en kostten meer dan 40 uur werk per taak. De benchmark vraagt niet alleen of een oplossing de tests haalt. Hij vraagt of de code mergewaardig is.
Dat woord is belangrijk voor vibe coding. Veel beginners gebruiken AI alsof de eerste werkende output het eindpunt is. Ze beschrijven een app, de tool bouwt iets, de preview opent en de conclusie is: het werkt. Maar “werkt in preview” betekent weinig. De echte problemen komen later: state die niet klopt, auth die lekt, routes die niet indexeerbaar zijn, componenten die niet te onderhouden zijn, tests die ontbreken, of code die een volgende prompt niet meer stabiel kan aanpassen.
Promptcoaching.nl is gebouwd rond prompting, vibe coding en de Prompt Coach. De keyword-map zet `vibe coding` als centrale hub neer, met tools, leren, voorbeelden en promptkwaliteit als subclusters. Dit artikel hoort daarom niet als algemeen AI-nieuws, maar als praktische beoordelingsgids: hoe test je AI-code voordat je ermee verder bouwt?
Waarom “maak dit werkend” een matige prompt is
Een AI-tool optimaliseert vaak op het criterium dat jij zichtbaar maakt. Vraag je om een werkende knop, dan krijg je een werkende knop. Vraag je om een route die getest, toegankelijk, onderhoudbaar en rollbackbaar is, dan krijgt het model een andere opdracht.
De meeste vibe coding fouten beginnen niet bij het model. Ze beginnen bij een te vage succesdefinitie. “Maak een dashboard” is geen reviewbare opdracht. “Maak een dashboard met drie states, expliciete loading/error states, geen mockdata in productie, herbruikbare componenten en tests voor filters” is een betere opdracht. Nog beter: “wijzig alleen deze componenten, leg aannames vast, voeg testcases toe en geef een diff-samenvatting.”
FrontierCode maakt die tweede manier van denken zichtbaar. Cognition zegt dat de benchmark criteria gebruikt voor correctness, test quality, scope discipline, style en adherence to codebase standards. Dat zijn precies de criteria die je in een goede prompt moet zetten als je met AI code laat schrijven.
Wat de FrontierCode scores zeggen over vibe coding
De hardste FrontierCode-subset heet Diamond. Daar scoort Claude Opus 4.8 via Claude Code volgens de Cognition-data 13,4%. GPT-5.5 via Codex haalt 6,3%. Claude Opus 4.7 via Claude Code haalt 5,2%. Zelfs de beste systemen zitten dus laag wanneer de vraag verschuift van “maak iets werkends” naar “maak iets dat een maintainer zou mergen”.
Je moet die cijfers niet lezen als reden om AI-code te negeren. Lees ze als reden om je proces serieuzer te maken. AI kan enorm versnellen. Maar de versnelling heeft alleen waarde als je reviewlaag meegroeiet. Anders ruil je bouwtijd in voor onderhoudsschuld.
OpenAI liet bij SWE-bench Verified al zien hoe lastig benchmarkkwaliteit is. Bij het maken van SWE-bench Verified werd 68,3% van de beoordeelde samples weggefilterd omdat issuebeschrijvingen, tests of andere criteria problematisch waren. METR liet later zien dat test-passing SWE-bench PR’s door maintainers veel minder vaak mergewaardig werden gevonden dan de automatische scores suggereren. FrontierCode is Cognition’s poging om die reviewrealiteit directer te meten.
Een betere prompt voor AI-code
Als je met vibe coding werkt, moet je prompt niet alleen de feature beschrijven. Je prompt moet de reviewcriteria beschrijven. Gebruik bijvoorbeeld dit patroon:
Doel:
Bouw [feature] voor [gebruikerstaak].
Scope:
Wijzig alleen [bestanden/componenten].
Maak geen brede refactor.
Kwaliteit:
- Voeg loading, empty en error states toe.
- Houd bestaande stijlen en componentpatronen aan.
- Voeg tests toe voor [cases].
- Leg aan het einde uit welke aannames je maakte.
Acceptatie:
De wijziging is pas klaar als de app buildt, tests slagen en de diff klein genoeg is om te reviewen.
Dit is geen magische prompt. Het is een manier om de agent niet alleen te laten produceren, maar ook te laten werken binnen een reviewbaar contract. De Prompt Coach kan hierbij helpen omdat je prompts kunt beoordelen op rol, taak, context, constraints en outputformat. Voor code moet je daar acceptatiecriteria en testgedrag aan toevoegen.
Maak je eigen mini-FrontierCode voor projecten
Je hebt geen groot benchmarkteam nodig om beter te testen. Maak per project een kleine evalset met taken die jij echt belangrijk vindt. Voor een Lovable-app kunnen dat SEO-rendering, formulierfouten, mobile layout en routing zijn. Voor een interne tool kunnen dat permissies, export, filters en auditlogs zijn. Voor een WordPress plugin kunnen dat hooks, backwards compatibility en settings validation zijn.
Laat de AI-tool dezelfde taak meerdere keren oplossen. Beoordeel niet alleen of de output werkt. Beoordeel:
- Was de diff klein genoeg?
- Bleef de agent binnen de afgesproken scope?
- Zijn er tests of controlecases toegevoegd?
- Is de code begrijpelijk voor iemand anders?
- Kan de wijziging later veilig worden aangepast?
Dit is precies waar veel vibe coding beginners te weinig aandacht aan geven. Ze vergelijken tools op snelheid en uiterlijk. De betere vergelijking gaat over herstelbaarheid. Welke tool maakt fouten die je kunt vinden? Welke tool houdt instructies vast? Welke tool raakt minder vaak bestanden aan die buiten scope liggen? Welke tool legt zijn aannames helder uit?
Wat we nog niet zeker weten
FrontierCode is niet volledig reproduceerbaar voor buitenstaanders, omdat Cognition de taken prive houdt om contaminatie te voorkomen. Dat is verdedigbaar, maar het betekent dat je de benchmark niet zelfstandig kunt narekenen. De ranking combineert ook model en agentharness. Claude Code, Codex en Gemini CLI zijn verschillende werkomgevingen. Een score zegt dus niet alleen iets over het model, maar ook over de tooling eromheen.
Voor jou als vibe coder maakt dat weinig uit als je de benchmark gebruikt als denkkader. Gebruik de ranking niet als simpele toolkeuze. Gebruik de benchmarkvraag: zou ik deze wijziging mergen?
Praktische implicaties voor PromptCoaching-lezers
Als je begint met vibe coding, test dan niet op gevoel. Maak per project een korte acceptatielijst. Werk je met Cursor, Lovable of Bolt, laat de tool die lijst zichtbaar volgen. Gebruik bij Codex-achtige workflows de voorbeelden uit OpenAI Codex use cases, maar voeg altijd je eigen projectregels toe.
Mijn oordeel: vibe coding wordt pas serieus wanneer je stopt met juichen bij de eerste preview. De eerste preview is een schets. De mergewaardige versie begint daarna. Wie dat verschil snapt, haalt veel meer uit AI-tools en bouwt minder wegwerpcode.
De beste prompt vraagt dus niet: “maak dit werkend.” De beste prompt vraagt: “maak dit reviewbaar.”