Het vibe coder-probleem

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

In 2025 was de term nog een meme. In 2026 is het een categorie founder-probleem waarvoor wij ingehuurd worden. Het patroon is zo consistent dat we de diff kunnen voorspellen 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 in isolatie geprompt. Het user object heeft één vorm in onboarding, een andere in billing, een derde in het admin-paneel. Op staging is dit onzichtbaar. In productie zie je 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 lopen groen en bewijzen niks. De eerste echte bug glipt er ongemerkt doorheen.
• Geen verwijdering. Oude code is nooit weggehaald toen nieuwe code erbij kwam. De codebase is een museum van elke richting die de oprichter 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 persoon die het "een beetje" begrijpt. Meestal de founder. Soms een freelancer die inmiddels niet meer reageert in Slack. De persoon die de code ge-ship't heeft, 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 engineering-werk was

De code typen was nooit het engineering-werk. 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 engineering. 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 engineer in de loop óók geen pauze houdt, niets inziet, en niets weggooit, dan doet niemand het.

Wat wij anders doen

Wij zijn niet anti-AI. Elke ervaren ontwikkelaar in het team gebruikt Claude Code, Cursor, of allebei, elke dag. De output van een ervaren ontwikkelaar in 2026 is twee tot drie keer wat het in 2024 was. 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. De kosten van het lezen van een gegenereerde diff zijn een fractie van de kosten van hem drie weken later in productie debuggen.
• Gooi weg wat er niet bij past. Het meeste AI-werk is lokaal correct en globaal inconsistent. Het werk van de senior is het globale model afdwingen.
• Voeg de test toe die de AI niet bedacht. Vooral de test die het negatieve bewijst, het verzoek dat zou moeten falen.
• Verwijder wat nu overbodig is. De AI verwijdert vrijwel nooit iets. De engineer wel.
• Lees de logs na deploy. 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 tragere feature-velocity, meer supportlast, en een grotere kans dat je volgende senior-aanname in week twee weer vertrekt.
• Incrementeel herschrijven. Identificeer de twee of drie subsystemen die de meeste productielast dragen. Herschrijf die eerst. Laat de rest voor later. Dit is wat we meestal aanraden.
• Volledig herschrijven. Alleen zinvol als je ook het product gaat pivoten. Anders zijn het zes maanden niets nieuws opleveren, en dat kunnen de meeste bedrijven zich niet veroorloven.