Het vibe coder-probleem

Een vibe coder is iemand die een AI een prompt geeft, de output accepteert, het live zet, en het niet kan debuggen als het stuk gaat.

In 2025 was de term nog een meme. In 2026 is het een soort founder-probleem waarvoor wij ingehuurd worden. Het patroon is zo voorspelbaar dat we de diff al kunnen raden voordat we de repo openen.

Dit stuk gaat niet over de vraag of AI goed code schrijft. Dat is zo. Dit stuk gaat over wat er gebeurt als een AI de code schrijft en er geen ontwikkelaar in de loop zit die hem leest, refactort, de helft eruit gooit die er niet bij past, en de test toevoegt waar nooit om gevraagd is.

De vorm van de codebase die we komen opruimen

We hebben dit kwartaal drie "fix de vibe-gecodeerde codebase"-projecten gedaan. De vorm is zo consistent dat het inmiddels een checklist is.

• Geen domeinmodel. Elke feature is los van de rest geprompt. Het user object heeft één vorm in onboarding, een andere in billing, een derde in het admin-paneel. Op staging zie je dat niet. In productie komt dezelfde klant terug als drie klanten in drie verschillende rapporten.
• Geen tests, of erger, tests die allemaal slagen. Tests die naast de code zijn gegenereerd die ze zogenaamd moeten verifiëren. Elke test bewijst dat de code doet wat de code doet. Ze staan groen en bewijzen niks. De eerste echte bug glipt er ongemerkt doorheen.
• Niets weggehaald. Oude code is nooit weggegooid toen er nieuwe bij kwam. De codebase is een museum van elke richting die de founder ooit heeft geprobeerd. Drie auth-strategieën, twee betaalintegraties, een half afgebouwd referral-programma dat iemand in week zes heeft laten liggen. Elke nieuwe feature moet doen alsof de andere niet bestaan.
• Eén iemand die het "een beetje" snapt. Meestal de founder. Soms een freelancer die inmiddels niet meer reageert in Slack. Degene die de code heeft opgeleverd, heeft geen mentaal model van het geheel; hij heeft een mentaal model van de prompts die de code hebben opgeleverd, en dat is niet hetzelfde.

Waarom typen nooit het ontwikkelwerk was

De code typen was nooit het ontwikkelwerk. Het was het zichtbare deel, het deel dat uren kostte en op werk leek. Het echte werk was altijd het deel dat zich niet goed laat fotograferen: beslissen wat je bouwt, hoe het samenkomt, wat je weglaat, wat je weggooit, welke 5% van het oppervlak het onder load houdt, waar de naden tussen subsystemen horen, en wat je doet als twee requirements elkaar stilletjes tegenspreken.

Toen typen langzaam was, gebeurden die beslissingen in de gaten tussen het typen. Een ervaren ontwikkelaar schreef een functie, hield even stil, zag in dat hij niet paste bij de rest van het systeem, gooide hem weg, en begon opnieuw. Dat weggooien was de ontwikkeling. Het typen was het bijproduct.

In 2026 is het typen snel en het weggooien gebeurt nooit. De AI houdt geen pauze. De AI ziet niets in. De AI gooit zijn eigen output niet weg tenzij je het hem opdraagt. Als de ontwikkelaar in de loop óók geen pauze houdt, niets inziet, en niets weggooit, dan doet niemand het.

Wat wij anders doen

Wij zijn niet tegen AI. Elke ervaren ontwikkelaar in het team gebruikt Claude Code, Cursor, of allebei, elke dag. Wat een ervaren ontwikkelaar in 2026 oplevert, is twee tot drie keer zoveel als in 2024. Die vermenigvuldiger is de hele reden dat onze pricing werkt. Het verschil zit in de 30 seconden tussen de suggestie van de AI en de merge-knop.

• Lees de diff. Elke regel. Een gegenereerde diff lezen kost een fractie van wat het kost om hem drie weken later in productie te debuggen.
• Gooi weg wat er niet bij past. Het meeste AI-werk klopt lokaal en is inconsistent over het geheel. Het werk van de senior is het globale model bewaken.
• Voeg de test toe die de AI niet bedacht. Vooral de test die het negatieve aantoont, het verzoek dat zou moeten falen.
• Verwijder wat nu overbodig is. De AI verwijdert vrijwel nooit iets. De ontwikkelaar wel.
• Lees de logs nadat je live hebt gezet. Vang de regressie vóór de klant dat doet.

Wanneer vibe coding prima is

Voor de duidelijkheid: voor een side project is vibe coding prima. Sterker, het is mooi. De beperking die het vibe-pad duur maakt, is toekomstig onderhoud door een ander mens. Als die toekomstige onderhouder niemand is, ga vooral je gang.

Is die toekomstige onderhouder de rest van je bedrijf voor de komende vijf jaar, huur dan iemand in die de diff gaat lezen.

Wat te doen als je hier al zit

Beschrijft dit stuk jouw codebase, dan heb je drie opties.

• Ermee leven. Genoeg bedrijven hebben dat gedaan. De prijs is dat je trager features oplevert, meer supportlast hebt, en een grotere kans dat je volgende senior-aanname in week twee weer vertrekt.
• Stap voor stap herschrijven. Zoek de twee of drie subsystemen die de meeste productielast dragen. Herschrijf die eerst. Laat de rest voor later. Dit raden we meestal aan.
• Volledig herschrijven. Alleen zinvol als je ook het product gaat pivoten. Anders lever je zes maanden lang niets nieuws op, en dat kunnen de meeste bedrijven zich niet veroorloven.