Copilot schreef het, maar wie bezit het? De governance‑kloof die engineering‑teams mogelijk over het hoofd zien

Een engineer opent Copilot om code voor de website van een klant op te stellen. Binnen enkele seconden ontvangen ze code die voorheen aanzienlijk langer handmatig geschreven zou moeten worden. Voor veel webontwikkelaars en bedrijven die hun websites optimaliseren, is het normaal zich af te vragen: is die code betrouwbaar? Is hij veilig? Moet hij worden beoordeeld voordat hij wordt geïmplementeerd?  Deze vragen vallen allemaal onder één overkoepelende vraag: wie wordt verantwoordelijk gehouden voor AI‑ondersteunde codering? En, het belangrijkste, wie bezit de productiviteitswinst?

Als AI een engineeringteam in staat stelt meer werk te voltooien in dezelfde tijd, kan iedereen meer profiteren van die economische waarde. Dit kan de ontwikkelaar zijn tijd besparen, de werkgever meer waarde halen uit bespaarde uren, of de klant krijgen wat hij heeft betaald met uren over. Ongeacht hoe de bespaarde tijd ten goede komt, blijft de vraag hoe het werk wordt bestuurd en geprijsd centraal staan.

AI en coderen wordt onvermijdelijk

AI‑coderingstools winnen snel aan populariteit en dringen door tot de mainstream ontwikkeling. Volgens de 2025 Stack Overflow Developer Survey, gaf 84 % van de respondenten aan AI‑tools te gebruiken of van plan te zijn ze te gebruiken in hun ontwikkelproces.

Hoewel het integreren van AI in de werkstromen van webontwikkelaars steeds gebruikelijker wordt, bestaat er nog steeds aarzeling over de betrouwbaarheid. Uit dezelfde enquête bleek dat 46 % geen volledig vertrouwen had in de nauwkeurigheid van AI‑output, en ongeveer 66 % AI‑oplossingen noemde die “bijna goed, maar niet helemaal” als bron van frustratie.

Het AI‑coderingdebat dat zich vormt, draait meer om de betrouwbaarheid dan om de vraag of die code meer waarde creëert en wie verantwoordelijk is om dat te waarborgen.

AI verbreekt de relatie tussen uren en output

Compensatie voor softwareontwikkeling was altijd gebaseerd op de veronderstelling dat engineeringoutput nauw verband hield met de geleverde inspanning. Generatieve AI maakt die vergelijking nu echter ingewikkelder.

Een gecontroleerd experiment met 95 ontwikkelaars vond dat deelnemers met toegang tot GitHub Copilot een specifieke JavaScript‑HTTP‑servertaak 55,8 % sneller dan degenen zonder toegang.

Dit laat zien dat AI ontwikkeling kan versnellen, mogelijk zonder concessies aan kwaliteit. Maar deze cijfers zijn alleen succesvol omdat het experiment een zeer specifieke programmeertaak volgde. Hoewel de taak sneller werd voltooid, betekent dit niet dat Copilot een volledige engineeringorganisatie 55,8 % productiever maakt.

Een andere onderzoekstudie illustreert dit idee. Een onderzoek met 96 full‑time Google‑software‑engineers vond dat ontwikkelaars die AI gebruikten een enterprise‑grade taak in ongeveer 96 minuten voltooiden, vergeleken met 114 minuten voor degenen zonder. De aangepaste schatting van de onderzoekers suggereerde ongeveer een 21 % vermindering van de voltooidtijd. De studie onderzocht echter niet de kwaliteit van de AI‑code, noch behandelde ze vragen over eerlijkheid met betrekking tot afhankelijkheid van de technologie.

Er is ook bewijs dat AI de codeertijd vertraagt. Een gerandomiseerde studie van METR betrok 16 ervaren open‑source‑ontwikkelaars die aan 246 echte issues werkten in repositories die ze goed kenden. Met tools die begin 2025 beschikbaar waren, waaronder Claude Sonnet 3.5 en 3.7, en Cursor Pro, namen ze ongeveer 19 % meer tijd om hun taken te voltooien, hoewel velen dachten dat deze tools tijd zouden besparen.

Samen ondermijnen deze studies de verwachting dat AI ontwikkelaars sneller laat werken. In plaats daarvan maakt AI de tijd en waarde van ontwikkelaars minder voorspelbaar voor bedrijven die webwerk aanbieden en voor de klanten die het ontvangen.

Het prijsprobleem waar niemand over spreekt

Time & Material (T&M) is een gangbaar model in webontwikkeling voor de aankoop van software, omdat het een terugkerend industrieel probleem aanpakt: een evoluerend project.

Met dit model hoeven niet alle functies of taken vooraf gedefinieerd te worden voordat de ontwikkeling start; klanten kunnen betalen voor engineeringtijd terwijl het project vordert en verandert.

AI veroorzaakt echter hobbels in dat beproefde model. Omdat de compensatie direct gekoppeld is aan engineeringuren, kan efficiëntere ontwikkeling resulteren in minder factureerbare uren voor klanten. Als AI dezelfde resultaten in minder tijd levert, kan de technologie waarde voor klanten creëren, maar de vermindering van factureerbare uren betekent minder inkomsten voor aanbieders.

De oplossing is niet om ontwikkelaars aan te moedigen langzamer te werken. Het T&M‑model kampt nu met een structureel probleem in de manier waarop prijzen en prikkels worden vormgegeven. Het gebruik van uurtarieven om waarde te bepalen kan beperkend zijn. Een koper kan precies weten wat elk engineeringuur kost, maar blijft onzeker over de totale investering die nodig is om het gewenste resultaat te bereiken.

Naarmate AI de engineeringproductiviteit verandert, kan de vraag verschuiven van:

“Wat kost een ontwikkelaarsuur?” → “Wat gebeurt er met de waarde wanneer er minder ontwikkelaarsuren nodig zijn?”

De METR‑bevindingen bemoeilijken deze vraag. Als ontwikkelaars denken tijd te besparen terwijl ze in werkelijkheid langer doen, is noch AI‑adoptie noch waargenomen productiviteit voldoende om financiële waarde aan te tonen. Daarom hebben organisaties governance nodig die kan meten wat er daadwerkelijk is gebeurd.

De governance‑kloof heeft vier eigenaren

Het bespreken van governance rond AI‑ondersteunde ontwikkeling moet verder gaan dan beleid dat bepaalt welke tools ontwikkelaars mogen gebruiken.
Er zijn ten minste vier soorten eigendom die engineeringorganisaties moeten definiëren.

1. Wie bezit de code?

AI kan een implementatie genereren, maar kan geen excuus zijn voor ontwikkeling zonder verantwoordelijkheid. Iemand moet nog steeds verantwoordelijk zijn voor het beoordelen, testen en goedkeuren van de code totdat deze de productiefase bereikt.

2. Wie draagt het risico?

Snellere code is alleen waardevol als deze geen problemen veroorzaakt elders. Een empirische studie van AI‑gegenereerde code identificeerde beveiligingszwaktes in 29,5 % van de onderzochte Python‑fragmenten en 24,2 % van de JavaScript‑fragmenten. Het onderzoek identificeerde ook zwaktes over 43 Common Weakness Enumeration‑categorieën.

De studie vond echter dat het terugvoeren van statische‑analysewaarschuwingen naar Copilot Chat tot 55,5 % van de geïdentificeerde beveiligingsproblemen kon verhelpen. Het onderzoek toont aan hoe AI codeerproblemen kan creëren en oplossen, maar organisaties hebben processen nodig om te bepalen hoe de output gevalideerd wordt.

NIST’s SP 800-218A weerspiegelt dit principe door zijn Secure Software Development Framework uit te breiden met best practices die generatieve AI en dual‑use foundation‑modellen adresseren.

3. Wie bezit de productiviteitswinst?

Commerciële afspraken vanaf het begin zijn essentieel om te bepalen wie de efficiëntiewinst moet ontvangen. AI kan klanten helpen minder uit te geven, teams in staat stellen meer software te leveren, of geen financieel voordeel opleveren aan het einde van het project.
Wat onveranderd blijft, is de noodzaak van transparante processen en de levering van kwalitatief, overeengekomen werk.

4. Wie bepaalt de prioritering?

AI kan het genereren van features goedkoper en sneller maken, maar kan niet bepalen of die features vereist zijn.
Sterker nog, een grotere ontwikkelingscapaciteit kan prioritering belangrijker maken. Wanneer teams sneller kunnen bouwen en experimenteren, moet er nog steeds iemand bepalen welke resultaten het beschikbare budget rechtvaardigen en welke ideeën moeten worden verlaten.

AI‑governance wordt een financiële kwestie

Deze vragen maken AI‑governance steeds relevanter. Stel je twee ontwikkelingspartners voor die vergelijkbare uurtarieven hanteren.

De ene heeft AI geïntegreerd in een sterk engineeringproces en behaalt het gewenste resultaat aanzienlijk sneller, terwijl de andere langer duurt. Alleen hun uurtarieven vergelijken vertelt de koper weinig over de processen die ze uitvoeren.

Kopers moeten evalueren:

• Totale verwachte investering
• Verantwoordelijkheid voor overschrijdingen
• Kwaliteitscontroles rond AI‑gegenereerd werk
• Hoe efficiëntiewinsten worden gedeeld

T&M kan nuttig blijven voor beide partijen als ze bewust onzekerheid in de diensten accepteren. Fixed‑price‑arrangementen kunnen ook werken wanneer eisen en leveringen stabiel zijn.

Maar AI maakt ook alternatieve structuren de moeite waard om te onderzoeken. Een aanpak is een maximale financiële grens vast te stellen terwijl de scope flexibel blijft. Vervolgens kunnen features worden geprioriteerd op basis van bedrijfswaarde binnen dat model.

Als engineering efficiënter wordt, kunnen winsten zich vertalen naar extra productcapaciteit in plaats van extra factureerbare tijd. Commerciële prikkels moeten hetzelfde resultaat als engineeringprikkels stimuleren, waardoor meer bruikbare software zo efficiënt mogelijk wordt gecreëerd.

Hetzelfde AI‑gesprek

Engineeringleiders moeten begrijpen hoe commerciële prikkels de levering beïnvloeden. Financiële en inkoopteams hebben voldoende zicht nodig op AI‑ondersteunde engineering om te beoordelen of de beweerde efficiëntie meetbare waarde oplevert.

Dat betekent dat volwassen AI‑governance niet mag stoppen bij goedgekeurde model‑lijsten, beveiligingscontroles, datapolitiek of code‑reviewvereisten. Het moet verantwoordelijkheid, financieel risico, prioritering en eigendom van productiviteitswinsten aanpakken.

Maar er is een tweede eigendomsvraag die een veel grotere impact op technologiebudgetten kan hebben: Wie bezit de waarde die wordt gecreëerd of verloren wanneer AI verandert hoe snel software wordt gebouwd?

De organisaties die bepalen of snellere engineering daadwerkelijk betere producten oplevert, investeringen beheersen en meetbare bedrijfsresultaten behalen, zullen degenen zijn die de concurrentie voorblijven.

Als je ontwikkelingsteam morgen AI zou adopteren, zou je huidige governance‑ en commerciële model je dan zelfs kunnen vertellen of het de levering waardevoller heeft gemaakt?