Het formulier is succesvol verzonden.
Meer informatie vindt u in uw mailbox.
Inhuren
Over onsDienstenTechnologieënIndustrieënPortfolio
Allereerst heb ik jullie een beetje voor de gek gehouden met de titel. Er is geen echte “Vibe-codering versus traditionele codering” oorlog. AI schrijft tegenwoordig code. Mensen maken er gebruik van. Teams bouwen ermee. Sommigen bouwen er zelfs complexe producten mee. We kunnen discussiëren of dat spannend, riskant, vervelend of alle drie tegelijk is, maar we kunnen niet doen alsof het niet gebeurt.
Verandert AI het programmeren dan voorgoed?
Ja. Dat is het al.
Maar niet in de eenvoudige AI vervangt ontwikkelaars zoals mensen graag online over discussiëren. De echte verandering is praktischer van aard: softwareteams moeten nu beslissen wat ze veilig aan AI kunnen delegeren, wat nog menselijke inbreng vereist en hoeveel risico ze bereid zijn te nemen omwille van de snelheid.
Daar komt de vergelijking goed van pas. Niet als een strijd tussen oud en nieuw, maar als een manier om de afwegingen te begrijpen.
In dit artikel gaan we het hebben over Vibe-codering versus traditionele programmering op het gebied van snelheid, controle, codekwaliteit, beveiliging, testen en onderhoud op de lange termijn — en waar AI-ondersteunde ontwikkeling zich tussen deze twee bevindt.
Ontwikkeling van Vibe-codering dat is wanneer je een AI-tool vertelt wat je wilt bouwen, en die vervolgens een groot deel van de code voor je schrijft. De tools: Claude Code, OpenAI Codex, Replit, Lovable, Bolt, enz.
In plaats van met een leeg bestand te beginnen en alles regel voor regel in te typen, begin je met een opdracht. Bijvoorbeeld: “Maak een eenvoudig boekingsformulier voor me”, “Voeg een gebruikersaanmelding toe” of “Maak een dashboard met grafieken”. Vervolgens geeft de AI je code, legt fouten uit, lost bugs op of bouwt zelfs complete functies.
De term raakte in zwang nadat Andrej Karpathy heeft het gebruikt om een meer relaxed manier van programmeren met AI te beschrijven — waarbij je het idee volgt, dingen snel test en de tool een groot deel van het zware werk laat doen.
Met Vibe Coding kun je complete schermen, functies, tests en app-workflows maken. Als je het mij vraagt, zou ik zeggen dat het voelt alsof je leiding geeft aan een razendsnelle junior-ontwikkelaar, die ook wel eens met veel zelfvertrouwen dingen kapotmaakt.
Daarom is vibe coding ideaal voor snelle ideeën, prototypes, MVP’s, interne tools en experimenten. Je kunt veel sneller dan voorheen iets werkends bouwen.
Als je al meteen naar ChatGPT bent gegaan om je nieuwe ‘unicorn’-app te bouwen, wacht dan even. AI weet niet altijd (bijna nooit) wat veilig, schaalbaar of netjes is. Het kan je code geven die vandaag werkt, maar volgende maand voor hoofdpijn zorgt. Dus ‘vibe-coderen’ is handig, maar het moet nog steeds door een mens worden gecontroleerd.
Traditionele programmering is de gebruikelijke manier waarop software wordt ontwikkeld: ontwikkelaars schrijven de code zelf, controleren deze, testen deze, verhelpen fouten en zorgen ervoor dat de software het gebruik door echte gebruikers aankan.
Hier bepalen de ingenieurs hoe het product moet worden opgezet. Ze kiezen de tech stack, ontwerpen de architectuur, schrijven de logica, controleren de code, testen alles en houden rekening met beveiliging, prestaties en toekomstige aanpassingen.
Het gaat meestal langzamer dan vibe-coderen, vooral in het begin. Je krijgt niet in één keer een complete functie met één prompt. Je hebt planning, technische afwegingen en daadwerkelijk programmeerwerk nodig. Heel ouderwets. Heel erg van het type “open de IDE en lijd een beetje”.”
Maar juist die extra controle is waar het om gaat.
Bij traditionele programmering begrijpen ontwikkelaars wat er onder de motorkap gebeurt. Ze weten waarom het systeem werkt, waar de risico’s liggen en hoe ze problemen kunnen oplossen als er iets misgaat. Dit is van groot belang voor complexe producten, bedrijfssoftware, fintech-apps, zorgsystemen, SaaS-platforms en alles wat met gevoelige gegevens of echt geld te maken heeft.
Geen van beide benaderingen is per definitie beter. Het hangt af van wat je aan het ontwikkelen bent, hoeveel risico je kunt verdragen en of je een snel prototype nodig hebt of een product dat over een jaar nog steeds zinvol is voor je team.
Hier is Vergelijking tussen vibe-codering en traditionele codering:
Het interessante is dat de meeste teams niet langer volledig aan één kant van de tafel zitten. Ze gebruiken AI om repetitief werk te versnellen, standaardcode te genereren en ideeën sneller uit te werken, terwijl ze nog steeds vertrouwen op traditionele engineeringpraktijken voor het beoordelen, testen, beveiligen en onderhouden van het eindproduct.
Met andere woorden, de toekomst is waarschijnlijk niet programmeren voor de sfeer versus echt programmeren. Het gaat om AI-ondersteunde ontwikkeling.
Het grootste probleem bij ‘vibe-coding’ is dat veel risico’s niet meteen aan het licht komen. Een functie kan er afgewerkt uitzien, een snelle test doorstaan en toch rommelige logica, zwakke beveiliging, een slechte structuur of afhankelijkheden verbergen die niemand heeft gecontroleerd. Dat is natuurlijk niet altijd een ramp. Maar het is ook geen tovenarij. Het is code, en code heeft gevolgen.
In ons aparte artikel over dit onderwerp gaan we veel dieper in op de beveiligingsaspecten ervan: beveiligingskwetsbaarheden in Vibe Coding. Laten we ons hier eens richten op het grotere geheel: wat kan er misgaan als door AI gegenereerde code onderdeel wordt van een echt product?.
AI kan snel code schrijven. Heel snel. Soms zelfs te snel voor zijn eigen bestwil.
Wanneer je met prompts werkt, kan elk nieuw verzoek tot enigszins verschillende patronen leiden. De ene functie kan de ene structuur gebruiken, een andere functie kan hetzelfde probleem op een totaal andere manier oplossen, en weer een derde kan een “creatieve” snelkoppeling bedenken waar niemand om heeft gevraagd.
In eerste instantie lijkt dit misschien niet zo belangrijk. De app werkt, de demo ziet er goed uit, iedereen is tevreden.
Maar na een paar weken of maanden kan de codebase moeilijker te begrijpen worden: bestanden raken rommelig, logica wordt herhaald en de naamgeving is inconsistent. Eenvoudige wijzigingen kosten meer tijd omdat niemand helemaal zeker weet wat van wat afhankelijk is.
Dat is technische schuld: niet altijd defecte code, maar code die elke volgende stap lastiger maakt.
Bij traditionele codering zorgen teams hier meestal voor door middel van architectuurregels, codebeoordelingen, gezamenlijke standaarden en refactoring. Bij vibe-codering heb je die zaken juist nog harder nodig — want de AI houdt je codebase niet automatisch netjes, alleen maar omdat je het vriendelijk vraagt.
Door AI gegenereerde code kan er heel overtuigend uitzien. Dat is juist een deel van het probleem.
Misschien laat het zich wel compileren. Misschien doorstaat het wel een basistest. Misschien wordt het zelfs geleverd met een zelfverzekerde uitleg die klinkt alsof die is geschreven door iemand die een heel dure hoodie draagt.
Maar “het ziet er goed uit” is niet hetzelfde als “het is goed”.”
AI kan randgevallen over het hoofd zien, validaties overslaan, onveilige logica gebruiken of code genereren die alleen werkt in het ideale scenario. En omdat de output er verzorgd uitziet, accepteren mensen deze mogelijk zonder deze grondig genoeg te controleren.
Dit is riskant voor ontwikkelaars, maar nog riskanter voor oprichters of teams zonder technische achtergrond die ‘vibe coding’ gebruiken om snel iets op te bouwen. Als niemand de code grondig controleert, kunnen kleine fouten rechtstreeks in de productie terechtkomen.
AI is goed in het opvolgen van instructies. Het is echter niet zo goed in het doorgronden van je hele bedrijf.
Het kent niet automatisch uw nalevingsregels, verouderde systemen, uitzonderlijke klantgevallen, interne workflows of productplannen voor de lange termijn. Tenzij u het de juiste context geeft, vult het de leemtes zelf in. En juist wanneer AI die leemtes opvult, kan het vreemd gaan.
Zo kan het bijvoorbeeld een betalingsstroom opzetten zonder rekening te houden met de logica achter terugbetalingen. Of een systeem voor gebruikersrollen bouwen dat wel werkt voor drie testaccounts, maar faalt wanneer de rollen voor verkoop, ondersteuning, administratie en partners allemaal verschillende rechten nodig hebben. Of een databasestructuur genereren die prima is voor een prototype, maar een ramp wordt zodra er echte gebruikers en echte gegevens bijkomen.
AI-tools halen vaak pakketten, bibliotheken en installatie-instructies binnen om de code te laten werken. Handig? Ja. Altijd veilig? Niet echt.
Een door AI gegenereerd project kan verouderde afhankelijkheden, overbodige pakketten of bibliotheken bevatten die het team nooit heeft gecontroleerd. In sommige gevallen kan AI zelfs pakketnamen voorstellen die niet bestaan of die niet overeenkomen met wat je dacht te installeren. Heel leuk. Heel normaal. Precies wat iedereen wilde.
De configuratie is een ander zwak punt.
Een op vibe gebaseerde app kan lokaal draaien en toch ernstige configuratieproblemen vertonen: blootgestelde omgevingsvariabelen, zwakke machtigingen, openbaar toegankelijke beheerderspaneel, open databases, gebrekkige logboekregistratie of geheime gegevens die zich op plaatsen bevinden waar ze absoluut niet thuishoren.
Deze problemen vallen vaak niet op, omdat ze de app niet altijd onbruikbaar maken. Alles kan gewoon blijven werken, terwijl er op de achtergrond stilletjes veiligheids- en onderhoudsrisico’s ontstaan.
Daarom zijn afhankelijkheidscontroles, omgevingsbeoordelingen en een veilige configuratie geen optie. Zeker niet als de app verder gaat dan een demo.
Er is nog een risico dat op het eerste gezicht saai klinkt, maar al snel heel reëel wordt: eigendom.
Wie is verantwoordelijk voor door AI gegenereerde code? Wie controleert deze? Wie keurt deze goed? Wie documenteert deze? Wie lost problemen op als er iets misgaat?
Als het antwoord luidt: “Nou, de AI heeft het geschreven”, dan gefeliciteerd: je hebt nu een bestuursprobleem.
Teams die met ‘vibe coding’ werken, hebben duidelijke regels nodig. Zo moet elke door AI gegenereerde functie bijvoorbeeld een codereview ondergaan. Wijzigingen die van belang zijn voor de beveiliging moeten zorgvuldiger worden gecontroleerd. Afhankelijkheden moeten worden goedgekeurd. Tests moeten verplicht zijn. Documentatie mag niet worden overgeslagen, alleen maar omdat de functie binnen 15 minuten tot stand is gekomen.
Dit klinkt misschien minder spannend dan het bedenken van een app tijdens een kopje koffie, maar het is precies wat het verschil maakt tussen een nuttige, door AI ondersteunde workflow en een toekomstig opruimproject.
Het is noch “AI voor alles gebruiken”, noch “AI negeren en alles handmatig blijven doen”.”
Dat zou te makkelijk zijn. En verdacht netjes.
In de praktijk hangt de juiste aanpak af van wat je aan het bouwen bent, hoe risicovol het is, hoe snel je moet handelen en hoe lang het product bedoeld is om mee te gaan. Een prototype dat in een weekend wordt gemaakt, een fintech-platform en een interne rapportagetool moeten niet op dezelfde manier worden gebouwd.
In plaats van je af te vragen of “vibe-codering” of traditionele codering ‘beter’ is, kun je je beter afvragen: wat heeft dit project op dit moment eigenlijk nodig?
Vibe-coderen werkt het beste wanneer snelheid belangrijker is dan perfectie. Dit is waar vibe-coderen echt tot zijn recht komt:
In principe is het handig als je snel iets wilt leren.
Misschien werkt het idee wel. Misschien vinden gebruikers het vreselijk. Misschien wordt het hele idee na één vergadering alweer overboord gegooid. Dat is prima. Met ‘vibe coding’ kom je sneller en goedkoper tot dat antwoord.
Traditionele ontwikkeling verdwijnt niet zomaar. Het spijt me voor iedereen die zit te wachten op “één prompt = een compleet bedrijfsplatform”. Zo ver zijn we nog niet.
Wanneer het product complex is, bedrijfskritisch of aan reële risico’s blootstaat, blijft traditionele programmeertechniek nog steeds van groot belang. Ontwikkelaars moeten de architectuur begrijpen, de logica beheersen, integraties plannen, de beveiliging controleren en ervoor zorgen dat het systeem kan meegroeien zonder dat het een peperdure puzzel wordt.
Dit is met name belangrijk voor:
Bij traditionele ontwikkeling hebben teams meer zeggenschap over dat antwoord. Het biedt structuur: architectuurplanning, codestandaarden, testen, kwaliteitsborging, DevOps, documentatie, beveiligingsbeoordeling en verantwoordelijkheid op de lange termijn.
Ja, in het begin gaat het wat trager. Maar traag is niet altijd slecht. Soms betekent traag juist dat er daadwerkelijk is nagedacht over wat er gebeurt als het product 100.000 gebruikers heeft, verbinding maakt met vijf externe systemen of een beveiligingsaudit moet doorstaan.
Heel vervelend. Maar wel heel nodig.
De allerbeste werkwijze in 2026 is meestal noch puur ‘vibe-coderen’, noch ouderwets handmatig coderen. Het is AI-ondersteunde ontwikkeling: ingenieurs gebruiken AI als hulpmiddel, maar zij blijven verantwoordelijk voor de architectuur, de logica, het testen, de beveiliging en de uiteindelijke beslissingen.
Een goede hybride workflow zou er als volgt uit kunnen zien:
Bij Innowise zien we AI bijvoorbeeld niet als vervanging voor technische discipline. We gebruiken het als een versnellingslaag bovenop degelijke architectuur, beoordeling, testen en beveiligingspraktijken. Ons doel is om sneller software te bouwen zonder dat we zes maanden later wakker worden in een codebase waar niemand nog iets mee te maken wil hebben.
Dit is waarschijnlijk de richting waarin het gaat:
Dus ja, AI zal meer code schrijven. Maar mensen zullen nog steeds moeten beslissen wat er gebouwd moet worden, waarom het op die manier moet werken en of het resultaat ook echt goed genoeg is.
Dat is het deel waar AI nog steeds niet op een intuïtieve manier mee om kan gaan.
Wij werken samen met bedrijven die AI willen inzetten bij de ontwikkeling zonder de controle te verliezen over kwaliteit, beveiliging en onderhoudbaarheid op de lange termijn. Soms betekent dat het beoordelen van een op gevoel geprogrammeerde MVP vóór de lancering. Soms betekent het het opschonen van een codebase die te snel is gegroeid. En soms betekent het het helpen van een team bij het opstellen van duidelijke regels voor hoe door AI gegenereerde code moet worden geschreven, gecontroleerd en uitgerold.
Dit zijn enkele voorbeelden hiervan:
Dus als je team al iets met AI heeft ontwikkeld, kan Innowise helpen om het te beoordelen, te beveiligen en er een product van te maken waarop je kunt vertrouwen.
Er is hier geen eenduidige winnaar. Vibe-codering is ideaal als je snel moet handelen, een idee wilt testen of iets wilt bouwen dat morgen alweer kan veranderen. Traditionele ontwikkeling is nog steeds de betere keuze wanneer het product veilig, schaalbaar en betrouwbaar moet zijn. De slimste teams kiezen niet voor altijd voor één van beide benaderingen — ze zetten AI in waar dat tijd bespaart en passen technische discipline toe waar fouten veel geld kosten.
Bij ‘vibe-coderen’ begin je met prompts. Je beschrijft wat je wilt, en de AI genereert de code. Bij traditioneel coderen schrijven en structureren ontwikkelaars de code zelf. Het belangrijkste verschil in de discussie tussen ‘vibe-coderen’ en traditioneel coderen is dus controle: vibe-coderen biedt snelheid, terwijl traditioneel coderen meer inzicht en zeggenschap biedt.
Ja, vooral als het product in productie gaat. AI kan helpen bij het schrijven van code, maar er moet nog steeds iemand zijn die kan beoordelen of die code veilig, logisch en schaalbaar is, en of deze daadwerkelijk doet wat het bedrijf nodig heeft. Zonder programmeerkennis is het gemakkelijk om iets te accepteren dat er op het eerste gezicht goed uitziet, maar later niet meer werkt.
Ja, maar het is geen tovenarij. Een betere prompt kan zorgen voor een beter resultaat, een duidelijkere structuur en minder vreemde verrassingen. Maar zelfs een perfecte prompt is geen vervanging voor codereview, testen of beveiligingscontroles. Prompts helpen. Ze nemen niet de hele verantwoordelijkheid voor het product op zich.
Niet geschikt voor serieuze software. Met Vibe Coding kunnen niet-technische teams prototypes bouwen en kunnen ontwikkelaars sneller werken, maar het is geen vervanging voor het technische inzicht van een ontwikkelaar. Ontwikkelaars blijven onmisbaar voor de architectuur, het opsporen van fouten, beveiliging, prestaties, integraties en al die lastige details die AI vaak over het hoofd ziet.
De belangrijkste risico’s van door AI gegenereerde code zijn zwakke beveiliging, rommelige logica, onveilige afhankelijkheden, blootgestelde vertrouwelijke gegevens, een slechte architectuur en technische schuld. Het lastige is dat de code mogelijk nog steeds werkt, waardoor het probleem niet altijd meteen duidelijk is. Dit is een van de belangrijkste punten in de discussie over de voor- en nadelen van vibe-codering versus traditionele codering: snelheid is nuttig, maar alleen als de code goed wordt gecontroleerd, getest en beveiligd.
Oprichters, start-ups, productteams, ontwerpers en interne teams kunnen er veel baat bij hebben wanneer ze ideeën snel moeten testen. Ook ontwikkelaars kunnen het gebruiken om repetitief werk te versnellen. Het is vooral handig voor prototypes, MVP-experimenten, demo’s en interne tools waarbij snel leren belangrijker is dan het bouwen van de definitieve versie.
Soms wel, maar niet zonder grondige beoordeling. Functies die op basis van sfeer zijn gecodeerd, moeten worden gecontroleerd, getest, beveiligd en vaak herzien voordat ze in productie worden genomen. Het is prima als uitgangspunt. Het mag niet worden behandeld als: “Laten we het maar uitbrengen omdat de AI dat zegt.”.
Ja, en dat is meestal de beste aanpak. AI kan helpen bij conceptversies, standaardteksten, tests, documentatie en snelle experimenten. Bij traditionele ontwikkeling blijven de belangrijke aspecten onder controle: architectuur, beveiliging, bedrijfslogica, prestaties en onderhoudbaarheid op de lange termijn.
Hoofd Big Data
Philip bouwt data-infrastructuren die helderheid verschaffen. Hij richt zich op het “waarom” achter de gegevens en ontwerpt systemen die enorme volumes verwerken tot bruikbare inzichten terwijl hij ervoor zorgt dat de technische visie scherp en doelgericht blijft.
