Vibe coding vs Vibe engineering
Het schrijven van blogs neemt toch meer tijd in beslag dan ik had bedacht. Ik wil graag meer diepgang krijgen in de blogs door praktijkvoorbeelden te gebruiken. Ik had verwacht dat AI wel alle teksten zou genereren zoals ik in mijn hoofd heb, maar dat valt nog erg tegen. Als ik de gegenereerde teksten lees dan voelen ze hol aan en zijn ze vluchtig geschreven. Mogelijk heb ik nog niet de juiste setup en tone of voice gevonden voor mijn blogs. Mogelijk krijg ik in de toekomst het voor elkaar om een goede humanizer te maken. Tot die tijd schrijf ik zelf de blogs. Ik gebruik wel AI om mijn teksten proef te lezen en te controleren of mijn zinsopbouw klopt.
Er is geen beter moment om te schrijven over vibe coding versus vibe engineering. Het onderwerp vibe coding is in Nederland actueler dan ooit. Vorige maand was er nog een mooie uitzending van Nieuwsuur over vibecode-workshops en de meest geavanceerde AI-tool die zo goed kan hacken dat deze achterdeuren vindt die al meer dan 10 jaar in veelgebruikte software zitten. Een super interessante tijd om in te leven! Als dit geen systeemtechnologie is, dan weet ik het ook niet meer.
Andrej Karpathy, voormalig AI director van Tesla en mede oprichter van OpenAI, introduceerde in februari 2025 de term vibe coding. Het ontwikkelen van websites/software op basis van gevoel, zonder benodigde technische kennis. Andrej is een held en kan concepten goed uitleggen. Volg hem op YouTube of X. Hij zit altijd bovenop het laatste nieuws. Een van zijn betere video’s vind ik deze video over hoe software aan het veranderen is die hij gaf voor een AI-startupschool in Amerika.
IT was altijd al een creatief beroep
Hopelijk ben je nog niet weggezapt en wil je verder lezen. Het verschil tussen Vibe coding en Vibe engineering leg ik uit aan de hand van twee voorbeelden uit eigen praktijk. Allereerst hoe ik met mijn zoontje van zeven jaar een game in elkaar zette volgens het vibecodeprincipe. En als tweede hoe ik bij FreezerData de MVP voor onze Virtuele Service Monteur heb gebouwd volgens het vibe-engineeringprincipe.
Ik heb IT altijd al ervaren als een creatief beroep. Binnen dat vak zie ik grofweg twee stromingen developers. Aan de ene kant de ambachtelijke stroming: developers die het mooi vinden om schone en perfecte code te schrijven. Elke functie netjes, elke naamgeving doordacht. Aan de andere kant de resultaatgerichte stroming: developers die bouwen om de uitkomst. Die willen weten: lost dit het probleem op, levert dit meerwaarde, werkt het. Beide stromingen hebben bestaansrecht. Maar met de komst van codeerassistenten verschuift het zwaartepunt. Het tikken van perfecte code wordt minder belangrijk. Het nadenken over wat je wilt bouwen en waarom, wordt juist belangrijker.
Zelf ben ik altijd van het resultaatgerichte geweest. Goed is goed genoeg.
Het betere is de vijand van het goede.
— Montesquieu
Retro iPad game gevibecoded!
Afgelopen zomer bouwde ik met mijn zoontje een game die hij in gedachten had. Voor mij was het een test: hoe ver kom je met vibe coding?
Hij wilde zo graag een iPad-game kopen, maar ik weigerde. Al die spelletjes die je eindeloos kunt spelen en waar geen einde aan lijkt te komen. In plaats daarvan triggerde ik hem om na te denken over wat voor game hij zelf zou willen.
De regel: geen toetsenbord aanraken. Ik had gehoord van Lovable en besloot het samen met hem uit te proberen. Ik sprak zijn ideeën letterlijk in op de iPad. Lovable nam de gesproken tekst en ging bouwen. Het resultaat: een echt speelbare game, Retro iPad Adventure Game. Probeer het eens uit!
Dit vind ik typisch een voorbeeld van vibe coding. Ik heb puur de creatieve ideeën doorgespeeld naar een programmeerassistent en deze heeft dit omgezet in code. Een werkende game! Met een joystick en een poppetje dat over het scherm kan bewegen en beloningen krijgt als deze over vlakken heen gaat. Zoals ze tegenwoordig zeggen: code is cheap. Het genereren ervan kost vrijwel niets. De code is gegenereerd, maar ik heb hem nooit bekeken en ben ook niet van plan dat te gaan doen. Ik test alleen de uitkomst door de game te spelen en stuur met iedere prompt bij wat nog niet klopt.
Vibe coden is puur aangeven wat je wilt hebben. Je beschrijft het met woorden, je geeft richting, maar het blijven allemaal functionele requirements. Geen non-functional requirements. Het geniale eraan: ideeën die alleen in je hoofd zitten, breng je zo tot leven. En met zo’n proof of concept in handen kun je je idee veel concreter pitchen bij een echte engineer. Gebruik dit alleen voor Proof of Concepts die je nooit in productie gaat nemen. Beproef het, gooi de code weg en bouw later een echt minimum viable product (MVP).
Geniaal! Taalmodellen brengen programmeren binnen handbereik van iedereen. Eén voorwaarde: creativiteit. Of toch niet? Wat doe je met al die niet-functionele requirements?
Vibe Engineering
Engineering is nadenken over architectuur, schaalbaarheid, security, onderhoud, koppelingen met andere systemen, en hoe kan je ervoor zorgen dat het over een paar jaar nog draait. AI kan je hierbij ook helpen. Maar je moet het wel vragen om het te doen. Als je gestructureerd aan de slag gaat als een ingenieur dan ben je bezig met Vibe Engineering. Maar het blijft wat mij betreft Vibe als je zelf niet naar de code kijkt en deze niet zelf beoordeelt.
Wat mij betreft betekent de term vibe dat je echt alles op gevoel doet. Je controleert niet de code en je gaat ervan uit dat de codeassistent de code schrijft waar je naar vraagt.
In de praktijk bij FreezerData
Vroeger kostte het heel veel tijd om alle code te schrijven en daarvoor huurden we bij FreezerData ontwikkelaars in. Aan mij was altijd de taak om de werkvoorbereiding te doen. Door te specificeren wat we willen dat er gebouwd moet worden. Hierin verwerk ik de architectuurprincipes die ik belangrijk vind en schrijf dit altijd met de hand uit. Het grappige hieraan is dat ik eigenlijk al heel veel ervaring heb met het uitschrijven wat er moet worden gebouwd zonder zelf de code te schrijven. Deze ervaring is nu voor mij heel fijn, omdat ik hetzelfde kan toepassen bij codeerassistenten.
Virtuele Service Monteur (MVP)
Hoe heb ik dan vibe engineering ingezet in het afgelopen jaar? We zochten vorig jaar februari via UpWork een ontwikkelaar die ons kon helpen met het bouwen van een ‘chatbot’. We hadden een challenge uitgeschreven en één ontwikkelaar uit Oekraïne won deze. We gingen aan de slag en hij kon ons helpen met het bouwen van een chatbot voor koelmonteurs. Echter merkten we dat de PoC snel was opgezet, maar dat deze persoon daarna vooral veel uren schreef en zeer weinig opleverde. Ondertussen was hij wel sociaal heel vaardig en zei hij iedere ochtend netjes goedemorgen en aan het einde van de dag, een fijne avond. Maar na 1 maand bleek het ontwikkelen toch te sloom te gaan en hebben we de samenwerking stopgezet. Maar daar zat ik dan met alle uitgeschreven requirements voor onze chatbot.
Toen heb ik zelf de proef op de som genomen. Hoe kan ik in de zeer beperkte tijd die ik beschikbaar heb tussen alle andere bedrijven door, toch een goede MVP neerzetten?
Ik installeerde Cline in VSCode, zette een veilige devcontainer op en ging aan de slag. Voor mij was het belangrijk om een werkende MVP op te leveren die ik begin mei mocht demonstreren en presenteren bij het seminar van het Lectoraat Industriële Digital Twins. Ik moest en zou een werkende applicatie opleveren, de kwaliteit van de code was niet belangrijk. Maar het resultaat en hoe het eruit zag wel.
Maar goed, hoe zag mijn setup er verder uit? Alle non-functional requirements heb ik uitgeschreven in help-bestanden voor de codeerassistent. De gehele architectuur had ik uitgeschreven volgens een memory bank. Hierin staat opgesomd hoe de frontend met de backend moet communiceren. In welke taal de backend geschreven moet worden. Welke dependencies (softwarepakketjes van andere ontwikkelaars) mogen worden gebruikt. Hoe ziet de structuur eruit in de broncode. Welke mappen zijn er en in welke map stop je welke bestanden. Zorg voor database-migratiebestanden om controle te houden hoe de database is opgebouwd. Gebruik een ORM voor database-toegang. Deze memory bank was opgedeeld in meerdere bestanden waarin stond uitgeschreven wat de projectbriefing is, wat voor een soort product je wilt bouwen, welke systeempatronen en welke technology stack en een bestand waarin werd bijgehouden wat de voortgang is.
De demo’s
In de eerste video zie je het kernprobleem: hoe koppel je handleidingen aan de objecten in ons klantportaal? We hebben handleidingen per merk en type koel- en vriesinstallaties, en specifieke handleidingen per data collector. De app synchroniseert de objecten en koppelt beide soorten handleidingen aan de juiste objecten. Zo weet de chat welke handleiding bij welk object hoort.
De tweede video laat zien hoe de chat-interface eruit ziet. De monteur kan een vraag typen, of inspreken via voice-to-text. De koppeling met Whisper voor spraakherkenning was een fluitje van een cent.
De gestelde vraag wordt vergeleken met de handleidingen op basis van RAG (Retrieval Augmented Generation). De handleidingen staan als embeddings opgeslagen in een vector database (Pinecone). Concreet: elke alinea uit de handleiding is omgezet in een vector, en bij elke vraag worden de meest relevante stukken tekst opgehaald. Die stukken gaan samen met de vraag naar het taalmodel, dat het antwoord formuleert.
Het antwoord komt terug met een dieplink naar de juiste pagina in de handleiding (PDF), zodat de monteur altijd kan terugvallen op de bron. Bronvermelding was voor mij essentieel: de monteur moet uiteindelijk letterlijke instructies uit de handleiding volgen. De chatbot helpt vooral om die instructies sneller te vinden en in begrijpelijke taal te formuleren.
Speech-to-speech kwam er later bij. De monteur kan het antwoord ook gesproken horen, handig wanneer zijn handen onder een installatie zitten. Met de juiste API-koppeling was dat snel ingebouwd.
Op dit moment valideren we grondig de kwaliteit van de antwoorden. Daarnaast zoeken we funding om de VSM grootser op de markt te brengen.
Hulpmiddelen die het verschil maken
De tools rondom vibe engineering worden in rap tempo volwassen. Twee patronen die ik zelf gebruik:
Memory bank. Je voegt context toe aan het project met een vaste set bestanden waarin staat wat de assistent tussen sessies moet onthouden: projectcontext, architectuurkeuzes, voortgang, do’s en don’ts. Bij de VSM heb ik dit ingericht zoals hierboven beschreven. Je hoeft niet bij elke nieuwe sessie opnieuw uit te leggen wat je aan het bouwen bent.
Skills. Een nieuwere ontwikkeling die in steeds meer AI-coding-tools opduikt: gecureerde vaardigheden die je een AI-agent meegeeft voor terugkerende taken. Denk aan een vaste manier om tests te schrijven of PR’s te reviewen, maar ook aan design-skills voor UI-werk, presentatie-skills voor slides, of een vaste security-check. Skills zijn niet beperkt tot programmeren. Je breidt je toolbox uit met eigen skills of skills uit de community. Eén keer goed beschrijven, daarna past de assistent het consistent toe.
Bij vibe coding sla je dit allemaal over. Bij vibe engineering investeer je juist in context, herhaalbaarheid en overdraagbaarheid. Die investering verdient zich snel terug zodra een project langer dan een middag meegaat.
Vibe Code Cleaner
Voor mijn zoontje maakt niets van dit alles uit. Zijn game hoeft niet AVG-proof te zijn en hoeft volgende week niet op te schalen naar een miljoen gebruikers. Maar als een directeur zoiets bouwt voor zijn klanten, of een gemeente voor burgerdata, ligt het fundamenteel anders. De rekening komt dan ergens anders te liggen: bij gebruikers wier data lekt, bij beheerders die maanden bezig zijn een onbegrijpelijke codebase op te ruimen, of bij teams die de PoC moeten herbouwen tot iets dat productie aankan.
Niet voor niets duikt er al een rolomschrijving op die ze “Vibe Code Cleaner” noemen: iemand die moet opruimen wat anderen in een middag hebben weggeprompt. Ik verwacht hier een hele schaduwindustrie van: mensen die de gegenereerde rommel weer beheersbaar maken, technische schuld inlossen, en alsnog de non-functional requirements inbouwen die in de eerste sprint werden overgeslagen.
Vibe coding is geweldig voor prototypes, voor leren, voor samen iets maken met je kind. Vibe engineering brengt je een stap verder: gestructureerd werken, context vastleggen, regels meegeven. Maar zelfs dan kom je er niet onderuit dat iemand de code daadwerkelijk leest en begrijpt. Anders weet niemand precies wat de software doet en wordt elke aanpassing een gok. En gelukkig heb je daar toch nog de specialisten voor nodig die zijn opgeleid tot software engineer.
De term kantelt nu alweer
Terwijl ik dit schrijf, schuift “vibe engineering” zelf alweer op. Simon Willison, die de term ooit bedacht, schrijft nu meer over agentic engineering patronen: software bouwen met coding agents die niet alleen code genereren, maar die ook zelf uitvoeren. Volgens hem staat dat “aan het andere uiteinde van het spectrum” van vibe coding. Code genereren is goedkoop geworden, maar het vakmanschap verschuift. Het verdwijnt niet.
Ook Karpathy verschuift naar de term Agentic Engineering en geeft daar meer uitleg over waar het naar toe gaat: From Vibe Coding to Agentic Engineering
Karpathy maakt in die video een onderscheid dat blijft hangen. Vibe coding verlaagt de drempel zodat iedereen iets kan bouwen. Agentic engineering houdt juist de kwaliteitslat van professionele software op peil: je blijft verantwoordelijk voor wat je oplevert, alleen sneller. Volgens hem gaat de snelheidswinst voor wie hier goed in is, ook een stuk verder dan de bekende 10x-engineer.
Tot slot
Vibe engineering is het toevoegen van spelregels, non-functional requirements en meer context waar de codeerassistent zich aan moet houden. Het feit dat bij vibe coding de code niet wordt bekeken of gereviewd, duidt erop dat de applicatie alleen maar gebruikt kan worden als demo. Niet als een volwaardige en beheersbare applicatie. Ook bij vibe engineering blijft het reviewen en begrijpen van de code essentieel.
Een van de eerste plekken waar dit concreet wordt, is bij onderlinge werkafspraken. Welke afspraken maak je binnen je team, met je opdrachtgever, over hoe en waar je AI inzet? Ben je transparant over wat jij zelf getikt hebt en wat een taalmodel heeft uitgespuugd? Bij mijn opdrachtgever Provincie Zuid-Holland worden daar op dit moment kaders voor ontwikkeld. Hoe zorg je ervoor dat je de AI slop niet over de schutting gooit naar een collega? Daar gaat mijn volgende persoonlijke blog over.
Welke AI-werkafspraken heb jij met je team of opdrachtgever? En ben je daar transparant over? Laat jij de code nog reviewen door een ‘echte’ collega van vlees en bloed? Ik ben benieuwd naar jouw ervaringen, reacties en voorbeelden. Stuur me jouw visie erop zodat ik die mee kan nemen in de volgende blog.
Wil je op de hoogte blijven of meedenken? Volg me dan op LinkedIn.