Vibe Coding is een val - Waarom AI-gebouwde software nog steeds engineers nodig heeft

Andrej Karpathy muntte de term vibe coding in februari 2025 om een manier van softwareontwikkeling te beschrijven waarbij u beschrijft wat u wilt, accepteert wat de AI produceert, en de code niet leest. Zijn formulering was grootmoedig - een weekendhobbymodus voor persoonlijke projecten. Wat volgde was dat niet. Tegen midden 2025 had een golf van niet-engineers productie-SaaS-applicaties gepubliceerd die volledig waren gebouwd in Cursor, Replit Agent, v0 en bolt.new, zonder ooit te begrijpen wat ze hadden gebouwd. De applicaties zagen er goed uit in demo's. Ze falen nu op dit moment in productie.

Wat vibe coding werkelijk is

Karpathy's originele beschrijving is precies: u bent «in de zone», u vertelt de AI wat u wilt, het produceert code, u drukt grotendeels op accepteren en u begrijpt niet volledig wat er draait. Hij erkende dit expliciet - «Ik lees de code niet, ik vibe er gewoon mee.» Voor een persoonlijk hulpmiddel of een wegwerpprototype is dit prima. De vibe coder doet niet alsof hij een engineer is. Het probleem is dat het tool-ecosysteem - Replit Agent's «ship your startup in a weekend», v0's one-click deploys, bolt.new's instant full-stack generatie - deze modus heeft verpakt als een legitiem pad naar productiesoftware.

Dat is het niet. En de resulterende technische schuld is kwalitatief anders dan gewone slechte code.

Waarom vibe code erger is dan slecht handgeschreven code

Wanneer een junior developer slechte code schrijft, begrijpt hij wat hij bedoelde. U kunt met hem gaan zitten, de logica traceren en het corrigeren. Wanneer een AI slechte code genereert die de operator nooit heeft gelezen, is er geen mentaal model te herstellen. De developer kan niet uitleggen waarom de authenticatie zo is gestructureerd, omdat hij de authenticatie nooit heeft gelezen. Hij kan u niet vertellen welke externe bibliotheek betalingen afhandelt, omdat hij het bestand accepteerde zonder het te openen. De code is een black box die hij bezit maar waarover hij niet kan redeneren.

De faalpatronen die we consistent zien in AI-gegenereerde productie-applicaties:

• Auth-bypasses ingebakken in het scaffold. AI-gegenereerde auth-code kopieert frequent patronen uit trainingsdata zonder het beveiligingsmodel te begrijpen. Row-level security «tijdelijk» uitgeschakeld tijdens ontwikkeling, in productie gelaten. JWT-secrets hardcoded in voorbeelden van omgevingsvariabelen die naar publieke repo's zijn gecommit. Rolcontroles die stringliteralen vergelijken en kapotgaan zodra een veld wordt hernoemd.
• Geen foutafhandeling voorbij het happy path. De AI schreef het successcenario. Wat gebeurt er wanneer de betalingsprovider een 402 teruggeeft? Wat gebeurt er wanneer de databaseverbinding halverwege een transactie wegvalt? In vibe-gecodeerde applicaties is het antwoord meestal een niet-afgehandelde promise rejection die verschijnt als een leeg scherm.
• Vendor lock-in op AI-gegenereerde patronen. Toen de AI koos om het datamodel op een bepaalde manier te structureren, accepteerde de vibe coder dit. Nu is de hele applicatie rondom die structuur gebouwd. Migreren weg ervan vereist inzicht in code die de developer nooit heeft gelezen.
• Geen tests. Niet omdat tests moeilijk zijn, maar omdat de vibe coder er nooit om vroeg en de AI ze niet vrijwillig aanbood. Wanneer er iets kapotgaat in productie, is er geen testsuite om regressies in de fix op te vangen.

De kloof van demo naar productie

AI-tools zijn echt goed in het genereren van code die werkt tegen een happy path met schone invoer, een coöperatief netwerk en één gelijktijdige gebruiker. Dat is precies de conditie waaronder een demo draait. Productie is het tegenovergestelde: misvormde invoer, weggevallen verbindingen, gelijktijdige schrijfoperaties, edge cases die nooit zijn gespecificeerd in de prompt.

Het patroon speelt zich voorspelbaar af. Een vibe-gecodeerde applicatie wordt gelanceerd, ziet er gepolijst uit, krijgt vroege gebruikers. Dan: een gebruiker met een niet-ASCII-teken in zijn naam breekt de databasequery. Een mobiele gebruiker op een trage verbinding triggert een race condition in het state management. Een concurrent meldt zich aan en ontdekt dat de API-endpoints data van andere gebruikers retourneren omdat de autorisatiecontrole aan de frontend-kant zat, niet op de server. Dit zijn geen exotische fouten. Ze zijn de basale consequentie van het uitleveren van code die men nooit heeft gelezen.

AI maakt goede engineers beter - het maakt slechte engineers niet overbodig

Dit is de claim die het vibe coding-verhaal omkeert. De tools zijn echt en de productiviteitswinsten zijn echt. Bij webvise gebruiken we Claude Code, Cursor en multi-agent orchestratie op elk project dat we leveren. Een senior engineer met Claude Code levert in uren wat eerder dagen kostte. Dezelfde tools in de handen van iemand zonder engineering-fundamentals produceren een demo die de eerste echte gebruiker niet overleeft.

Het verschil zit niet in de tool - het zit in wat de engineer meebrengt naar de tool. Engineering-fundamentals gaan niet over het met de hand schrijven van code. Ze gaan over het begrijpen van systeemgrenzen, faalmodi, beveiligingsmodellen en data-integriteit. Een engineer die Claude Code gebruikt leest de gegenereerde authenticatiecode en herkent wanneer die onjuist is. Een vibe coder drukt op accepteren en levert het af.

Het specifieke risico voor bedrijfssoftware

Consumenten-hobbytoepassingen kunnen de faalmodi van vibe coding absorberen. Als een persoonlijke financiëntracker wat data verliest, is dat vervelend. Als een B2B-SaaS die klantgegevens, betalingsstromen of interne workflows afhandelt wordt uitgeleverd met de hierboven beschreven auth- en foutafhandelingsproblemen, zijn de gevolgen juridisch, contractueel en reputatieschade. De AVG vrijstelt u niet omdat u uw eigen dataverwerkingscode niet heeft gelezen.

De golf van AI-gegenereerde SaaS-applicaties van 2025-2026 heeft een voorspelbare klasse startups voortgebracht: indrukwekkend in een demo, vroege klanten gewonnen op de belofte, dan tegen een muur gelopen toen de eerste enterprise-prospect een beveiligingsreview uitvoerde of de eerste dag met hoog verkeer de ontbrekende foutafhandeling blootlegde. De oprichters zijn geen fraudeurs - ze wisten oprecht niet wat ze hadden gebouwd.

Waar u op moet letten bij een AI-vergroot ontwikkelpartner

Als u een ontwikkelpartner evalueert die beweert AI-tools te gebruiken, stel dan deze vragen:

• Voeren zij geautomatiseerde tests uit op AI-gegenereerde code? Als het antwoord is «we vertrouwen de AI-uitvoer», loop dan weg. Testdekking is hoe u de foutafhandeling opvangt die de AI heeft weggelaten.
• Voeren zij beveiligingsreviews uit op gegenereerde authenticatie- en autorisatiecode? AI-tools kopiëren auth-patronen uit trainingsdata. Die patronen bevatten echte kwetsbaarheden uit echte codebases.
• Kunnen zij de architectuur uitleggen van wat zij hebben gebouwd? Als een developer u niet door het datamodel kan leiden en kan uitleggen waarom het zo is gestructureerd, heeft hij het niet ontworpen - hij heeft het geaccepteerd.
• Versiebeheren zij hun prompts naast de code? Engineering-discipline toegepast op AI-tools betekent de prompt behandelen als onderdeel van de codebase, niet als een wegwerpinvoer.
• Hebben zij een proces voor het omgaan met AI-hallucinaties? AI-tools genereren vol vertrouwen onjuiste API-aanroepen, verouderde methoden en niet-bestaande bibliotheekfuncties. Een ervaren team heeft hier een reviewlus voor. Een vibe coder ontdekt het tijdens runtime.

Het juiste kader: AI als krachtmultiplier, niet als vervanging

Het vibe coding-verhaal is verleidelijk omdat het gedeeltelijk waar is. AI-tools hebben de drempel voor het bouwen van software werkelijk verlaagd. Een gemotiveerde niet-engineer kan in een weekend een werkend prototype opleveren. Dat is waardevol voor validatie, MVP's, interne tooling met lage inzet. De fout is de vloer als het plafond te behandelen - aannemen dat omdat u iets aan de praat kunt krijgen, u het ook betrouwbaar op schaal, veilig en onderhoudbaar aan de praat kunt krijgen.

De engineers die het meeste hebben geprofiteerd van AI-coderingstools zijn degenen die ze gebruiken om de vervelende delen van engineering te elimineren - boilerplate, scaffolding, repetitieve refactors - terwijl ze hun oordeel toepassen op de delen die ertoe doen: architectuur, beveiliging, foutafhandeling en productiegereedheid. De AI versnelt het werk. De engineer zorgt ervoor dat het correct is.

Bij webvise gebruiken we AI-vergroot ontwikkelen op elk project - Claude Code, Cursor, multi-agent pipelines - maar met de engineering-discipline die de uitvoer productieklaar maakt. Als u software bouwt die echte gebruikers, echte edge cases en echte beveiligingsvereisten moet overleven, laten we praten over hoe we werken.