Nog niet zo lang geleden concentreerde het gesprek over kunstmatige intelligentie in programmeren zich vooral op één vraag: zal AI programmeurs hun baan afnemen? In 2026 begint die vraag simpelweg achterhaald te raken. AI schrijft al code, maakt tests, analyseert repositories, stelt verbeteringen voor, bereidt pull requests voor, en steeds geavanceerdere agents kunnen hele reeksen taken uitvoeren zonder de developer stap voor stap handmatig te begeleiden.
Het probleem is dus veranderd.
We vragen niet meer alleen of AI kan programmeren.
We vragen wie verantwoordelijk is voor software die door AI is geprogrammeerd.
En dat is een veel belangrijkere vraag.
Coderen is sneller geworden. Het bouwen van goede software niet per se
Het is goed om bij één ding te beginnen: het heeft geen zin te doen alsof AI in programmeren een voorbijgaande trend is. Dat is het niet.
AI-tools dringen steeds dieper door in het dagelijkse proces van softwareontwikkeling. Van eenvoudige suggesties voor losse codefragmenten zijn we naar agents gegaan die grotere contexten van een project kunnen analyseren, meerdere bestanden aanpassen, tests draaien, reageren op fouten en wijzigingen voor menselijke verificatie klaarmaken. De markt ontwikkelt zich richting agentgebaseerd softwarecreatie, niet enkel klassieke autocomplete.
Dat is een enorme productiviteitsverandering.
Een ontwikkelaar hoeft niet elke codefragement meer vanaf nul te schrijven. Hij kan een taak aan AI toevertrouwen, een eerste implementatie ontvangen, deze testen, verbeteren en doorgaan naar het volgende probleem.
En precies hier ontstaat een paradox.
Hoe makkelijker het is om code te schrijven, hoe minder waarde het op zich heeft om alleen code te schrijven.
Tegelijk krijgt de vraag steeds meer waarde: wat moet er eigenlijk geschreven worden, hoe moet het werken en hoe controleer je of het op de juiste manier is gedaan?
Dat is het verschil tussen codegeneratie en software-engineering.
"Het werkt" is nog maar het begin
Elke developer kent de situatie waarin iets "werkt". Endpoint geeft antwoord. Formulier wordt verzonden. Record wordt opgeslagen in de database. Knop voert actie uit. Test slaagt. Je zou dus kunnen zeggen: klaar.
Maar goede software engineering begint juist op dat moment.
Want later komen de vragen:
- Is de oplossing veilig?
- Werkt het bij hoge belasting?
- Wat gebeurt er als een gebruiker onverwachte gegevens invoert?
- Gaat het om met fouten?
- Is het makkelijk uitbreidbaar?
- Zal een andere ontwikkelaar deze code over een jaar begrijpen?
- Is de oplossing in lijn met de architectuur van het gehele systeem?
- Dupliceren we logica die al ergens anders bestaat?
- Creëert het technische schuld?
- Controleert de test echt het juiste gedrag, of bevestigt hij alleen dat de code precies doet wat de auteur had verondersteld?
AI kan helpen sommige van deze vragen te beantwoorden. AI kan ook helpen tests te maken, mogelijke problemen te vinden of refactorings voor te stellen. Maar het ontslaat een organisatie niet van de verantwoordelijkheid voor het antwoord.
Het gevaarlijkste code is niet die welke niet werkt
Code die direct faalt is relatief makkelijk te vinden.
Veel gevaarlijker is code die goed genoeg werkt om naar productie te gaan, maar problemen heeft die niet direct zichtbaar zijn.
Het kan onnodig complex zijn. Het kan duplicatie van bestaande logica bevatten. Het kan fouten bevatten in de omgang met randgevallen. Het kan prestatieproblemen hebben. Het kan bibliotheken of patronen gebruiken die het team liever niet hanteert in het project.
En het kan er zeer professioneel uitzien.
Dat is precies een van de valkuilen van generatieve AI; code kan overtuigend lijken voordat het goed is.
Een Sonar-studie gepubliceerd in 2026 toont aan dat 53% van de ondervraagde developers AI een negatieve invloed toeschreef op technische schuld door het genereren van code die er correct uitzag maar onbetrouwbaar bleek te zijn.
Dat betekent niet dat AI uitsluitend slechte code produceert. Het betekent iets veel praktischers: meer gegenereerde code is niet automatisch meer waardevolle code.
AI kan ook het tempo van technische schuld versnellen
Stel je een klassiek project voor.
Voor AI had een developer twee dagen nodig om een bepaalde functie te maken. Na de invoering van AI doet AI het in een halve dag. Geweldig.
Maar wat als tegelijkertijd het aantal wijzigingen in het project meerdere malen toeneemt?
Wat als in plaats van één goed doordachte implementatie er vijf vergelijkbare ontstaan?
Wat als nieuwe functies sneller worden toegevoegd dan het team in staat is om te refactoren?
Wat als code regelmatig door verschillende modellen wordt gegenereerd met uiteenlopende aannames over architectuur?
Dan vergroot AI niet alleen de productiviteit. Het kan ook het tempo van accumulatie van technische schuld verhogen.
Een analyse van GitClear over 211 miljoen regels code wijst op een stijging van codeduplicatie in de geanalyseerde periode, en de auteurs koppelen deze trend onder andere aan de popularisering van AI-assisted coding. Dit is geen bewijs dat elke door AI gegenereerde regel slechter is, maar het is een krachtig signaal dat hogere wijzigingssnelheid sterke kwaliteitscontrole vereist.
En hier komen we bij een zeer belangrijke regel: als AI het schrijven van code versnelt, moet ook het verificatieproces mee evolueren.
Je kunt niet simpelweg de codeproductie verdubbelen en de rest van het proces ongewijzigd laten.
"AI controleert haar eigen code"
Dat klinkt verleidelijk. AI schreef een functie. Een andere AI controleert hem. Weer een andere maakt tests.
Probleem opgelost? - Niet noodzakelijk.
In 2026 zien we steeds vaker situaties waarin één agent code creëert en een andere agent die reviewt. Er ontstaat zo een gesloten AI-tot-AI-cyclus: de ene agent maakt de wijziging, de andere analyseert hem, en de organisatie kan het resultaat accepteren zonder voldoende menselijke tussenkomst. Onderzoek naar dit model laat zien dat AI-to-AI code review inderdaad toeneemt, hoewel het nog steeds een minderheid van de geanalyseerde agentactiviteiten vormt.
Dat kan zeer waardevol zijn. Maar het heeft ook een fundamentele beperking - twee AI-systemen kunnen dezelfde soort fout maken.
Als de agent die code schrijft een foutieve zakelijke aanname hanteert, kan de review-agent die over het hoofd zien. Als beide systemen op vergelijkbare patronen zijn getraind, kunnen ze hetzelfde probleem missen.
Daarom moet de mens nog steeds deel uitmaken van het proces. Niet als iemand die de code handmatig overschrijft, maar als iemand die het systeem, de zakelijke context, risico's en consequenties van technische beslissingen begrijpt.
De ontwikkelaar van de toekomst wordt niet minder verantwoordelijk. Hij wordt verantwoordelijk voor meer
Dat is een zeer belangrijke verandering.
Je kunt je een developer voorstellen die vroeger 70% van zijn tijd aan implementatie besteedde, en die dankzij AI nu veel meer tijd kan besteden aan analyse, architectuur, testen, review en het oplossen van problemen.
Dat is het positieve scenario.
De developer hoeft geen codeproductiemachine te zijn. Hij kan een nog betere ingenieur worden. Het probleem ontstaat wanneer een organisatie de productiviteitsstijging enkel interpreteert als een mogelijkheid om het aantal uren te verminderen dat voor een taak nodig is.
Want dan is het makkelijk tot een absurd model te komen: "Als AI dit in een uur doet, waarom hadden we er vroeger drie dagen voor nodig?"
Die drie dagen konden analyse, architectuur, tests, reviews, fixes, integratie, documentatie en uitrol omvatten.
Code was slechts één onderdeel van het werk.
En wat met veiligheid?
Hier wordt het nog belangrijker.
Gegenereerde code kan kwetsbaarheden bevatten, foutieve aannames over autorisatie, inadequate datavalidatie of gevaarlijk gebruik van libraries.
Het is dus niet genoeg te zeggen: "Maar AI heeft de code gecontroleerd".
Onderzoeken naar AI-powered code review tonen aan dat zulke tools niet als vervanging voor toegewijde beveiligingsmechanismen en handmatige audits moeten worden gezien. In een van de studies over GitHub Copilot Code Review wezen de auteurs op problemen met het detecteren van belangrijke kwetsbaarheden, zoals SQL-injectie, XSS en insecure deserialization.
Dat leidt tot een gezonde regel: AI kan onderdeel zijn van het securityproces. Het mag niet het enige beveiligingsmechanisme zijn. Zeker niet bij applicaties die klantgegevens, betalingen, documenten, personeelsgegevens of bedrijfsinformatie verwerken.
Het grootste probleem ontstaat wanneer niet duidelijk is wie de beslissing heeft genomen
In een traditioneel proces kun je de wijziging traceren.
Een developer heeft code geschreven.
Een pull request is aangemaakt.
Iemand heeft het gereviewd.
Tests zijn uitgevoerd.
De wijziging is naar productie gegaan.
In een wereld van agentgebaseerd programmeren wordt dat proces complexer. Een agent kan tientallen acties uitvoeren. Hij kan veel bestanden wijzigen. Hij kan tests genereren. Hij kan zelf fouten repareren. Hij kan een pull request klaarmaken.
Daarom worden governance-regels voor AI in het softwareontwikkelingsproces steeds belangrijker.
Wie mag een agent starten?
Tot welke repository heeft hij toegang?
Mag hij productcode wijzigen?
Mag hij database-migraties uitvoeren?
Mag hij afhankelijkheden installeren?
Mag hij productiedata gebruiken?
Wie keurt zijn wijzigingen goed?
Heeft elke wijziging een audittrail?
Kun je reconstrueren waarom een bepaalde beslissing is genomen?
Dit zijn geen vragen van het type "AI zal ooit van belang zijn". Dit zijn vragen over het softwareontwikkelingproces vandaag.
Het is geen toeval dat tools voor development teams functies toevoegen die contextcontrole, code-standaarden, review van agents en monitoring van agentgebruik ondersteunen. Dat dergelijke mechanismen deel gaan uitmaken van ontwikkeltools laat de richting van de markt zien: een agent mag niet slechts een "extra ontwikkelaar" zijn; hij moet onderdeel zijn van een gecontroleerd engineeringproces.
"Vibe coding" is geweldig. Tot op zekere hoogte
Er is niets mis met experimenteren.
Wil je een prototype maken? AI is fantastisch.
Wil je snel een idee valideren? Geweldig.
Wil je een proof of concept maken? Nog beter.
Een kleine interne automatie? Misschien doet AI het grootste deel van het werk.
Het probleem ontstaat wanneer een prototype als product wordt behandeld.
Want plotseling verandert: "laten we iets snel maken" in: "sluit daar CRM op aan".
Daarna: "laten we betalingen toevoegen".
Vervolgens: "laten we 500 gebruikers erop laten werken".
En een maand later: "waarom is dit systeem zo traag en waarom weet niemand behalve de auteur hoe het te onderhouden?"
Een prototype kan snel zijn. Een product moet ontworpen zijn. Dat is een groot verschil.
AI neemt geen verantwoordelijkheid over. Het verschuift die hoger
En dat is wellicht de belangrijkste conclusie van het hele debat.
Als een developer ooit vooral verantwoordelijk was voor het correct schrijven van code, is hij vandaag steeds vaker verantwoordelijk voor een veel breder proces: het begrijpen van het probleem, het kiezen van de oplossing, het controleren van de kwaliteit van gegenereerde code, security, tests, architectuur, onderhoudbaarheid en naleving van zakelijke vereisten.
AI kan een deel van het werk doen. Maar AI zou niet automatisch verantwoordelijkheid moeten overnemen.
Bovendien tonen recente gebeurtenissen in de AI-wereld aan dat het controleprobleem niet langer puur theoretisch is. In de afgelopen dagen verschenen meldingen van incidenten waarbij AI-agents in ontwikkelomgevingen ingrepen, onder meer agents van OpenAI die zich tijdens testactiviteiten met RubyGems zouden hebben bemoeid. OpenAI bevestigde betrokkenheid van zijn agents en gaf uitleg over het incident.
Dat is een prima voorbeeld waarom, naarmate AI autonomer wordt, het belang van toegangsbeperkingen, sandboxing, monitoring en menselijke controle toeneemt.
AI kan toegang hebben tot code. Dat betekent nog niet dat het toegang tot alles zou moeten hebben.
Wat moet een goed softwarehuis doen?
Allereerst niet doen alsof AI niet bestaat. Integendeel.
Het is zinvol AI te gebruiken waar het de productiviteit van het team daadwerkelijk verhoogt: bij code-analyse, prototyping, documentatie, tests, refactoring, het genereren van repetitieve onderdelen of het analyseren van problemen.
Maar tegelijkertijd moeten klassieke principes van software-engineering behouden blijven.
Architectuur blijft belangrijk.
Code review blijft belangrijk.
Tests blijven belangrijk.
Security blijft belangrijk.
Documentatie blijft belangrijk.
Ervaring van ontwikkelaars blijft belangrijk.
En vooral blijft de mens belangrijk die kan zeggen: "Ja, AI heeft deze code gegenereerd. Maar voordat we het uitrollen, controleren we of we het überhaupt op die manier zouden moeten schrijven."
Het duurste kan niet zijn hoeveel je betaalt om code te schrijven
Dat is een perspectief dat het waard is om te veranderen.
Als AI een functie in een fractie van de tijd kan maken, is dat geweldig. Maar de kosten van software eindigen niet bij de eerste uitrol.
Het systeem zal worden doorontwikkeld.
Het zal aan nieuwe services worden gekoppeld.
Vereisten zullen veranderen.
Nieuwe apparaten, browsers, betaalsystemen, regelgeving en klantbehoeften zullen opkomen.
Iemand moet na een jaar weer in de code duiken.
Iemand moet om 02:00 's nachts een bug vinden.
Iemand moet een migratie uitvoeren.
Iemand moet het systeem beveiligen.
En dan blijkt of het bedrijf echt heeft bespaard door snel software te maken, of alleen de kosten naar later heeft verschoven.
Daarom ligt echte waarde niet in zoveel mogelijk code door AI te laten schrijven.
Waarde ligt in het dankzij AI sneller bouwen van betere software, zonder het overzicht over wat is gebouwd te verliezen.
Bij Web24 zien we AI als gereedschap, niet als vervanging van engineering
AI kan een uitstekend teamlid zijn.
Het kan werk versnellen.
Het kan repetitieve taken overnemen.
Het kan ontwikkelaars helpen enorme hoeveelheden code te analyseren.
Het kan de weg van idee naar eerste werkende oplossing verkorten.
Maar tussen "het werkt" en "klaar voor de komende vijf jaar" ligt een enorme ruimte.
Daar begint echte software-engineering. Omdat het vandaag steeds makkelijker is om code te genereren. Het is moeilijker een systeem te bouwen waarvoor je met gerust hart verantwoordelijkheid kunt nemen. Misschien wordt dat wel een van de belangrijkste competenties van softwarehouses in de komende jaren.
Niet alleen het schrijven van code.
Niet alleen het gebruik van AI.
Maar het vermogen om AI, menselijke ervaring, architectuur, security en verantwoordelijkheidsgevoel voor het hele systeem te combineren.
