Onze insights
16/4/2026

Vibecoding / agentic engineering vanuit technologisch perspectief: wat kan er nu mislopen?

Hanne De Kesel
Door Hanne De Kesel
·
April 16, 2026

Dankzij tools als Claude Code, GitHub Copilot (nu met agentic mode), Cursor, Lovable, Bolt en Replit kan zowat iedereen met een idee voor een applicatie die ook echt bouwen, en dat in een paar uur tijd. Maar is het echt zo eenvoudig? In onze vorige blog over vibecoding voor marketeers zetten we de kansen en valkuilen vanuit marketingperspectief op een rij: rommelige code, tokenlimieten, geen CMS, beperkte SEO en het ontbreken van een strategisch fundament.

In dit artikel bekijken we de innovatie vanuit technologisch perspectief: wat gebeurt er als mensen zonder technische achtergrond software bouwen die effectief in productie gaat?

De technologie evolueert razendsnel. Karpathy, die de term ‘vibecoding’ een jaar geleden bedacht, geeft nu aan dat die term de volledige lading niet meer dekt. Hij pleit intussen voor “agentic engineering” als een nauwkeurigere omschrijving. Een teken dat het domein volwassen wordt, maar ook complexer.

Die indrukwekkende evolutie zien we ook in hoe de technologie gebruikt wordt. Platformen als Vercel en Netlify zagen hun gebruikersaantallen in 2025 fors stijgen, vooral dankzij vibecoders. Grote techbedrijven als Google en Microsoft genereren nu al meer dan 20% van hun code met AI. Gartner voorspelt dat tegen 2028 liefst 75% van de software engineers in grote ondernemingen AI-codeassistenten zal gebruiken, tegenover minder dan 10% begin 2023.

Vibecoding maakte de technologie om applicaties te bouwen toegankelijk voor iedereen. Maar terwijl we die technologische democratisering toejuichen, staan we ook graag even stil bij de risico's. Wat kan er nu mislopen?

Knelpunt 1: beveiliging als grootste zorg

Het GenAI Code Security Report 2025 van Veracode, gebaseerd op meer dan 100 LLM's en 80 programmeeropdrachten, stelt vast dat 45% van de door AI gegenereerde code voor beveiligingslekken zorgt. In bijna de helft van de gevallen kiezen de modellen, bewust of onbewust, voor een onveilige methode. Op zich is dat niet onlogisch: LLM's die getraind zijn op publieke coderepositories leren zowel veilige technieken als wijdverspreide kwetsbaarheden aan. “Garbage In, Gospel Out”: de modellen leveren misschien functioneel correcte code af, maar de beveiligingskwaliteit blijft consequent achter.

1.1 Authenticatie en identiteitsbeheer

AI-modellen bouwen standaard een gebruikersbeheersysteem, maar doen dat zonder de juiste best practices toe te passen. Ze kennen het concept van een Identity Provider (IdP), maar passen het zelden proactief toe.

Een degelijke IdP zoals Auth0, Cognito of Azure Entra ID biedt out-of-the-box: MFA, bescherming tegen brute force-aanvallen, anomaliedetectie, tokenbeheer en compliance (SOC2, GDPR). Dat bouw je niet na met een paar prompts.

Wat kan er nu mislopen? Een concreet voorbeeld: De startup Enrichlead, volledig gebouwd met Cursor, zag hoe AI alle beveiligingslogica client-side plaatste. Binnen 72 uur ontdekten gebruikers dat één aangepaste waarde in de browserconsole volledige, gratis toegang gaf tot alle betalende functies. De oprichter kon de 15.000 regels gegenereerde code niet doorlichten.

1.2 OWASP Top 10, nu in het kwadraat

Cross-site scripting (XSS), SQL injection, broken authentication, security misconfiguration… het zijn geen nieuwe risico's. Ze staan al jaren in de OWASP Top 10. Jammer genoeg zorgt vibecoding ervoor dat ze op massale schaal opduiken. Onderzoek toont aan dat LLM's code in respectievelijk 86% en 88% van de gevallen niet beveiligen tegen Cross-Site Scripting en Log Injection, twee van de meest voorkomende aanvalsvectoren. Een applicatie die publiek bereikbaar is zonder WAF (Web Application Firewall) of rate limiting, is een open uitnodiging voor hackers.

1.3 De kost van publiek draaiende AI-agents

AI-agents of backendservices die publiek gehost worden zonder authenticatie of toegangsbeperkingen, zijn voor iedereen toegankelijk. Vaak weet een vibecoder niet eens dat zijn applicatie publiek bereikbaar is. Token- en rekenkosten kunnen daardoor exponentieel oplopen. In de marketingversie van deze blog hadden we het al over tokenlimieten, maar hier krijgt dat een heel andere dimensie. Niet alleen het gesprek met de AI, ook de draaiende applicatie zelf jaagt er budget door.

1.4 Hardcoded credentials en blootgestelde API-keys

Vibecoding kiest er vaak voor om API-keys, tokens of databasecredentials rechtstreeks in de code te hardcoden. Bij frontend-only applicaties die rechtstreeks verbinden met Supabase of vergelijkbare backend-as-a-service-platformen, zijn de databasesleutels gewoon leesbaar in de browser. Wie een beetje overweg kan met developer tools, kan die sleutels kopiëren en vervolgens willekeurige queries uitvoeren, tot het verwijderen van volledige tabellen toe.

Wat kan er nu mislopen? Een concreet voorbeeld: Moltbook, een AI-gedreven sociaal netwerk dat volledig via vibecoding gebouwd werd, had een verkeerd geconfigureerde Supabase-database die 1,5 miljoen API-keys en 35.000 e-mailadressen publiek blootlegde. Dat was geen gesofisticeerde hack: het lek was simpelweg het gevolg van snel bouwen zonder beveiligingsfundament.

1.5 Juridisch kader: de EU Cyber Resilience Act

De EU Cyber Resilience Act legt fabrikanten van softwareproducten secure-by-design-principes, verplichte risicoanalyses en minstens vijf jaar beveiligingsupdates op. Vibecoding zonder oog daarvoor is niet alleen technisch riskant, maar ook juridisch kwetsbaar. De CRA hanteert drie boeteniveaus: de hoogste boete voor inbreuken op de essentiële cyberbeveiligingseisen, gevolgd door inbreuken op documentatie en conformiteit, en ten slotte misleidende informatie. Het uiteindelijke boetebedrag hangt af van de ernst, de duur, herhaling en de omvang van het bedrijf.

Knelpunt 2: architectuur en hosting

2.1 Monoliet of microservices?

AI genereert standaard een monolithische applicatiestructuur (alles in één blok), tenzij je expliciet iets anders vraagt. Voor kleine projecten is dat niet per se fout, maar het schaalt dramatisch slecht. Zonder inzicht in het verschil tussen een monoliet en microservices neem je impliciet architectuurbeslissingen zonder het te beseffen, beslissingen met een grote impact op performantie, onderhoudbaarheid en hostingkosten. Voor bedrijfskritische applicaties kan dat bijzonder zware gevolgen hebben.

2.2 Kubernetes is geen speelgoed

Bij vibecoding worden automatisch Dockerfiles of zelfs Kubernetes-configuraties gegenereerd als standaard deploymentoutput, zonder enige uitleg of context. Kubernetes is een extreem krachtig, maar ook extreem complex platform voor containerorkestratie, dat normaal op enterpriseschaal beheerd wordt door gespecialiseerde teams. De tool spuwt gewoon infrastructuurcode uit, zonder rekening te houden met de operationele complexiteit (kosten, overhead, netwerkconfiguratie, ingress management, secrets management, auto-scaling, monitoring, …). Die complexiteit gaat de pet van de vibecoder ver te boven, maar heeft wel een directe impact op de factuur en op de beschikbaarheid van de applicatie.

2.3 Vendor lock-in en risico's in de supply chain

Vibecoding vergroot het risico in de supply chain: AI-assistenten raden soms kwetsbare third-party libraries aan of introduceren code met restrictieve licenties, risico's die een vibecoder niet opmerkt. Onderzoek toont bovendien aan dat 5% van de commercieel door AI gegenereerde code onbestaande pakketnamen bevat (“hallucinated packages”). Aanvallers registreren die pakketnamen en voorzien ze van malware, klaar om automatisch geïnstalleerd te worden bij de volgende dependency-update.

2.4 Technische schuld aan machinesnelheid

Klassieke technische schuld ontstaat wanneer developers snelheid voorrang geven op onderhoud. Vibecoding Debt is hetzelfde fenomeen aan AI-snelheid: kwetsbaarheden zitten er vanaf dag één ingebakken, in codebases die niemand nog kan lezen of auditen.

Wat kan er nu mislopen? Een concreet voorbeeld: een SQL injection-kwetsbaarheid kan zich verstoppen in een data access layer die met vibecoding gebouwd werd. De AI gebruikte bijvoorbeeld een ORM, maar voegde op 3 plaatsen raw queries toe “voor de performantie”. Die queries gebruiken stringconcatenatie in plaats van geparametriseerde statements. Tijdens een code review valt dat niet op, omdat de code er tussen 10.000 andere regels “normaal” uitziet. Twee jaar later maken aanvallers de database leeg. Post-mortem: “We wisten niet eens dat die queries er stonden.”

Wat wel werkt: AI gedreven door expertise

Laten we vooral niet blijven hangen in worstcasescenario's. De kracht van vibecoding of agentic engineering zit erin dat het de drempel om te bouwen drastisch verlaagt. Wat vroeger weken of maanden duurde, kan nu in dagen of zelfs uren. Dat is geen bedreiging voor technologie, maar een uitnodiging om ze slimmer en efficiënter in te zetten.

Want waar code zonder fundament op drijfzand lijkt, kan je met de juiste principes, keuzes en begeleiding diezelfde snelheid omzetten in een hefboom voor innovatie. Hoe pakken wij dat aan?

Blueprints en herbruikbare componenten als fundament

Onze experts bouwen software op basis van een set beproefde bouwblokken en blueprints waarin de keuzes al bewust gemaakt zijn. Even snel, want we gebruiken de technologie van agentic engineering, maar vanuit jarenlange expertise.

Het verschil zit niet in de tools, maar in het fundament: veilige standaardinstellingen, architectuurkeuzes en infrastructuurstandaarden zitten al in onze blueprints en componenten. Wij leveren het kader, AI vult in. Het resultaat? De snelheid van vibecoding, maar zonder de risico's.

Expert-in-the-loop als principe

Karpathy waarschuwde al dat agents, als we niet opletten, gewoon “slop” genereren. Zijn conclusie: de belangrijkste taak van de developer verschuift van code schrijven naar code reviewen. Een beetje zoals bij een getalenteerde stagiair: ook zijn werk zet je toch niet zonder review in productie?

Een andere vaak gemaakte vergelijking: agentic coding met expertise is als industriële landbouw met zware machines. De machine (AI) maakt de boer niet overbodig, maar geeft hem exponentieel meer productiekracht, op voorwaarde dat hij de tractor weet te besturen.

We gebruiken AI als turbomotor, niet als automatische piloot. De architectuur, de beveiligingskeuzes en de hostingstrategie blijven mensenwerk, maar dan gevoed door expertise en ervaring.

Waar kunnen we helpen?

  • Architectuurreview en begeleiding. We kijken vanuit technisch perspectief mee, nog voor je begint. Welke stack? Welke hosting? Hoe zit het met authenticatie, dataopslag en API-beveiliging? Zo zorgen we van bij de start voor de juiste keuzes.
  • “Vibe better”-opleiding. Wil je zelf experimenteren met agentic engineering, maar mis je de achtergrond? We leren je hoe je AI goed aanstuurt met de juiste architecturale context en guardrails voor beveiliging, zodat wat je bouwt ook veilig en schaalbaar is.
  • Ondersteuning tijdens de vibetime. Heb je liever een partner die je begeleidt terwijl je bouwt? We helpen je de klassieke valkuilen te vermijden zolang ze nog goedkoop op te lossen zijn, in plaats van achteraf.
  • Van vibe naar robuust. Ben je al in vibecoding gedoken en loop je nu tegen een van de knelpunten hierboven aan? Wij helpen je verder. We nemen bestaande applicaties die met vibecoding gebouwd zijn over en maken er productieklare software van, met degelijke beveiliging, best practices voor hosting en onderhoudbare code.

Vibecoding en agentic engineering zijn blijvers. De vraag is niet of we deze tools moeten gebruiken, maar hoe we dat op een verantwoorde manier doen. Met de juiste expertise bouw je AI-gedreven ontwikkeling op een stevig fundament, niet op drijfzand zonder draagkracht.

Snel iets gebouwd dat nu ook in productie overeind moet blijven? Software veilig tot daar brengen, is precies wat onze Fly-fase doet.

Wil je snel én veilig bouwen? Wij helpen je het beste van twee werelden te combineren. Neem contact op.