Ruben Bijker
Neem contact op

Vibe coding: de goede manier, de slechte manier en waarom ervaring telt

Door Ruben Bijker · Gepubliceerd · 6 min lezen

Vibe coding is software bouwen door een AI-tool te prompten en over te nemen wat die schrijft. Je beschrijft een feature, de tool maakt de code, je draait hem en als het lijkt te werken ga je door. Voor een prototype kan dat prima zijn. Voor software waar een bedrijf op draait, zit het verschil tussen de goede en de slechte manier in ervaring.

Ik gebruik AI elke dag. Het maakt me sneller. Maar snelheid helpt alleen als je weet waar je heen gaat.

De slechte manier: het werkt, tot het niet meer werkt

De slechte variant lijkt eerst productief. Features verschijnen snel en de demo werkt. De problemen komen later, meestal allemaal tegelijk.

  • Code die niemand begrijpt. Neem je een wijziging over die je niet kunt uitleggen, dan kun je hem niet debuggen, uitbreiden of beoordelen op veiligheid.
  • Geen architectuur. Elke prompt lost het probleem van dat moment op. Niemand bepaalt waar logica hoort, dus staat die overal.
  • Dubbele logica. De tool schrijft vrolijk een tweede versie van iets dat al bestaat. Een bugfix moet dan op drie plekken, en ergens wordt er een vergeten.
  • Een zwak datamodel. Tabellen en velden komen er prompt voor prompt bij. Migraties worden pijnlijk en de data klopt niet meer.
  • Beveiligingslekken. Ontbrekende autorisatiechecks, ongevalideerde input, secrets in de code, een adminroute die iedereen kan bereiken. De app werkt prima, tot iemand ernaar gaat zoeken.
  • Geen tests. Elke nieuwe wijziging kan een oude feature breken, en je merkt het pas als een gebruiker het meldt.
  • Onbeheersbare groei. Elke wijziging duurt langer dan de vorige, omdat de AI om zijn eigen eerdere keuzes heen moet werken. Uiteindelijk is de eerlijke schatting voor een kleine feature een herbouw.

Niets hiervan zie je in een demo. Je ziet het zodra er echte gebruikers, echte data en echt geld bij komen.

De goede manier: een engineer die de AI stuurt

De goede variant gebruikt dezelfde tools. Het verschil is wie de beslissingen neemt.

  1. Bepaal eerst de architectuur. De stack, het datamodel, de grenzen tussen modules en waar de bedrijfslogica woont. Die keuzes zijn vroeg goedkoop en later duur om te veranderen, dus die maak ik, niet de tool.
  2. Geef de AI een helder kader. Conventies, de relevante bestanden, types en schema's. Hoe strakker het kader, hoe beter de output in de codebase past.
  3. Werk in kleine stappen. Eén gerichte wijziging tegelijk is makkelijk te reviewen en terug te draaien.
  4. Review elke diff. Ik lees wat de AI schreef zoals ik de pull request van een collega zou reviewen. Kan ik een regel niet uitleggen, dan gaat hij er niet in.
  5. Test wat ertoe doet. Unittests voor logica, end-to-endtests voor de kritieke flows, en een typecheck en linter bij elke wijziging.
  6. Behandel veiligheid als ontwerptaak. Authenticatie, autorisatie, inputvalidatie en secrets krijgen bewuste aandacht, niet wat de tool als eerste voorstelde.
  7. Lever het goed op. Automatische deployments, preview-omgevingen, error tracking en monitoring vanaf de eerste dag, zodat ik problemen vind en niet je gebruikers.

Zo neemt AI het typwerk en het routinewerk over. Het denkwerk blijft bij iemand die weet hoe goede software eruitziet.

Waarom ervaring de echte voorwaarde is

AI-tools schrijven code die overtuigend oogt. Juist daarom telt ervaring. Om het probleem in plausibele code te zien, moet je weten wat er meestal misgaat: de query die traag wordt met echte data, de race condition, de shortcut die een datalek wordt, de abstractie die de volgende feature niet overleeft.

Dat leer je alleen door jarenlang software te bouwen, live te zetten en te onderhouden, inclusief de delen die misgingen. Zonder die achtergrond kun je goede output niet van slechte onderscheiden, en de AI vertelt het je ook niet.

Houd de architectuur in de gaten

Architectuur houdt een codebase werkbaar terwijl hij groeit. Met AI erbij is dat belangrijker, niet minder belangrijk, omdat code nu sneller wordt geschreven dan iemand terloops kan bijhouden.

  • Houd een duidelijke structuur, zodat elk nieuw stuk code een logische plek heeft.
  • Refactor zodra er duplicatie ontstaat, voordat die zich verspreidt.
  • Verwijder code die niet nodig is. Meer code is meer onderhoud, wie hem ook schreef.
  • Herzie keuzes als het product verandert, in plaats van de AI eromheen te laten patchen.

Hoe ik werk

Ik bouw al meer dan 15 jaar software, van design en frontend tot backend, infrastructuur en hosting. Ik gebruik AI om sneller te werken, en die ervaring om te bepalen wat er gebouwd wordt, hoe het in elkaar past en wat er live gaat. Zo krijg je de snelheid, zonder dat je er later voor betaalt.

Zie ook: AI-ondersteund ontwikkelen en een stack kiezen.

Veelgestelde vragen

Wat is vibe coding?
Software bouwen door aan een AI-tool te beschrijven wat je wilt en de code die het schrijft over te nemen, vaak zonder die goed te lezen. Snel voor prototypes, riskant voor alles wat lang mee moet.
Kan iemand zonder programmeerervaring met AI een product bouwen?
Een demo, ja. Een product vraagt om een goed datamodel, veiligheid, tests, deployment en monitoring. Zonder programmeerervaring kun je niet beoordelen of de AI dat goed heeft gedaan.
Is vibe coding slecht?
Niet per definitie. De tool is het probleem niet. Het probleem is code overnemen die niemand begrijpt. Met een ervaren engineer die stuurt, reviewt en de architectuur bewaakt, maakt AI goed werk sneller.

Bijbehorende dienst: Webapplicatie laten bouwen: maatwerk door een senior developer

Een project in gedachten?

Vertel kort wat je nodig hebt. Je krijgt antwoord van mij, niet van een verkoopteam.

Neem contact op

Verder lezen