AI-assisted engineering, geen vibe coding: het verschil dat ertoe doet

Vibe coding, een term die zich in 2025 verspreidde, betekent aan een AI beschrijven wat je wilt, accepteren wat die produceert, en op gevoel itereren tot het resultaat er goed uitziet. Het is een legitieme manier om een idee te verkennen. Het is snel, goedkoop en oprecht leuk. Wat het niet is, is engineering, want niets in de loop verifieert dat de software zich correct gedraagt, veilig blijft of volgende maand veilig aangepast kan worden. De output wordt op het oog beoordeeld, en het proces laat geen record achter van wat er veranderde, waarom, of of iemand het gecontroleerd heeft.

AI-assisted engineering behoudt de snelheid en schrapt het giswerk. De AI schrijft nog steeds de code, maar elke wijziging landt binnen een leveringsdiscipline: hij wordt geversioneerd op een branch, getoetst aan beleid, doorlopen door geautomatiseerde tests, gescand en geprobed op securityproblemen, en gedeployed via een gecontroleerde pipeline met een rollback-pad. Een mens keurt de wijzigingen goed die consequenties dragen, en een audit trail legt vast dat dat gebeurd is. De prompt is dezelfde. Alles wat na de prompt gebeurt, is anders.

Het onderscheid is niet academisch. Het bepaalt of het ding dat je bouwde klantdata kan bevatten, een securityreview kan doorstaan, het vertrek van zijn maker overleeft, of aan een tweede team overgedragen kan worden. Als het antwoord op één van die vragen ja moet zijn, is de manier van bouwen, niet het model dat bouwt, wat de doorslag geeft.

De term begon als compliment, een naam voor hoe moeiteloos genereren was geworden, en werd een waarschuwingslabel toen de eerste golf AI-gebouwde apps echte gebruikers ontmoette. Niets aan die waarschuwing is anti-AI. De modellen zijn niet het probleem; het ontbrekende systeem eromheen is dat wel, en hetzelfde model in een beheerde delivery loop produceert software waar een bedrijf achter kan staan. Daarom gaat het argument hier over procesarchitectuur, niet over modelkeuze, en daarom geldt het welke leveranciers-AI je ook verkiest. Het geldt bovendien op elke schaal: een tweekoppige startup kan verantwoord vibe-coden door te weten aan welke kant van de lijn hij staat; een bank kan het zich niet veroorloven het niet te weten.

De meeste teams komen dit probleem tegen op het overdrachtsmoment. Iemand in marketing, operations of product vibe-codet een tool die goed genoeg werkt dat mensen erop gaan vertrouwen. Dan heeft hij SSO nodig. Dan slaat hij iets persoonlijks op. Dan vraagt een directeur wie wijzigingen beoordeelt, en het eerlijke antwoord is niemand. Op dat punt zijn de keuzes lelijk: hem fatsoenlijk herbouwen, hem as-is adopteren en onbekend risico erven, of een tool doden die mensen al gebruiken.

De kosten duiken op in drie grootboeken. Ten eerste herbouwwerk: prototypes die niet kunnen doorstromen worden vanaf nul herbouwd, wat betekent dat het snelle pad eigenlijk het trage pad was. Ten tweede securityblootstelling: onbeoordeelde gegenereerde code gaat naar productie met welke toegangspatronen en dependencies het model toevallig koos, en niemand kan zeggen wat erin zit. Ten derde reviewknelpunten: wanneer AI het volume aan wijzigingen vermenigvuldigt maar de review- en testcapaciteit gelijk blijft, vertraagt óf het uitleveren naar het oude tempo, óf zakt het toezicht stilletjes weg. Geen van beide is de uitkomst waarvoor iemand een AI-tool kocht.

Er is ook een organisatorische kostenpost die zelden het slide deck haalt: vertrouwen. De eerste vibe-gecodeerde tool die data corrumpeert of een record lekt, maakt elk toekomstig AI-gebouwd voorstel moeilijker goed te keuren. Teams die vroeg discipline vestigen, behouden hun toestemming om snel te bewegen. Teams die het overslaan krijgen meestal één incident, en dan een moratorium.

Als je engineering leidt, is de scherpste versie van de pijn de asymmetrie van de schuld. Het bedrijf viert de snelheid van AI-gebouwde tools tot er precies één faalt, en die fout landt bij engineering, ook wanneer engineering de tool nooit heeft gezien. Die dynamiek maakt een beheerd pad de zet uit eigenbelang, niet alleen de verantwoordelijke zet: het enige duurzame antwoord op ongesanctioneerd bouwen is een gesanctioneerde manier van bouwen die even snel is. Verboden overleven het contact met een tool die iemands maandagochtendprobleem oplost niet; betere defaults wel.

Een snelle zelftest. Kun je de laatste drie wijzigingen aan de app benoemen en wie ze goedkeurde? Als de app nu meteen zou breken, zou iets anders dan een gebruiker het je vertellen? Zou een collega de wijziging van gisteren kunnen terugdraaien zonder jou in de kamer? Stopt iets automatisch een publicatie wanneer een loginflow breekt? Heb je meer dan één keer nee geantwoord, dan ben je aan het vibe-coden. Hoe je tooling ook heet.

Niets hiervan is een argument tegen prototypen op gevoel. Exploratie is waar goede producten vandaan komen, en volledige discipline afdwingen op een wegwerp-spike verspilt ieders tijd. Het faalpatroon is niet prototypen; het is prototypes die stilletjes productie worden omdat niemand de lijn trok. Bepaal waar de lijn ligt voordat de tool hem oversteekt, en maak het oversteken een bewuste daad met een checklist. Geen geleidelijke opeenstapeling van gebruikers. Wil je een gestructureerde versie van die zelftest, dan loopt de vibe coding risicoscorecard er vraag voor vraag doorheen.

Draai dezelfde test ook op portfolioniveau. De meeste organisaties hebben niet één AI-gebouwde app; ze hebben er tientallen, in wisselende staten van discipline, en geen lijst. Een inventaris met benoemde eigenaren, zelfs een ruwe spreadsheet, zet een onbekend risico om in een beheerd risico, en brengt meestal twee of drie tools aan het licht die stilletjes kritiek werden terwijl niemand keek. Dat zijn je eerste kandidaten voor het beheerde pad, gerangschikt op datagevoeligheid en gebruikersaantal in plaats van op wie het hardst roept.

Automo is gebouwd zodat het snelle pad en het gedisciplineerde pad hetzelfde pad zijn. Je beschrijft de app in gewone taal en Automo genereert echte React-, TypeScript- en Supabase-applicaties die je bezit, maar elke wijziging landt binnen de delivery loop in plaats van ernaast. Guardrails koppelt code aan bedrijfsdomeinen, detecteert risicovolle wijzigingen, past plain-English-beleid toe, legt menselijke review vast en laat een audit trail achter elke merge. QA draait deterministische browserreplays, self-healing tests, smoke gates vóór publicatie en productiechecks na publicatie. Security draait statische scanning, dependency-checks en toegangscontrole-probes, en bevestigt kwetsbaarheden tegen de live app voordat ze gemarkeerd worden.

Het resultaat is dat een prototype en een productie-app op Automo niet twee verschillende artefacten zijn. Het is hetzelfde artefact op verschillende niveaus van toezicht, met het toezicht toegepast door het platform in plaats van door wie het toevallig onthoudt. Code is standaard React, TypeScript en Tailwind, op elk moment exporteerbaar naar je eigen repo, dus de discipline wordt nooit een kooi. Voor teams die serieuze productieprogramma's draaien is dat de pitch in één regel: AI-assisted engineering, geen vibe coding. Serieuze ontwikkelprogramma's beginnen bij USD 10.000 per jaar; een demo is de snelste manier om de loop end-to-end te zien draaien.

Eén eerlijke kanttekening: geen enkel platform maakt discipline gratis. Beleid moet nog steeds geschreven worden, beschermde zones moeten aangewezen worden, en iemand blijft eigenaar van de afwegingen bij gemarkeerde wijzigingen. Wat een platform verandert is de default. Op Automo is het ongedisciplineerde pad het pad dat extra moeite kost, het omgekeerde van hoe de meeste tooling werkt. In de praktijk is die omkering wat beslist of de standaarden van een team het contact met een deadline overleven.