Ergens tussen ChatGPT, Copilot, Claude en Cursor gebeurde iets merkwaardigs. We weren als het ware in een digitaal AI wormgat ingetrokken. We begonnen meer tegen computers te praten dan tegen onze collega’s of geliefden. Algoritmes die door mensen geprogrammeerd waren begon zelf programmeren. De eerste liefde kende geen vragen. Tijdsbesparing, deadlines halen, doughnuts die niet vergeelden op de tafel.
Een applicatie waarvoor gisteren een developer, een architect, drie meetings en een sprintplanning nodig waren, verschenen plots na een paar goed gekozen zinnen op het scherm.
“Maak een portal.” Enter. “Voeg authenticatie toe.” Enter. “Hang er een database achter.”
Enter. “Deploy.” En kijk. Het werkt. Allemaal gerealiseerd met een abonnement van nog geen 25 Euro. Tig uren gespaard die alsnog in de eindafrekening bleven… AI. Fantastisch.
Tot na een tijd tijdens een overbodige SCRUM meeting iemand de vraag stelde:
Is onze huidige manier van developen eigenlijk een goed idee? Missen we niet een paar belangrijke schakels? De persoon kreeg enkel hoongelach. De blikken van hoe kan je zo AI dom zijn veroorzaakten de eerste publieke vernedering.
Toch was het de verstandigste vraag die iemand in maanden had gesteld. Want nadat het lachen was verstomd en de manager stelde dat iedereen recht van spreken had werd er een pleidooi gehouden die voorkwam dat het een eeuwig eetzaal verhaal werd met een hoge amusementsfactor.
De medewerker die nog had leren programmeren in Pascal had wel een ongelezen haalbaarheidsstudie gedaan. Die had zelfs de agenda niet gehaald. Het bedrijf moest de concurrentie bijbenen weet u wel.
Tijd voor de realiteit van efficiëntie, concentratie en serieuze praat. Toen de aanwezigen van e meeting niet langer naar de spectaculaire tijdswinst maar naar het werkelijke risicoprofiel begonnen te kijken, verscheen een heel ander verhaal.
De code was er sneller. Maar de aanwezige verantwoordelijkheid ten opzichte van regelgeving niet. De architectuur was sneller goedgekeurd. Maar niemand kon precies reconstrueren waarom bepaalde architecturale keuzes waren gemaakt.
Dependencies waren met één commando binnengekomen, maar niemand had bewust besloten dat ze vertrouwd mochten worden. Een model had stukken bedrijfscontext gezien zonder dat vooraf altijd duidelijk was welke data die context precies bevatte. Credentials gaven een agent toegang omdat dat nu eenmaal nodig was om “lekker door te kunnen werken”. Code reviews veranderden soms ongemerkt van begrijpen wat hier gebeurt in vluchtig bevestigen dat de output er aannemelijk uitzag.
En het meest verontrustende was misschien dat bijna alles gewoon leek te werken.
Dat was precies het probleem.
“Een systeem hoeft niet kapot te zijn om gevaarlijk te zijn. Soms moet het alleen lang genoeg probleemloos werken om iedereen te laten vergeten welke risico’s nooit gecontroleerd werden.”
De risicoanalyse die volgde, was daarom geen aanval op AI. Integendeel. AI had gedaan wat we ervan gevraagd hadden.
Snel programmeren. Alternatieven voorstellen. Code herschrijven. Tests genereren. Problemen oplossen. Nog een poging doen. En nog een. Nooit moe, nooit geïrriteerd, nooit klagen dat de sprint alweer te vol zat.
De ongemakkelijke conclusie was dat niet de machine haar rol verkeerd had begrepen.
Ieder lid van een ontwikkelings project team had zijn eigen rol verkeerd begrepen. Ze hadden snelheid aangezien voor volwassenheid. Autonomie voor governance. Een werkende demo voor engineeringbewijs. En zelfsturing voor de afwezigheid van sturing.
“We waren bijzonder goed geworden in het meten of werk bewoog. Veel minder goed in het bewijzen of vertrouwen gerechtvaardigd was.”
Het wormgat had één natuurwet veranderd Er was namelijk iets fundamenteels gebeurd. De afstand tussen intentie en consequentie was ingestort. Een idee kon bijna onmiddellijk code worden. Een goed idee dus ook. Maar helaas geldt dezelfde natuurwet voor slechte ideeën. Een verkeerde architecturale aanname kan nu razendsnel worden geïmplementeerd. Een onveilige dependency eveneens. Een ondoordachte datastroom ook. Een agent met te ruime privileges kan sneller handelen dan een menselijke collega ooit zou kunnen.
Laat ons even kijken welke neveneffekten AI AI wormgat al heeft.
De programmeur die zichzelf zag verdwijnen
Wie vandaag overweegt softwaredeveloper te worden, krijgt een vreemde boodschap voorgeschoteld. Enerzijds schreeuwt de wereld dat digitalisering, cybersecurity, data en artificiële intelligentie belangrijker worden dan ooit.
Anderzijds opent diezelfde student zijn nieuwsfeed en leest dat AI softwaredevelopers overbodig zal maken. Waarom nog jaren leren programmeren wanneer een taalmodel het in twintig seconden kan? Die redenering klinkt aannemelijk.
Ze is alleen gebaseerd op een achterhaald idee van wat een goede developer eigenlijk doet. Want als softwareontwikkeling voornamelijk bestaat uit het produceren van regels code, dan hebben we inderdaad een probleem.
AI produceert code verschrikkelijk snel. Maar software engineering was nooit uitsluitend het schrijven van code.
Het ging ook over begrijpen waarom iets gebouwd moet worden. Over requirements. Architectuur. Data. Identiteiten. Afhankelijkheden. Failure modes. Privacy. Security. Continuïteit. Onderhoudbaarheid.
En over dat ene bijna vergeten woord:
feasibility. Haalbaarheid!
Kunnen we dit bouwen?
Mogen we dit bouwen?
Moeten we dit bouwen?
En onder welke voorwaarden kunnen we het verantwoord bouwen?
Juist nu wanneer AI de kostprijs van het produceren van code ogenschijnlijk richting nul duwt, wordt het vermogen om die vragen te beantwoorden juist waardevoller.
De misbare developer is degene die enkel ongelooflijk snel geworden is
Daar zit een paradox. Een besef om alle energie in te zetten om het AI wormgat te vermijden.AI maakt een goede engineer potentieel veel productiever.++
Maar AI kan iemand die onvoldoende begrijpt wat hij aan het bouwen is óók veel sneller onbetrouwbare software laten produceren. Helaas beginnen inmiddels de cijfers die ongemakkelijke waarheid te ondersteunen.
In de Stack Overflow Developer Survey 2025 gebruikt of overweegt 84% van de respondenten AI-tools voor development. Maar slechts 33% vertrouwt de accuraatheid ervan, terwijl 46% die actief wantrouwt. Slechts ongeveer 3% zegt de output sterk te vertrouwen.
Nog interessanter: 66% noemt AI-oplossingen die bijna juist, maar nét niet juist zijn als frustratie. En 45% ervaart dat het debuggen van AI-generated code meer tijd kan kosten.
Dat is geen argument tégen AI. Het is een argument vóór engineering.
Recent veiligheidsonderzoek maakt het nog scherper. In een studie uit 2026 werden twaalf agentconfiguraties getest op 186 realistische software-engineeringtaken waarin security relevant was. In één gerapporteerde configuratie was 57% van de oplossingen functioneel correct, maar slechts 11,8% veilig. Dat ene benchmarkresultaat mag niet worden veralgemeend naar alle AI-code, maar het illustreert wel een fundamenteel probleem:
“Het werkt” en “het is veilig” zijn twee verschillende eigenschappen.
Een andere recente studie vond 75 bevestigde securitybevindingen in twaalf door een coding agent gegenereerde webapplicaties. Expliciete security-instructies in de prompt verbeterden de resultaten aanzienlijk, maar zelfs daar werd de ernstigste resterende fout pas bij manueel testen ontdekt.
Maar is er geen andere nieuwe beweging die kan redden, zoals het hippe fenomeen vibe coding. Helaas botst zelfs vibe coding tegen real life needed development en dus op de echte wereld.
De managementmythe van het herprogrammeren van de luie developer door de introductie van zelfsturing
Zelfsturing. Het woord klinkt fantastisch.Geef mensen autonomie. Verwijder bureaucratie. Laat teams zelf bepalen hoe ze hun doel bereiken. En autonomie is waardevol. Developers noemen autonomie en vertrouwen om hun eigen werk te beheren zelfs als belangrijkste factor voor jobsatisfactie in de Stack Overflow-survey van 2025.
Maar autonomie zonder begrenzing is iets anders. Dat is geen zelfsturing. Dat komt enkel neer op het uitbesteden van governance.
Stel je onze stereotype developer voor. Cola links. Doos donuts rechts. Deadline vrijdag. Het management zegt: “Wij sturen op outcome. Jullie zijn zelforganiserend. Gebruik gerust AI.” Onze developer krijgt nu twee mogelijke routes.
Route één vraagt threat modelling, dataclassificatie, architecture review, secrets management, IAM, logging, dependency checks, tests en documentatie.
Route twee vraagt: “Claude, build me this.”
Welke route wint wanneer beide routes organisatorisch als gelijkwaardig worden behandeld en alleen snelheid wordt gemeten? Dat heeft weinig met luiheid te maken. Het systeem heeft eenvoudigweg de kortste weg beloond. Het management heeft geen autonomie ontworpen. Het Management heeft de vangrails verwijderd.
De Europese Cybersecurity regelgeving heeft slecht nieuws voor dat management
En hier wordt het even het moment om niet naar je AI prompt te grijpen als beleidsvoerder. De wetgeving legt verantwoordelijkheid namelijk nadrukkelijk niet bij de developer of CISO.
Artikel 20 verlangt dat bestuursorganen van essentiële en belangrijke entiteiten de cybersecurity-risicobeheersmaatregelen goedkeuren, toezien op de uitvoering ervan en — binnen de toepasselijke nationale regels — verantwoordelijk kunnen worden gehouden voor inbreuken op artikel 21. Bestuursleden moeten bovendien cybersecuritytraining volgen.
En artikel 21 leest bijna als een waarschuwing tegen bijvoorbeeld naïef vibe coding.
Organisaties moeten passende technische, operationele én organisatorische maatregelen nemen. De richtlijn noemt onder andere risicoanalyse, incidentafhandeling, continuïteit, supply-chain security, veilige ontwikkeling en onderhoud van systemen, vulnerability handling, beoordeling van de effectiviteit van maatregelen, cyberhygiëne, opleiding, cryptografie, access control en asset management.
Hedendaagse klanten kijken bovendien nadrukkelijk naar hun software leveranciers en hun secure development procedures.
En in de overwegingen bij de richtlijn verschijnt iets interessants: Zero Trust.
Zero-trustprincipes, netwerksegmentatie, identity- en accessmanagement, cyberhygiëne en awareness worden expliciet genoemd als praktijken die organisaties moeten toepassen.
Dus nee:
“Onze developer heeft dat met een AI-agent gebouwd” is geen securitymodel.
“Onze teams zijn zelfsturend” is geen risk-control. En “de leverancier zegt dat zijn model veilig is” is geen threat assessment.
Van Zero Trust naar HarmonyQ Zero Trust Development
Daarom hebben we misschien een nieuwe engineeringdiscipline nodig.
Geen verbod op vibe coding. Geen nostalgische terugkeer naar Notepad++, handgeschreven SQL en programmeurs die Stack Overflow-antwoorden overschrijven.
Gebruik die AI. Gebruik er gecontroleerd veel van.
Laat haar boilerplate produceren. Laat haar refactoren. Laat haar tests voorstellen. Laat haar prototypes maken. Laat haar documentatie helpen schrijven. Laat haar alternatieven onderzoeken.
Maar maak één afspraak: gegenereerde code verdient exact nul impliciet vertrouwen.
Dat is geen radicale gedachte. NIST trekt Zero Trust inmiddels expliciet door naar AI-enabled DevSecOps. AI-componenten en agents moeten identiteiten krijgen; toegang tot repositories, buildsystemen, registries, modellen, databronnen, API’s en infrastructuur moet continu geauthenticeerd en geautoriseerd worden volgens least privilege. NIST noemt daarnaast threat modelling, constrained guardrails, monitoring, auditing en human-in-the-loop voor beslissingen met hoger risico.
OWASP waarschuwt ondertussen voor Excessive Agency: AI-systemen die te veel functionaliteit, te veel permissions of te veel autonomie krijgen.
Dat brengt ons bij:
ZT9 — Zero Trust Development in negen gates Niet negen lagen bureaucratie.
Negen momenten waarop software moet bewijzen dat ze de volgende stap verdient.
ZT1 — Intent
Waarom bouwen we dit?
Geen AI begint aan productiecode voordat het gewenste gedrag, de eigenaar, scope, kritikaliteit en acceptatiecriteria begrijpelijk zijn.
De eerste securitycontrole is geen firewall.
Het is een heldere bedoeling.
ZT2 — Feasibility
Kunnen, mogen en moeten we dit bouwen?
Hier komt het vergeten gedachtengoed terug. De antwooren die niet mogen ontbreken op:
Technische haalbaarheid. Juridische haalbaarheid. Security. Privacy. Kosten. Data residency.
Operationele consequenties. Vendor lock-in. Recovery.
En de vraag die vóór de eerste prompt gesteld moet worden: wat gebeurt er als dit systeem fout gaat?
ZT3 — Data
Welke informatie mag waarheen?
Classificeer data voordat een model ze ziet. PII? Intellectuele eigendom? Credentials? Customer data? Source code? Secrets?
DLP hoort niet achter de AI te staan om achteraf de brokstukken op te ruimen. DLP staat vóór de prompt.
ZT4 — Identity
Wie doet dit eigenlijk?
Een mens heeft een identiteit. Een service heeft een identiteit. Dus een AI-agent ook.
Geen mysterieuze machinegebruiker met gedeelde credentials en permanente tokens. Iedere actor identificeerbaar. Iedere actie attributable.
ZT5 — Privilege
Wat mag die identiteit doen?
Een coding agent die code moet lezen, hoeft geen productieomgeving te kunnen verwijderen.
Een agent die tests uitvoert, heeft geen customer database nodig.
Least privilege wordt extreem belangrijk wanneer software niet alleen antwoorden genereert maar zelfstandig tools kan bedienen.
OWASP’s waarschuwing voor excessive agency komt precies hier binnen.
ZT6 — Supply Chain & Code
Waar komt dit vandaan?
Packages. Libraries. Containers. Models. MCP’s. Plugins. Generated code. Training dependencies. Artifacts. Alles heeft provenance nodig.
Alles kan een dependency worden. Alles kan dus een aanvalspad worden.
Dat past niet toevallig rechtstreeks bij NIS2: artikel 21 noemt zowel supply-chain security als beveiliging bij acquisition, development en maintenance.
ZT7 — Verification
Bewijs het.
Niet: “de AI zegt dat het veilig is.”
Tests. SAST. DAST waar relevant. Secrets scanning. Dependency scanning. Policy-as-code. Securitytests. Human review waar de impact dat vereist.
En vooral:
AI mag zijn eigen examen niet als enige examinator beoordelen.
NIST zegt inmiddels expliciet dat AI-generated content door mensen moet worden gemonitord en gevalideerd en dat verifieerbare processen nodig zijn om accuracy en trustworthiness te controleren.
ZT8 — Deployment
Wie geeft toestemming om de volgende trust boundary over te steken?
Een prototype is geen productie en een passing unit test is geen deployment approval.
Signed artifacts. Controlled CI/CD. Segregation of duties waar nodig. Policy gates. Rollback.
Geen laptop-naar-productie omdat de demo er fantastisch uitzag.
ZT9 — Operations
En uiteindelijk: vertrouw zelfs goedgekeurde software niet voor eeuwig.
Observeer. Log. Detecteer. Herbeoordeel. Patch. Revoke. Isolate. Recover. Leer.
Zero Trust eindigt niet bij deployment. Daar begint het pas echt.
Limiteer tokens. Niet creativiteit.
De enige oplossing die haalbaar is om het model van zelfsturing te repareren. We hoeven developers niet opnieuw onder een command-and-controlmanagement te plaatsen. Geef ze enorme creatieve vrijheid, maar binnen expliciete grenzen.
Limit tokens.
Limit privileges.
Limit data exposure.
Limit blast radius.
Never limit engineering judgement.
Een tokenbudget voorkomt eindeloze agent-loops en houdt kosten beheersbaar.
Maar een tokenlimiet is geen securitycontrol. Een AI-agent met 2.000 tokens en administratorrechten op productie is veel gevaarlijker dan eentje met 200.000 tokens in een gecontroleerde sandbox. Stuur daarom niet primair op hoe een developer zijn oplossing bereikt. Stuur op de trust boundaries die hij niet zonder bewijs mag passeren.
Dat is bounded autonomy.
Management bepaalt risk appetite, wettelijke grenzen en trust boundaries. Engineering bepaalt daarbinnen creatief de oplossing. AI versnelt de uitvoering.
ZT9 bepaalt of het resultaat door mag naar de volgende zone.
Autonomie binnen bewijsbare grenzen.
Misschien moeten we het beroep dus helemaal niet redden
Misschien moeten we vooral stoppen het verkeerde beroep te verdedigen. Als “developer” betekent: iemand die sneller syntax kan produceren dan een computer, dan ziet de toekomst er inderdaad ongemakkelijk uit. Maar misschien was dat nooit het echte vak. De developer van morgen is degene die tegenover zijn management kan zitten en kan zeggen:
Ik begrijp wat jullie willen bereiken.
Ik weet welke data daarvoor beweegt.
Ik weet welke identities toegang krijgen.
Ik weet waar onze trust boundaries liggen.
Ik weet welke onderdelen AI heeft gegenereerd.
Ik weet welke aannames we niet vertrouwen.
Ik kan aantonen welke controles zijn uitgevoerd.
Ik weet wat de blast radius is als het fout gaat.
En ik kan uitleggen waarom deze software verantwoord naar productie mag.
Dat beroep verdwijnt niet omdat AI kan programmeren. Dat beroep wordt juist belangrijker omdat AI kan programmeren.
En misschien moeten hogescholen dát gaan vertellen
Aan de achttienjarige die vandaag twijfelt of softwareontwikkeling nog een toekomst heeft, moeten we niet beloven dat AI wel zal overwaaien. Helaas dat zal niet het geval zijn.
We moeten ook niet proberen hem sneller code te leren typen dan een taalmodel.
We moeten hem iets veel ambitieuzers leren. Laat studenten AI vanaf het begin gebruiken. Maar laat iedere gegenereerde applicatie vervolgens door ZT9 lopen.
AI en zelfsturing en hypes als Vibe coding zijn niet de vijand. Het gevaar door het digitale wormgat te worden opgezogen ontstaat pas wanneer we snelheid verwarren met vertrouwen en experimenteren met engineering. AI is daarom ook geen reden om developers af te schaffen. Integendeel: hoe eenvoudiger het wordt om software te produceren, hoe belangrijker de mensen worden die begrijpen wat die software doet, welke data ze raakt, welke risico’s ze introduceert en waarom we haar uiteindelijk zouden mogen vertrouwen. AI verlaagt de drempel om code te maken, maar verhoogt daarmee tegelijkertijd de lat voor degene die zich engineer wil noemen.
Hetzelfde geldt voor zelfsturing. Er is niets mis met developers die vrijheid krijgen om oplossingen te zoeken, technologie te kiezen en samen met AI sneller te experimenteren. Maar vrijheid zonder duidelijke grenzen is geen volwassen vorm van autonomie. Onbegrensde zelfsturing is uiteindelijk een managementfout. Een organisatie kan verantwoordelijkheid niet naar beneden delegeren en vervolgens verbaasd zijn wanneer snelheid, deadlines en gemak het winnen van security, privacy en gezond technisch verstand. Goed management schrijft niet voor welke toets een developer moet indrukken, maar maakt wel duidelijk welke grenzen nooit zonder bewijs mogen worden overschreden.
Daarom hoort Zero Trust niet langer alleen thuis bij firewalls, endpoints, netwerken en identities. Zodra machines zelf code schrijven, libraries selecteren, tools bedienen, data verwerken en beslissingen voorbereiden, moet diezelfde gedachte tot diep in de softwarefabriek doordringen. Vertrouwen mag niet ontstaan omdat een model overtuigend antwoordt, omdat de tests groen kleuren of omdat een applicatie tijdens de demo keurig doet wat ervan verwacht wordt. Vertrouwen moet verdiend worden, telkens opnieuw, van de eerste intentie tot de laatste handeling in productie. Dat is uiteindelijk de essentie van ZT9: niet negen nieuwe bureaucratische hindernissen, maar negen momenten waarop snelheid even plaats moet maken voor de vraag of de volgende stap verantwoord is.
Misschien kan de filosofie daarom in drie regels worden samengevat: Vibe to explore. Engineer to deploy. Zero Trust everything in between. Laat AI de ruimte voor creativiteit vergroten. Laat haar prototypes bouwen, alternatieven bedenken, code schrijven, testen en opnieuw beginnen. Maar laat engineering bepalen wanneer een experiment klaar is om werkelijkheid te worden.
Wanneer de volgende generatie developer dan vraagt of het nog zin heeft om dit vak te leren nu AI zelf kan programmeren, moeten we vooral niet antwoorden: “Maak je geen zorgen, AI kan het nog niet goed genoeg.” Dat is een geruststelling met een houdbaarheidsdatum. Misschien kan AI het over enkele jaren namelijk verbazingwekkend goed. Het veel sterkere antwoord is daarom: leer vooral méér dan coderen.
Leer begrijpen hoe systemen werkelijk in elkaar grijpen en hoe data erdoorheen stroomt. Leer herkennen waar risico ontstaat voordat het een incident wordt. Begrijp architectuur, privacy, regelgeving en cybersecurity. Leer denken zoals degene die een systeem wil bouwen, maar af en toe ook zoals degene die het wil misbruiken. Leer AI sturen wanneer ze je versnelt en haar wantrouwen wanneer haar zelfvertrouwen groter wordt dan haar gelijk. Want in een wereld waarin bijna iedereen met een paar goede prompts software kan laten ontstaan, zit de waarde van de engineer steeds minder in het produceren van de volgende regel code en steeds meer in het begrijpen van de consequenties ervan.
Misschien is dat wel de werkelijke redding van het beroep. Niet proberen sneller te programmeren dan de machine, maar iets ontwikkelen wat veel moeilijker te automatiseren is: engineering judgement. Dat bijna hinderlijke, professioneel paranoïde cyberinstinct dat ervoor zorgt dat je midden in een fantastische demo, terwijl iedereen enthousiast naar het scherm kijkt en de applicatie precies lijkt te doen wat ze moet doen, toch nog één vervelende vraag durft te stellen:
Wacht eens even. Wie vertrouwt hier eigenlijk wie?
Dan wordt het niet : AI AI… OEI OEI Het wormgat wordt gemeden. De reis gaat verder met beter werk, betere kwantiteit en respect voor waarden van de mens als individu, en donuts die niet vergelen.
