💻 computer science

VIBEPASS: Can Vibe Coders Really Pass the Vibe Check?

Het onderzoek VIBEPASS onthult dat hoewel grote taalmodellen syntactisch correcte tests kunnen genereren, hun vermogen om subtiele bugs te diagnosticeren en te repareren beperkt blijft door een tekort aan fault-target redenering, wat een kritieke bottleneck vormt voor autonoom software-engineering.

Oorspronkelijke auteurs: Srijan Bansal, Jiao Fangkai, Yilun Zhou, Austin Xu, Shafiq Joty, Semih Yavuz

Gepubliceerd 2026-03-18

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Srijan Bansal, Jiao Fangkai, Yilun Zhou, Austin Xu, Shafiq Joty, Semih Yavuz

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer slimme, maar soms wat overmoedige assistent hebt die code schrijft (computerprogramma's). Deze assistent, een "AI", is zo goed dat hij vaak 90% van de taken perfect doet. Maar er is een groot probleem: als de assistent een klein, sluipend foutje maakt dat niet direct zichtbaar is, denkt hij vaak dat alles perfect is.

Dit artikel introduceert VIBEPASS, een nieuwe manier om te testen of deze slimme assistenten echt kunnen "nadenken" over fouten, in plaats van alleen maar code te kopiëren.

Hier is de uitleg in simpele taal, met een paar creatieve vergelijkingen:

1. Het Probleem: De "Vibe Check"

Vandaag de dag schrijven AI's steeds meer software met weinig menselijk toezicht. Dit noemen ze "vibe coding". Het werkt goed zolang de instructies duidelijk zijn. Maar in de echte wereld moet een AI ook zelf kunnen zeggen: "Hé, hier zit een fout in, en ik weet precies waar en waarom."

Tot nu toe hebben we geen goede manier om dit te testen. De meeste tests kijken alleen of de code werkt op de standaard voorbeelden. Maar wat als de code faalt op een heel rare, specifieke situatie die niemand had bedacht?

2. De Oplossing: VIBEPASS (De "Fout-Detectie Test")

De onderzoekers hebben VIBEPASS bedacht. Dit is geen gewone test, maar een drie-delige uitdaging voor de AI, alsof je een detectiveopleiding geeft:

Stap 1: De "Vind de Fout" Test (Het Foutje Zoeken)
De AI krijgt een stuk code dat bijna perfect is, maar een verborgen fout heeft. De AI moet een specifiek voorbeeld bedenken (een "test") dat laat zien waar de fout zit.
- Vergelijking: Stel je voor dat je een auto hebt die normaal rijdt, maar op een heel specifieke helling met een bepaalde snelheid uitvalt. De AI moet precies die helling en snelheid kunnen bedenken om de motor te laten staken. Als de AI alleen maar zegt "rijden" (standaard test), ziet hij de fout niet. Hij moet de "zwakke plek" vinden.
Stap 2: De "Reparatie" Test (Het Oplossen)
Als de AI de fout heeft gevonden, moet hij de code repareren.
- Vergelijking: De AI moet niet alleen zeggen "de motor stopt op deze helling", hij moet ook de sleutel vinden om de motor zo te repareren dat hij ook op die helling blijft rijden.

3. Wat Vond de Studie? (De Verassende Resultaten)

De onderzoekers keken naar 12 van de slimste AI's ter wereld (zoals GPT-5, Gemini, Claude). Wat bleek?

Slim zijn in coderen ≠ Slim zijn in fouten vinden.
De AI's zijn fantastisch in het schrijven van code die er goed uitziet (90% slaagt). Maar zodra ze zelf een fout moeten ontdekken, zakken ze dramatisch.
- Vergelijking: Het is alsof een chef-kok perfect een taart kan bakken die er prachtig uitziet. Maar als je hem vraagt: "Probeer eens een taart te bakken die niet lukt, zodat we de fout kunnen zien", dan faalt hij. Hij kan de taart maken, maar hij begrijpt niet waarom hij zou mislukken.
Het echte probleem is het "Gissen" naar de fout.
De grootste drempel was niet het schrijven van de test, maar het bedenken van het idee voor de test.
- Vergelijking: De AI kan perfect een sleutel maken (de test), maar hij weet niet welke sleutel in welk slot past. Hij moet eerst raden welk slot kapot is. Dat "raden" (de hypothese) is waar de meeste AI's vastlopen.
Eigen tests werken beter dan externe tests.
Als de AI zelf een fout heeft gevonden en die test gebruikt om te repareren, gaat het vaak beter dan als iemand anders de test aanlevert.
- Vergelijking: Als jij zelf merkt dat je fiets een lekke band heeft, weet jij precies waar je moet kijken om het te plakken. Als iemand anders zegt "kijk hier", kijk je misschien op de verkeerde plek. De AI werkt het beste als hij zijn eigen diagnose stelt.

4. De Conclusie: Waarom is dit belangrijk?

De studie laat zien dat we nog niet klaar zijn voor volledig autonome software-engineering. De AI's zijn geweldige "schrijvers", maar nog geen goede "detectives".

Ze kunnen de code schrijven, maar ze kunnen de oorzaak van een probleem nog niet goed doorgronden. Zolang ze niet kunnen "nadenken" over waarom iets fout gaat (in plaats van alleen maar te proberen het te fixen), zullen we mensen nodig blijven om de "vibe check" te doen.

Kortom: VIBEPASS is de eerste echte "vrijheidsproef" voor AI's om te zien of ze echt begrijpen wat ze schrijven, of dat ze alleen maar slim lijken. En tot nu toe: ze lijken slim, maar ze zijn nog geen echte detectives.

Probleemstelling

De opkomst van Large Language Models (LLMs) heeft geleid tot "vibe coding": agente workflows die software genereren met minimale menselijke supervisie. Hoewel deze modellen hoge scores behalen op bestaande benchmarks (vaak >90%), evalueren deze benchmarks voornamelijk het genereren van correcte code vanuit duidelijke specificaties onder ideale omstandigheden.

In de praktijk moeten modellen echter:

Code verifiëren.
Latente fouten diagnosticeren die niet worden opgepikt door bestaande tests.
Gerichte reparaties uitvoeren.

Een fundamenteel probleem is dat LLM-generaties vaak alle zichtbare tests halen, maar stilzwijgend falen op randvoorwaarden (edge cases). De kernvraag is: Kan een LLM, gegeven een bijna-correct programma zonder zichtbare fouten, een concrete input genereren die de latente fout blootlegt, en deze diagnose gebruiken om de code te repareren? Dit wordt in het paper fault-targeted reasoning (redenering gericht op het vinden van fouten) genoemd. Bestaande benchmarks evalueren testgeneratie en reparatie vaak geïsoleerd, waardoor de cruciale schakel van diagnose ontbreekt.

Methodologie: VIBEPASS Benchmark

Het paper introduceert VIBEPASS, het eerste empirische raamwerk dat twee gekoppelde taken gezamenlijk evalueert om fault-targeted reasoning te meten. De dataset bestaat uit 173 instanties gebaseerd op 76 uitdagende algoritmische problemen uit LiveCodeBench.

Opbouw van de dataset:

Elk voorbeeld bevat een probleem, officiële tests, een menselijke "silver" oplossing (correct), en een door een LLM gegenereerde "buggy" oplossing.
De buggy oplossingen halen 10–90% van de officiële tests, wat betekent dat ze subtiele semantische fouten bevatten die niet triviaal te detecteren zijn.

De twee kern-taken:

Fault-Triggering Test Generation (FT-Test):
- Het doel is het genereren van een test (input + verwachte output) die de buggy oplossing faalt laat zien, terwijl de correcte oplossing slaagt.
- De test moet discriminerend zijn (niet alleen syntactisch geldig, maar specifiek de fout blootleggen).
- Twee settings: Bug-Aware (het model weet dat er een fout is) en Bug-Discovery (het model moet eerst bepalen of er een fout is).
Fault-Targeted Program Repair (FPR):
- Het doel is het repareren van de fout onder drie verschillende richtlijnen:
  - NoTest: Geen extra context, alleen weten dat er een fout is.
  - ExtTest: Het model krijgt een extern gegenereerde test (van Task 1) als diagnose.
  - IntTest: Het model genereert eerst zijn eigen test en gebruikt deze vervolgens voor reparatie.

Evaluatie:
Er zijn 12 frontier-modellen getest, waaronder GPT-5-varianten, Gemini-3, Claude Opus/Sonnet, en open-source systemen. De evaluatie gebruikt strikte criteria: geldigheid van input, uitvoerbaarheid, en discriminatiekracht (het vermogen om de buggy vs. correcte code te onderscheiden).

Kernresultaten

1. Fault-targeted reasoning schaalt niet mee met algemene programmeervaardigheid

Modellen genereren bijna perfect syntactisch geldige inputs (gemiddeld 86,4% validiteit).
Echter, slechts 61,3% van de gegenereerde tests is daadwerkelijk discriminerend (blootlegt de fout).
De grootste bottleneck is het genereren van de fouthypothese (het vinden van de juiste input), niet het valideren van de output. Het gat tussen validiteit en discriminatie is 2,7 keer groter dan het gat in outputvalidatie.
Er is een enorme spreiding in prestaties tussen modellen, wat aangeeft dat dit een specifieke vaardigheid is die niet lineair meegroeit met algemene coderingscapaciteit.

2. Zelfgegenereerde tests presteren vaak beter dan externe tests

In de IntTest setting (zelf gegenereerde test) presteren sterke redeneermodellen gelijk aan of beter dan bij gebruik van externe tests.
Wanneer een model een geldige "corner case" zelf genereert, verbetert dit de reparatiesucces met 6,4 punten vergeleken met externe tests.
Dit suggereert dat contextuele uitlijning (dat het model de test zelf heeft bedacht in de context van de fout) belangrijker is dan de pure kwaliteit van de test alleen.
Opmerking: Gemiddeld dalen de prestaties bij gebruik van gegenereerde tests ten opzichte van "NoTest" omdat veel gegenereerde tests misleidend zijn of de fout niet correct diagnosticeren.

3. De "Performance Cliffs" en Bottlenecks

Er zijn duidelijke afbrokkelingspunten in de pijplijn:
- Van Valid IO naar Fault-Triggering Input: -14,7% succespuntverlies.
- Van Fault-Triggering IO naar Repair: -21,2% succespuntverlies.
Dit bevestigt dat het probleem niet ligt bij het synthetiseren van code of het maken van tests, maar bij causale redenering over het programma om de specifieke oorzaak van de fout te lokaliseren.
De correlatie tussen het vinden van een discriminerende input en het succesvol repareren van de code is zeer sterk ( $r = 0,79$ ).

Bijdragen

VIBEPASS Benchmark: Een hoogwaardige dataset met 173 verifieerbare instanties die fault-targeted reasoning systematisch evalueert via een multi-stage framework (testgeneratie + reparatie).
Decoupling Framework: Een methode om testgeneratie en reparatie te ontkoppelen om te analyseren waar de keten breekt.
Systematische Analyse: De eerste uitgebreide evaluatie van 12 frontier-modellen, die aantoont dat ondanks sterke generatieprestaties, de capaciteit voor causale programmareasoning (diagnose) aanzienlijk tekortschiet.

Betekenis en Conclusie

Het paper concludeert dat de "binding bottleneck" voor autonoom debuggen niet de synthese van code of de validiteit van tests is, maar fault-targeted reasoning. Zelfs de meest geavanceerde modellen worstelen met het diagnosticeren van subtiele, latente fouten.

De bevindingen hebben grote gevolgen voor de ontwikkeling van agente coderingssystemen:

Het verbeteren van algemene code-generatie zal niet automatisch leiden tot betere debugging.
Modellen moeten specifiek worden getraind op het genereren van fouthypothese en het begrijpen van causale relaties in code.
Zelf-diagnose (het genereren van eigen tests) is een krachtig mechanisme, maar alleen als het model de diagnose correct kan stellen; anders degradeert het de prestaties.

VIBEPASS biedt een rigoureuze basis voor het verder ontwikkelen van betrouwbare, autonome software-engineeringssystemen die echt "vibe checks" kunnen doorstaan.