Terug naar het blogartikel

AI als versneller, niet als vervanger: werkstroom, codekwaliteit en eigenaarschap

Michel Mix · Medellín, Colombia · 7 mei 2026

Samenvatting

Deze literatuursynthese onderzoekt welke workflowprincipes samenhangen met productiviteit, codekwaliteit en menselijk eigenaarschap bij AI-ondersteunde softwareontwikkeling. De kernconclusie is praktisch: AI-codeassistenten kunnen ontwikkelaars versnellen, maar vooral wanneer ze worden ingebed in een expliciete werkstroom met scherpe taakafbakening, goede specificatie, gecontroleerde generatie, structurele verificatie, kwaliteitsborging en menselijke review. De literatuur laat tegelijk zien waarom ongericht AI-gebruik misleidend kan zijn. Developers voelen zich vaak sneller, terwijl verificatie, aanpassing, technische schuld en eigenaarschapsverlies de winst kunnen verkleinen of omdraaien. De sterkste workflow is daarom niet “meer AI”, maar gedisciplineerd AI-gebruik binnen normale engineeringcontrols.

Kernpunten

• Productiviteitswinst door AI is reëel, maar ongelijk verdeeld en sterk afhankelijk van ervaring, taaktype, projectfase en verificatiekosten.
• AI werkt het best bij afgebakende acceleratietaken; exploratie, architectuur, security en hoge-accountability-werk vragen zwaarder menselijk oordeel.
• Specificatie vóór generatie is een kwaliteitshefboom: intentie, constraints, context en expliciete grenzen moeten eerst helder zijn.
• Verificatie is geen bijzaak maar een ontworpen workflowstap; vermoeidheid en verificatielast kunnen controles aantoonbaar oppervlakkiger maken.
• Statische analyse, tests, security-validatie en peer review worden belangrijker door AI-gebruik, niet minder belangrijk.
• Menselijk eigenaarschap blijft de finale poort: de developer moet de code begrijpen, kunnen uitleggen en willen onderhouden.

Positionering

Deze tekst is een literatuursynthese voor een presentatie over AI-assisted software development. Het is geen volledige systematische review en geen productvergelijking tussen AI-tools. De synthese verbindt empirische studies, preprints, industriële casussen en conceptuele artikelen tot een werkbare redenering voor ontwikkelteams.

Onderzoeksvraag

Welke workflowprincipes hangen samen met productiviteit, codekwaliteit en menselijk eigenaarschap bij AI-ondersteunde softwareontwikkeling?

Literatuursynthese

Inleiding

AI-codeassistenten zijn in korte tijd alomtegenwoordig geworden in softwareontwikkeling. GitHub Copilot, ChatGPT, Claude, Cursor en hun autonome opvolgers worden niet meer alleen experimenteel ingezet: ze schrijven inmiddels meer dan twintig procent van de nieuwe code bij organisaties als Google en Microsoft, terwijl de Stack Overflow Developer Survey 2025 rapporteert dat 84 procent van de professionele ontwikkelaars AI-codingtools gebruikt of van plan is dat te doen (geciteerd in Liu et al., 2026). Toch zijn de effecten op productiviteit, codekwaliteit en professioneel eigenaarschap allesbehalve eenduidig positief, en zijn ze sterk afhankelijk van de manier waarop developers AI inzetten.

De centrale these van deze synthese is dat de vraag of AI helpt minder relevant is dan de vraag hoe het wordt ingezet. De geselecteerde empirische en conceptuele studies laten zien dat er een coherente set workflowprincipes bestaat die productiviteitswinst mogelijk maakt, codekwaliteit borgt en menselijk eigenaarschap bewaakt. Tegelijkertijd tonen dezelfde studies dat het negeren van deze principes leidt tot verborgen tijdkosten, persistente technische schuld en een geleidelijke erosie van professionele accountability.

Deze synthese is thematisch opgebouwd. Eerst komt het productiviteitsbeeld aan bod, daarna de vijf workflowprincipes: taakafstemming, specificatie vóór generatie, expliciete verificatie, structurele kwaliteitsborging en menselijk eigenaarschap. Vervolgens wordt codereview behandeld als kritisch knooppunt en worden de organisatorische randvoorwaarden benoemd. De tekst sluit af met een geïntegreerde, direct toepasbare werkstroom en de grenzen waarbinnen de conclusies het sterkst gelden.

Productiviteit: een genuanceerd en contextafhankelijk beeld

De productiviteitseffecten van AI-codeassistenten zijn positief gemiddeld, maar ongelijk verdeeld en voor een deel illusoir als het bredere plaatje wordt genegeerd. Dit is de meest consistente bevinding in de literatuur, en tegelijkertijd de meest miskende.

De sterkste positieve cijfers komen uit de RCT-studie van Cui et al. (2025), die 4.867 ontwikkelaars volgde bij Microsoft, Accenture en een Fortune 100-bedrijf: AI-codeassistentie leidde tot gemiddeld 26,08 procent meer voltooide taken, 13,55 procent meer commits en 38,38 procent meer compilaties. Minder ervaren ontwikkelaars profiteerden het sterkst. Vergelijkbare, zij het meer bescheiden winsten werden gevonden door Song et al. (2024) in open-source projecten: Copilot-gebruik leidde tot een nettostijging van 5,9 procent in projectniveau codebijdragen. Mohamed et al. (2025) bevestigen in hun systematische review van 39 studies dat de meerderheid voordelen rapporteert, met name versnelling van routinetaken en vermindering van het zoeken naar syntaxis en boilerplate.

Echter, dezelfde literatuur bevat een opvallende contraconventionele bevinding die de euforie tempereert. Becker et al. (2025) voerden een binnen-deelnemers RCT uit met 16 ervaren open-source bijdragers (246 taken) die werkten in hun eigen, vertrouwde projecten; de auteurs zelf benoemen experimentele artefactrisico’s, maar achten het hoofdresultaat robuust. Het resultaat was een 19 procent toename in taakvoltooiingstijd bij AI-gebruik — terwijl de deelnemers zelf een verbetering van 24 procent voorspeld hadden. Dit optimisme-gat tussen perceptie en werkelijkheid is in meerdere studies gesignaleerd (Liang et al., 2024; Mozannar et al., 2024) en vormt een ernstig risico: teams die denken sneller te werken maar dat niet doen, bouwen geen grond voor kritische evaluatie van hun werkwijze.

De verklaring voor dit verschil ligt in wat Mohamed et al. (2025) de meerdimensionaliteit van productiviteit noemen, en wat Chen et al. (2026) empirisch uitwerken op basis van een mixed-methods studie bij BNY Mellon (2.989 enquêtereacties en 11 diepte-interviews). Chen et al. identificeren zes productiviteitsfactoren, waarvan technische expertise en eigenaarschap van het werk de meest onderschatte zijn. Kortetermijnmetrics zoals commits en voltooide taken meten niet of een developer daadwerkelijk de code begrijpt, kan onderhouden of met vertrouwen kan verdedigen. Fan et al. (2026) voegen vanuit een ander kader een aanvullende dimensie toe: verificatiebelasting. Hun experiment met 60 deelnemers laat zien dat AI-gebruik de werktijd gemiddeld 22 procent verkort, maar dat een verification-load index (mislukte compilaties, time-to-first-compile, codeomkeringen, pauzes en interactie-onderbrekingen) cumulatief oploopt en deels de stijging in stress en vermoeidheid over taken heen verklaart.

De grens van de productiviteitswinst is dus niet willekeurig. Becker et al. (2025) tonen dat de grens verschuift met de vertrouwdheid met de codebase: in rijpe, complexe projecten wegen verificatie- en aanpassingskosten zwaarder dan de tijdswinst van gegenereerde code. Song et al. (2024) voegen een collectieve dimensie toe: AI verhoogt individuele bijdragen, maar verhoogt ook de coördinatietijd met 8 procent. Het nettoeffect op projectniveau blijft volgens de auteurs positief, maar wel kleiner dan een puur individuele meting zou suggereren. Kortom: de vraag is niet of AI productiviteitswinst oplevert, maar voor wie, in welke projectfase en bij welke taakverdeling — en of die winst wordt gerealiseerd zonder sluipende kwaliteits- en eigenaarschapskosten.

Workflowprincipe 1: taakafstemming

De eerste en meest fundamentele conclusie uit de literatuur is dat niet alle taken even geschikt zijn voor AI-ondersteuning, en dat het bewust matchen van taaktype aan AI-inzet de productiviteitswinst maximaliseert terwijl kwaliteitsrisico’s worden beperkt.

De grondslag voor dit principe legden Barke et al. (2023) via grounded theory-analyse van 20 programmeurs die met GitHub Copilot werkten. Zij onderscheidden twee kwalitatief verschillende interactiemodi. In de acceleratiemodus weet de developer precies wat hij wil bereiken en gebruikt hij AI als versneller: suggesties worden snel beoordeeld en geaccepteerd of verworpen. In de exploratiemodus is de developer onzeker over de richting en gebruikt hij AI om opties te verkennen — wat zowel kan helpen als vertragen. Het cruciale punt is dat elke modus een andere verificatiestrategie vraagt: in acceleratiemodus volstaat snelle inspectie, terwijl in exploratiemodus diepgaander evaluatie noodzakelijk is.

Empirisch inzicht in taakafstemming bieden Sergeyuk et al. (2024) op basis van een enquête onder 481 JetBrains-gebruikers. Zij laten zien dat ontwikkelaars AI-assistenten gebruiken bij uiteenlopende activiteiten, waaronder nieuwe features, tests, bugtriage, refactoring en natural-language artifacts, maar dat concrete taken zoals testgeneratie en docstrings duidelijker geschikt lijken dan taken waarvoor projectbrede context nodig is. Dit correspondeert met Li et al. (2024), die met hun DevEval-benchmark laten zien dat huidige LLM’s significante tekortkomingen hebben in de vroege SDLC-fasen (systeemontwerp, omgevingsopzet, acceptatietesten) en het sterkst presteren bij geïsoleerde implementatietaken.

De praktijk bevestigt dit patroon. Li et al. (2026) analyseerden 2.547 ChatGPT-gesprekken van GitHub en vonden dat het overgrote deel van de interacties bestond uit één tot drie beurten — taakgericht, smal van scope, en gericht op codegeneratie, code-aanpassing of probleemresolutie. Vigh et al. (2026) bevestigen in interviews met 11 developers dat AI-gebruik conditioneel en selectief is: developers gebruiken AI bewust niet voor beveiligingskritische, systeembepalende of hoge-accountability-taken. Dit is geen onwil, maar professioneel oordeel. Verantwoordelijkheid voor correctheid en veiligheid wordt door deze developers expliciet als non-transferable beschouwd.

Het workflowprincipe dat hieruit volgt, is dat bewuste taakafstemming vóóraf plaatsvindt — niet als vage richtlijn, maar als expliciete beslissing: is dit een acceleratietaak of een exploratietaak? Is de risicograad laag genoeg voor AI-delegatie? Is er voldoende context om een AI-suggestie snel te kunnen beoordelen? Dat dit geen academische abstractie is, toont Russo (2024) aan: in zijn mixed-methods studie (enquête onder 100 softwareontwikkelaars, PLS-SEM-validatie met 183 respondenten) blijkt workflow-compatibiliteit de sterkste driver voor AI-adoptie te zijn — sterker dan waargenomen nut of sociale druk. Tools die het bestaande werkproces doorbreken, worden niet duurzaam geadopteerd; tools die er naadloos in passen, wel.

Workflowprincipe 2: specificatie vóór generatie

De tweede conclusie is dat AI-codegeneratie substantieel beter presteert wanneer de intentie, context en architecturale constraints expliciet worden vastgelegd vóórdat het model aan het werk gaat. Dit principe staat haaks op de meest gangbare AI-interactiepraktijk, waarbij developers direct een taak formuleren en hopen op een bruikbare suggestie.

De scherpste empirische demonstratie hiervan levert Mu et al. (2024) met ClarifyGPT: een framework dat ambiguïteiten in vereisten detecteert, gerichte verduidelijkingsvragen stelt aan de gebruiker en pas daarna code laat genereren. In een mensgevalideerde evaluatie op MBPP-sanitized steeg de Pass@1 van GPT-4 van 70,96 procent naar 80,80 procent door deze expliciete clarificatiestap. De wortel van deze verbetering is eenvoudig: LLM’s gokken bij onduidelijke input, en die gok is vaker fout dan de gebruiker beseft.

Ullrich et al. (2025) verdiepen dit via interviews met 18 practitioners uit 14 bedrijven. Hun bevinding is dat requirements zoals die doorgaans worden gedocumenteerd, te abstract zijn voor directe LLM-input. Developers moeten ze handmatig decomponeren in concrete programmeertaken, verrijkt met designbeslissingen, architectuurconstraints en relevante contextinformatie. Dit is geen tijdrovende omweg: het is het fundamentele requirements-engineeringwerk dat altijd al noodzakelijk was, maar dat nu ook een expliciete promptvoorbereiding vereist. De implicatie is duidelijk: eigenaarschap over de specificatie is de meest kritische menselijke bijdrage aan de AI-workflow, en het weglaten ervan leidt vrijwel zeker tot suboptimale output.

Mallya et al. (2025) voegen hier een praktische nuance aan toe vanuit requirements engineering: LLM’s kunnen gebruikersfeedback classificeren en requirementspecificaties genereren, maar hun prestaties blijven gematigd en vereisen menselijke validatie. Daarmee wordt AI bruikbaar als eerste filter voor ruwe input uit tickets, reviews of feedbackkanalen, maar niet als vervanging van de menselijke specificatiestap. Juist voordat code wordt gegenereerd moet de developer controleren of functionele intentie, niet-functionele eisen en prioriteit correct zijn vertaald.

Liang et al. (2024) ondersteunen dit vanuit een usabilityperspectief. In hun enquête onder 410 ontwikkelaars waren de meest genoemde redenen voor het niet accepteren van AI-suggesties: de output voldoet niet aan niet-functionele vereisten, en de output is moeilijk te sturen. Beide bezwaren zijn manifestaties van hetzelfde probleem: te weinig context en sturing in de prompt. Als aangrenzend bewijs uit bredere GenAI-literatuur toont Gerlich (2025) in een cross-nationaal experiment (n=150) dat gestructureerde prompting — waarbij de gebruiker gedwongen wordt zijn vraag methodisch te formuleren — niet alleen de kwaliteit van de AI-output verhoogt, maar ook cognitieve offloading vermindert en kritisch redeneren bevordert. Ongestructureerd AI-gebruik, zo blijkt, verhoogt de perceptie van productiviteit maar niet de redeneer- of outputkwaliteit.

Sarkar et al. (2024) vatten de principiële consequentie samen: AI-interfaces moeten bewust zo worden ontworpen dat ze kritisch denken in stand houden bij toenemende delegatie. Hun voorgestelde mechanisme zijn provocations — korte tekstuele tegenwerpingen die AI-output bekritiseren en alternatieven aanwijzen — die volgens hen niet vanzelf uit de interactie voortvloeien maar expliciet als interface-element ontworpen moeten worden. Het risico van het weglaten van zulke mechanismen is niet primair hallucinatie, maar cognitieve delegatie: de geleidelijke verplaatsing van kritisch denken van de developer naar het model, zonder dat de developer dit merkt of van plan was.

Workflowprincipe 3: verificatie als expliciete workflowstap

Dat AI-output verificatie vereist, is evident. Wat de literatuur toevoegt — en wat in de praktijk structureel onderschat wordt — is dat verificatie een substantiële tijdkost heeft, cumulatief afneemt in kwaliteit door vermoeidheid, en actief ontworpen moet worden in de workflow in plaats van ad hoc te worden uitgevoerd.

Mozannar et al. (2024) legden via de CUPS-taxonomie (Code Understanding and Participation Structures) bloot hoe 21 programmeurs daadwerkelijk hun tijd besteedden bij het werken met GitHub Copilot. De resultaten waren ontnuchterend: een groot deel van de interactietijd ging naar het lezen en evalueren van AI-suggesties, niet naar schrijven of probleemoplossing. De productiviteitswinst was daarmee kleiner dan de gebruikers verwachtten. Fan et al. (2026) kwantificeren dit verder via een gecontroleerd experiment: zij introduceerden de verification-load index — een samengestelde maatstaf van mislukte compilaties, tijd tot eerste compilatie, codeomkeringen en interactie-onderbrekingen. De index toonde aan dat verificatiebelasting cumulatief stijgt over taken heen, wat leidt tot vermoeidheid en statistisch aantoonbaar oppervlakkiger controle.

De praktische consequentie wordt het scherpst geïllustreerd door Becker et al. (2025). Hun RCT toonde dat ervaren developers in bekende codebases 19 procent lánger deden over taken met AI dan zonder. De oorzaak was niet dat de AI slecht was, maar dat de developers significant veel tijd besteedden aan het beoordelen, aanpassen en herstellen van suggesties die richting correct waren maar context misten. Dit is het aambeeldprobleem van rijpe projecten: er zijn conventies, architectuurpatronen, technische schuld en impliciete kennis die de AI niet heeft — en die de developer steeds opnieuw moet compenseren.

Liu et al. (2026) laten zien wat er gebeurt als verificatie onvoldoende is. In hun grootschalige analyse van 302.600 AI-gegenereerde commits in 6.299 GitHub-repositories werden 484.366 afzonderlijke issues geïdentificeerd — waarvan 22,7 procent nog aanwezig was in de laatste repositoryversie. Code smells waren het meest prevalent (89,3 procent van alle issues). Elke onderzochte AI-tool introduceerde in meer dan 15 procent van de commits ten minste één issue. Agarwal et al. (2026) vinden vergelijkbare patronen voor autonome coding agents: static-analysis-waarschuwingen stegen met 18 procent en cognitieve complexiteit met 39 procent — en dit bleef persistent, ook nadat de velocity-winst van de agents was weggeëbt.

Het workflowprincipe dat hieruit volgt, is dat verificatie niet als vanzelf goed verloopt en niet zo laat moet worden uitgevoerd als de druk hoog is. Adalsteinsson et al. (2025) laten zien dat AI-review in codereview-context effectiever is wanneer de reviewcontext expliciet wordt samengesteld (via een RAG-pipeline), zodat de AI-output relevanter is en de menselijke reviewer minder hoeft te compenseren. Vijayvergiya et al. (2024) tonen bij Google dat AI als eerste filter werkt voor coding-conventions, waarna menselijke reviewers zich kunnen concentreren op logica en architectuur — een expliciete taakverdeling die verificatie-efficiëntie verhoogt. Fan et al. (2026) adviseren adaptieve interface-selectie op basis van taakmoeilijkheid: inline AI voor eenvoudige taken, chatgebaseerde AI voor hogere complexiteit, gestructureerde prompts voor beginners.

Kortom: verificatie moet worden ontworpen — gepland als stap, toegerust op basis van taakmoeilijkheid en risico, en bewust afgebakend in tijd om vermoeidheid te beperken.

Workflowprincipe 4: structurele kwaliteitsborging

De vierde conclusie is dat AI-gebruik structurele kwaliteitsborging via statische analyse, tests en codestandaarden noodzakelijker maakt, niet overbodig. Meerdere studies tonen aan dat AI-output consistent kwaliteitsproblemen introduceert die zonder extra QA-stappen in de codebase blijven bestaan.

Liu et al. (2026) leveren hier het meest overtuigende empirische bewijs voor. Naast de hoge persistentie van issues (22,7 procent) vonden zij dat code smells het dominante probleemtype zijn — een fundamenteel onderhoudsrisico dat pas op lange termijn manifest wordt als hogere aanpassingskosten. Sun et al. (2026) sluiten hier op aan vanuit een andere invalshoek: zij analyseerden 109 wetenschappelijke papers, hielden twee industriële workshops en deden een empirische patchstudie, en concludeerden dat er een systematische misalignment bestaat tussen academische prioriteiten (security, performance), industriële prioriteiten (maintainability, leesbaarheid) en het feitelijke gedrag van LLM’s. Non-functionele kwaliteitskenmerken (NFQCs) zijn in geen van de drie domeinen afdoende geborgd. Practitioners vrezen technische schuld-accumulatie maar hebben geen geëigende QA-mechanismen voor AI-gegenereerde code.

Yu et al. (2026) maken deze conclusie concreet op organisatieniveau. In hun multi-casestudie van drie industriële GenAI-projecten vonden zij dat teams vooral contextspecifieke, taakgerichte kwaliteitsmetrics gebruiken, omdat generieke onderzoeksmetrics zelden direct passen bij de operationele waarde van een GenAI-output. Voor AI-gegenereerde code betekent dit dat kwaliteitsborging niet kan blijven steken in een algemene test- of lintstap. Teams moeten per codebase en taaktype expliciet maken welke kwaliteitscriteria tellen: onderhoudbaarheid, foutafhandeling, performance, beveiliging, uitlegbaarheid of aansluiting op domeinregels.

Dat prompting het probleem oplost, lijkt een aantrekkelijke gedachte, maar wordt niet ondersteund door de data. Della Porta et al. (2025) onderzochten 7.583 codebestanden uit de Dev-GPT-dataset op drie kwaliteitsattributen (maintainability, security, reliability) voor drie promptpatronen (zero-shot, chain-of-thought, few-shot). De Kruskal-Wallis-toets vond op deze dataset geen significante verschillen tussen de patronen voor maintainability, security en reliability. Binnen de scope van Della Porta et al. levert het promptpatroon dus geen meetbare kwaliteitswinst op — een indicatie dat kwaliteitsborging elders in de workflow moet worden belegd.

Statische analyse in combinatie met LLM’s biedt een meer veelbelovende richting. Patcas & Motogna (2026) evalueerden zes LLM’s op het oplossen van SonarQube-gerapporteerde kwaliteitsproblemen en vonden een gemiddelde reductie van 36 procent — met het beste model (Grok 3) dat 71,54 procent haalde op één project. Wadhwa et al. (2024) ontwikkelden CORE (Microsoft Research), een proposer-ranker LLM-duo dat statisch-analyseissues oplost en menselijke reviewcriteria nabootst; 59,2 procent van de Python-bestanden slaagde zowel voor de tool als voor menselijke beoordeling, terwijl 76,8 procent van de Java-bestanden de statische analyse passeerde. Berabi et al. (2024) toonden dat gerichte AI-reparatie van beveiligingsproblemen — waarbij programma-analyse de context van het LLM begrenst — betere resultaten levert dan ongericht genereren. De rode draad in al deze benaderingen is dezelfde: statische analyse stuurt de AI, in plaats van dat AI statische analyse vervangt. Simões & Venson (2024) bevestigen dat LLM-kwaliteitsevaluatie aanvullend is aan statische analyse, niet vervangend: hun vergelijking van GPT-modellen met SonarQube toont substantiële variabiliteit tussen modellen en benadrukt dat menselijke eindnormen noodzakelijk blijven.

Voor beveiligingsspecifieke kwaliteitsborging is de situatie nog urgenter. Tessa et al. (2026) voerden een adversariaal audit uit van drie state-of-the-art beveiligde codegeneratiemethoden en vonden dat statische analysers de beveiliging 7 tot 21 keer overschatten, dat 37 tot 60 procent van de als ‘veilig’ geclassificeerde outputs niet-functioneel was, en dat onder adversariale condities de daadwerkelijk veilige-én-functionele output daalde naar 3 tot 17 procent. Beveiligingsborging kan niet worden gedelegeerd aan een AI-model, zelfs niet aan modellen die specifiek voor dit doel zijn ontwikkeld. Tony et al. (2024) bevestigen vanuit een complementaire invalshoek dat gestructureerde prompttechnieken — met name Recursive Criticism and Improvement (RCI) — beveiligingszwakheden reduceren, maar dat externe beveiligingsvalidatie onverminderd noodzakelijk blijft.

De bevinding van Haroon et al. (2026) completeert het kwaliteitsplaatje op het terrein van testgeneratie. LLM’s bereiken initieel 79 procent lijndekking, maar onder semantische codewijzigingen (SAC) daalt het slaagpercentage van nieuw gegenereerde tests naar 66 procent, en de branchdekking naar 60 procent. Tests zijn oppervlakkig gekoppeld aan de originele code en reageren op lexicale in plaats van semantische veranderingen. AI-gegenereerde testsuites vereisen bij elke significante codewijziging menselijke herbeoordeling om regressiedekking te waarborgen.

Het workflowprincipe dat hieruit volgt, is dat kwaliteitsborging een structurele en meerdimensionale stap in de workflow is — niet een optionele aanvulling. Concreet betekent dit: statische analyse (bijv. SonarQube, CodeQL) draaien op AI-gegenereerde code vóórdat deze in review gaat; beveiligingsvalidatie via een dedicated tool naast de LLM; AI-testsuites periodiek herbeoordeeld bij codewijzigingen; en NFQCs (maintainability, leesbaarheid, performance) expliciet benoemd als acceptatiecriteria.

Workflowprincipe 5: menselijk eigenaarschap

De vijfde conclusie is dat menselijk eigenaarschap bij AI-ondersteunde softwareontwikkeling geen vanzelfsprekendheid is, maar actief moet worden bewaard. Zonder expliciete aandacht eroderen de mechanismen die eigenaarschap dragen — in Alami et al. (2025) terug te voeren op vier intrinsieke drivers: persoonlijke standaarden, professionele integriteit, trots op codekwaliteit en het bewaken van de eigen reputatie — systematisch onder invloed van AI-delegatie.

De conceptuele basis voor dit principe leggen Alami & Ernst (2024) in hun interviewstudie met 12 softwareontwikkelaars. Zij onderscheiden twee vormen van accountability: institutionele accountability (formele processen, meetbare KPI’s) en grassroots accountability (intrinsieke motivatie, reputatie, peernormen). Grassroots accountability is niet overdraagbaar aan een systeem: het berust op wederkerigheid, trots op kwaliteit en de verwachting van vakgenoten. Alami et al. (2025) tonen in een vervolgstudie (16 interviews en focusgroepen met simulaties van AI-review) dat LLM-geassisteerde codereview precies deze wederkerigheid doorbreekt: developers voelen zich niet accountable tegenover een AI, zoals ze dat wel zijn tegenover een collega. Dit heeft directe gevolgen voor de kwaliteitsnormen die zij hanteren bij door AI gegenereerde of gereviewde code.

Sarkar et al. (2024) beschrijven het structurele risico van toenemende AI-delegatie in de metafoor van Copilot dat verandert in Autopilot: de geleidelijke verplaatsing van kritisch denken van de developer naar het model, zonder bewuste keuze. Zij stellen dat hallucinaties minder gevaarlijk zijn dan dit sluipende verlies aan cognitieve betrokkenheid, en pleiten voor critical thinking tools — concreet gemaakt in hun prototype als provocations die AI-suggesties bekritiseren — als ontwerpfamilie die kritische evaluatie in het werk in stand houdt. Gerlich (2025) ondersteunt dit vanuit bredere GenAI-literatuur: gestructureerd AI-gebruik (waarbij de gebruiker gedwongen wordt de vraag methodisch te formuleren) reduceert cognitieve offloading significant en verhoogt kritisch redeneren, vergeleken met ongestructureerd gebruik.

Dat developers dit intuïtief aanvoelen, toont Vigh et al. (2026): in interviews met 11 developers bleek AI-gebruik consistent selectief te zijn. Developers beperkten AI-gebruik bewust bij taken met hoge accountability (beveiligingskritisch werk, systeemdefiniëring, architectuurbeslissingen). Verantwoordelijkheid voor correctheid en veiligheid werd door vrijwel alle deelnemers als non-transferable beschouwd. Dit is geen terughoudendheid uit onbekendheid met AI, maar professionele oordeelsvorming.

Ogenrwot & Businge (2026) leveren kwantitatief bewijs dat developers dit eigenaarschap in de praktijk ook waarmaken: in hun analyse van 338 GitHub pull requests uit 255 repositories met zelf-toegegeven ChatGPT-gebruik (645 AI-snippets, 3.486 developer-patches) was de mediane integratiegraat van AI-patches slechts 25 procent. Van de geïntegreerde patches werd het overgrote deel selectief aangepast, uitgetrokken of iteratief verfijnd. Volledige overname was de uitzondering. Watanabe et al. (2026) vinden vergelijkbare patronen voor autonome coding agents (Claude Code): 83,8 procent van de agent-PR’s werd gemerged, maar 45,1 procent vereiste menselijke revisie, met name voor bugs, documentatiestijl en projectspecifieke standaarden.

Het workflowprincipe dat hieruit volgt, is tweeledig. Enerzijds moet de developer bewust grenzen stellen aan AI-delegatie op basis van accountability en risicograad. Anderzijds moet de workflow-infrastructuur die grenzen ondersteunen: iteratieve menselijke beoordeling als norm, niet als uitzondering; peer review als sociale kwaliteits- en eigenaarschapspoort die niet door AI-review wordt vervangen, maar hooguit ondersteund; en het actief cultiveren van kritische betrokkenheid bij AI-output in plaats van snelle acceptatie.

Codereview als kritisch knooppunt

Codereview verdient een aparte behandeling, omdat het het meest onderzochte en meest beladen knooppunt is in de AI-ondersteunde ontwikkelworkflow. Het is het moment waarop productiviteit, codekwaliteit en eigenaarschap samenkomen — en waarop de spanning tussen AI-ondersteuning en menselijke accountability het meest voelbaar is.

De basis van waaruit alle AI-reviewinterventies moeten worden begrepen, legde Bacchelli & Bird (2013) in hun empirische studie bij Microsoft (17 developers, 16 teams, 873 programmeurs). Moderne codereview is veel meer dan foutopsporing: het is het primaire mechanisme voor kennisoverdracht, teamgeleide kwaliteitsnormen, bewustzijn van elkaars code en gedeeld eigenaarschap. Deze sociale functie is niet vervangbaar door een geautomatiseerd systeem, hoe nauwkeurig dat ook is. Een review door een collega draagt waarde die niet reduceerbaar is tot de comments die worden geplaatst — het draagt ook de wederkerige verantwoordelijkheid die Alami et al. (2025) identificeren als de kern van professionele accountability.

Dit sluit AI-ondersteuning in codereview niet uit, maar begrenst de rol die het mag innemen. Vijayvergiya et al. (2024) toonden bij Google dat AI (Autocommenter) effectief kan functioneren als eerste filter voor coding-practice-afwijkingen, waardoor menselijke reviewers zich kunnen richten op logica, semantiek en architectuur. Adalsteinsson et al. (2025) tonen bij WirelessCar dat een RAG-gebaseerd AI-reviewprototype (dat relevante contextuele informatie ophaalt vóór beoordeling) positiever werd ontvangen dan een contextloos AI-review — en dat de voorkeur voor AI-review conditioneel was op de familiarity van de reviewer met de codebase. Wadhwa et al. (2024) ontwikkelden een pipeline (CORE) waarbij statische analyse als gids voor de LLM fungeert en een ranker-LLM menselijke acceptatiecriteria nabootst. Peng et al. (2025) bereikten een 84 procent acceptatiegraad in productie bij Huawei via een mixture-of-prompts architectuur voor beveiligingsgericht review.

Cihan et al. (2025) sluiten hierbij aan met hun voorstel voor ‘human-in-the-loop LLM code review’: AI-review als kennisdelings- en signaleringsondersteuning, niet als eindoordeel. Lin et al. (2024) voegen hier een trainingsperspectief aan toe: de kwaliteit van AI-reviewcommentaar is afhankelijk van de kwaliteit van de trainingsdata, en menselijke expertise blijft de normatieve standaard. Ervaringsbewust trainen van reviewmodellen verbetert de output significant zonder extra dataverzameling.

De workflowimplicatie is dat AI in codereview altijd een adviserende, nooit een beslissende rol heeft. De reviewer behoudt eindoordeel, en het sociale ritueel van peer-review — met zijn wederkerige accountability — wordt bewaard. AI-review kan de drempel verlagen voor het signaleren van technische problemen (style, security, conventions), maar kan de sociale kwaliteitsfunctie van menselijke review niet overnemen. Waarbij het ook de efficiency van de menselijke reviewer vergroot: minder triviale opmerkingen te plaatsen, meer tijd voor de substantiële beoordeling.

Adoptie en organisatorische randvoorwaarden

De vijf workflowprincipes werken alleen als de organisatorische context hun implementatie ondersteunt. Drie factoren zijn hierbij beslissend: workflow-compatibiliteit, vertrouwen en sociaal draagvlak, en professionele differentiatie.

Russo (2024) identificeerde in zijn mixed-methods adoptiestudio (HACAF-framework) workflow-compatibiliteit als de sterkste adoptiefactor — sterker dan waargenomen nut of sociale invloed. AI-tools die naadloos aansluiten op bestaande werkprocessen worden structureel geadopteerd; tools die het werkproces doorbreken worden gemeden, ook al zijn ze objectief beter. Dit heeft directe implicaties voor de introductie van AI-workflows in teams: de workflow moet worden ingepast bij bestaande praktijken en geleidelijk worden uitgebreid, niet als totale herinrichting worden opgelegd.

Banh et al. (2025) benadrukken via hun sociotechnisch adoptieframework (18 SE-expertinterviews) dat succesvolle GenAI-integratie organisatorische alignment vereist: heldere governance over wanneer en hoe AI wordt gebruikt, organisatorisch beleid dat vertrouwen en experimenteerruimte biedt, en stapsgewijze integratie die ruimte geeft voor bijsturing. Sergeyuk et al. (2024) bevestigen dat vertrouwen en bedrijfsbeleid twee van de meest genoemde barrières zijn voor AI-gebruik — en dat het ontbreken van projectbrede context in AI-assistenten een derde, technische barrière vormt die toolselectie mede bepaalt.

Shao & Ishengoma (2026) leggen een opmerkelijk professioneel-differentiatie-effect bloot: professionals passen systematisch verfijningsstrategieën toe bij AI-output (maintainability, architectuuralignment), terwijl studenten primair gericht zijn op een werkend eindproduct. Dit verschil in eigenaarschapscultuur is relevant voor teams die AI introduceren: zonder expliciete normvorming over kwaliteitsrefinement als verwachte werkwijze, glijdt het team naar het laagste niveau. Yu et al. (2026) bevestigen dit in een multi-casestudie: de kwaliteit van GenAI-toepassingen in de praktijk varieert sterk en is afhankelijk van organisatorische inbedding en kwaliteitsborging. Hao et al. (2024) voegen hier het principe van transparantie aan toe: het publiek delen van ChatGPT-gesprekken in PR’s en issues — een praktijk die zij bij 580 GitHub-threads analyseerden — functioneert als traceerbaarheidsartefact dat de kwaliteit van AI-gebruik zichtbaar maakt en toetsbaar houdt.

Aanbevolen werkstroom

Geïntegreerde conclusie

De bestudeerde studies convergeren naar een coherente kern: AI-codeassistentie levert aantoonbare voordelen op, maar uitsluitend wanneer het wordt ingezet als een bewust bestuurde, meerstaps workflow — niet als ad-hoc inspiratiebron of taakuitbesteding. De centrale paradox in de literatuur is dat de grootste productiviteitsrisico’s optreden wanneer AI het beste lijkt te werken: bij snelle suggesties die direct worden overgenomen, accumuleren code smells, beveiligingsproblemen en eigenaarschapsschade sluipend. De grootste bescherming is niet minder AI, maar betere werkprocessen.

De vijf kernprincipes die consistent door de literatuur naar voren komen — taakafstemming, specificatie-eerst, expliciete verificatie, structurele kwaliteitsborging en bewust eigenaarschap — zijn geen onafhankelijke tips, maar een samenhangend systeem. Elk principe versterkt de andere principes. Goede specificatie maakt verificatie efficiënter. Expliciete verificatie beschermt het eigenaarschap. Structurele kwaliteitsborging maakt taakafstemming haalbaar. En bewust eigenaarschap geeft de grenzen aan waarbinnen de andere principes opereren. De zeven stappen hieronder operationaliseren deze vijf principes voor dagelijks werk.

De zeven stappen

De onderstaande werkstroom is gebaseerd op het gewogen bewijs uit de geselecteerde empirische en conceptuele studies. Ze is bedoeld als dagelijks bruikbare handleiding, niet als ideaalplaatje.

Stap 1 — Taakafstemming: beslis vóórdat je start

Stel jezelf twee vragen vóórdat je AI opent:

1. Wat voor taak is dit?
   • Acceleratietaak: ik weet wat ik wil, AI helpt me sneller — directe AI-input is gepast.
   • Exploratietaak: ik ben onzeker over richting — gebruik AI om opties te genereren, evalueer kritischer.
2. Wat is de risicograad?
   • Laag: boilerplate, testgeneratie, docstrings, refactoring van geïsoleerde functies — AI-delegatie is veilig.
   • Hoog: beveiligingskritische code, architectuurbeslissingen, compliance-gerelateerde logica, systeemdefinitie — beperk AI-gebruik; menselijk oordeel is niet overdraagbaar.

Bewijs: Barke et al. (2023), Vigh et al. (2026), Li et al. (2026), Sergeyuk et al. (2024), Li et al. (2024).

Stap 2 — Specificatie: maak intentie en context expliciet

Formuleer vóór het prompten:

• Wat wil je bereiken? (functionele intentie)
• Welke constraints gelden? (architectuur, taalconventies, performancevereisten, beveiligingsstandaarden)
• Welke context heeft het AI-model nodig? (relevante bestaande code, interfaces, afhankelijkheden)
• Wat is expliciet buiten scope? (formuleer wat je niet wil)

Gebruik bij complexere vereisten een verduidelijkingsvraag aan de AI vóórdat je om code vraagt: “Begrijp je de intentie? Stel vragen voordat je genereert.”

Als de input uit tickets, gebruikersfeedback of supportkanalen komt, gebruik AI hooguit om thema’s te clusteren of een eerste requirementspecificatie te formuleren. Valideer daarna zelf of de functionele intentie, NFR’s en prioriteit kloppen voordat je de AI om implementatie vraagt.

Bewijs: Mu et al. (2024), Ullrich et al. (2025), Mallya et al. (2025), Liang et al. (2024), Gerlich (2025), Sarkar et al. (2024).

Stap 3 — Generatie: stuur, vertrouw niet blind

Genereer de code, maar positioneer de AI-output als conceptversie, niet als definitieve code.

• Gebruik korte, taakgerichte sessies (1–3 iteraties) voor duidelijk omschreven deeltaken.
• Geef de AI expliciete feedback als een versie de intentie mist — niet “dit klopt niet”, maar “dit mist X vanwege Y”.
• Wees bereid om een sessie te stoppen als de AI structureel niet de juiste context heeft; de investering in verdere sturing wordt dan groter dan zelf schrijven.

Bewijs: Li et al. (2026), Becker et al. (2025), Ogenrwot & Businge (2026).

Stap 4 — Verificatie: gestructureerd en tijdsgebonden

Verifieer AI-output systematisch en gestructureerd:

• Leesbegrijpelijkheid: begrijp je elke regel zelf? Zo niet — herschrijf of vraag uitleg.
• Functionele correctheid: voer de code uit (handmatig of via unit-test) op representatieve input.
• Architectuurconformiteit: past dit bij de bestaande codeconventies, naamgeving en structuur?
• Niet-functionele aspecten: heb je nagedacht over leesbaarheid voor de volgende developer, geheugengebruik, foutafhandeling?

Baken verificatie in tijd: stel een tijdslimiet per sessie. Verificatiebelasting neemt toe bij vermoeidheid — neem een pauze als je merkt dat je oppervlakkiger controleert.

Bewijs: Mozannar et al. (2024), Fan et al. (2026), Becker et al. (2025), Adalsteinsson et al. (2025).

Stap 5 — Kwaliteitsborging: statische analyse en review als vaste schakels

Voer altijd kwaliteitsborging uit na AI-generatie, ongeacht hoe overtuigend de output er uitziet:

• Statische analyse: run SonarQube, Pylint, ESLint of een equivalent op AI-gegenereerde code vóórdat die in review gaat. AI-output heeft een structureel hogere kans op code smells (Liu et al., 2026).
• Beveiligingsvalidatie: gebruik een dedicated security-scanner (bijv. Snyk, Semgrep) bij beveiligingsgevoelige code. Vertrouw niet op de AI-verklaring dat iets veilig is (Tessa et al., 2026; Berabi et al., 2024).
• Testdekking: AI-tests zijn initieel sterk, maar degraderen bij codewijzigingen. Beoordeel AI-testsuites opnieuw bij elke significante refactoring of functiewijziging (Haroon et al., 2026).
• Contextspecifieke kwaliteitscriteria: leg per codebase vast welke niet-functionele eisen in deze wijziging echt tellen, zoals onderhoudbaarheid, foutafhandeling, performance of domeinconformiteit. Generieke metrics zijn nuttig, maar niet genoeg (Sun et al., 2026; Yu et al., 2026).
• Documenteer het AI-gebruik: maak AI-bijdragen zichtbaar in commits of PR-beschrijvingen (Hao et al., 2024; Ogenrwot & Businge, 2026). Dit ondersteunt reviewers en houdt eigenaarschap traceerbaar.

Bewijs: Liu et al. (2026), Agarwal et al. (2026), Sun et al. (2026), Patcas & Motogna (2026), Haroon et al. (2026), Tessa et al. (2026).

Stap 6 — Codereview: AI als eerste filter, mens als finale poort

In de review-fase gelden de volgende rollen:

Auteur:

• Dien code in met vermelding van AI-bijdragen en de verificatiestappen die al doorlopen zijn.
• Voeg relevante context toe die de reviewer helpt bij de beoordeling.

Reviewer:

• Gebruik AI-review (indien beschikbaar) als eerste filter voor coding conventions, style en bekende patronen.
• Reserveer je menselijke aandacht voor semantisch begrip, architectuurconformiteit, eigenaarschapsvraagstukken en risico-inschatting.
• Peer review is niet vervangbaar door AI-review: het is ook het moment van kennisoverdracht en gedeeld eigenaarschap (Bacchelli & Bird, 2013; Alami et al., 2025).

Bewijs: Bacchelli & Bird (2013), Alami et al. (2025), Vijayvergiya et al. (2024), Adalsteinsson et al. (2025), Cihan et al. (2025), Wadhwa et al. (2024).

Stap 7 — Reflectie: houd eigenaarschap actief

Op individueel niveau:

• Stel jezelf na elke AI-sessie: begrijp ik de code die ik ga committen? Kan ik hem uitleggen aan een collega? Kan ik hem onderhouden over zes maanden?
• Behandel AI-output als startpunt, niet als eindpunt. De mediaan van 25 procent integratie in real-world PR’s (Ogenrwot & Businge, 2026) is een ijkpunt: selectiviteit is professioneel standaard, niet twijfel aan de tool.

Op teamniveau:

• Bespreek regelmatig welke delen van de codebase hoge en lage AI-inzet rechtvaardigen.
• Neem technische schuld van AI-gegenereerde code mee in sprint-retrospectives (Liu et al., 2026).
• Cultiveer expliciete kwaliteitsnormen voor AI-output refinement — het verschil tussen professionele en studentgebruikers is grotendeels dit (Shao & Ishengoma, 2026).

Bewijs: Sarkar et al. (2024), Gerlich (2025), Alami & Ernst (2024), Alami et al. (2025), Chen et al. (2026), Shao & Ishengoma (2026).

Praktische definitie van klaar

Voor dagelijks teamgebruik kan de werkstroom worden samengevat als een minimale definition of done voor AI-ondersteund werk. Een AI-bijdrage is pas klaar wanneer:

• taaktype en risicograad vooraf zijn benoemd;
• de gebruikte requirements, tickets of feedback zijn vertaald naar concrete constraints en waar nodig menselijk gevalideerd;
• de auteur de gegenereerde code begrijpt, kan uitleggen en zelf wil onderhouden;
• tests, statische analyse, security-checks en relevante contextspecifieke kwaliteitscriteria zijn doorlopen;
• AI-gebruik en verificatiestappen zichtbaar zijn voor de reviewer;
• een menselijke reviewer het finale oordeel geeft over semantiek, architectuurfit en eigenaarschap.

Deze definitie maakt de synthese praktisch toepasbaar zonder de nuance van de literatuur te verliezen: AI mag versnellen, maar alleen binnen een werkproces waarin specificatie, verificatie, kwaliteitscriteria en menselijke verantwoordelijkheid expliciet blijven.

Grenzen van de conclusie

Elke synthese vereist eerlijkheid over de grenzen van de conclusies. Drie boundary conditions zijn relevant:

1. Ervaringsniveau bepaalt de productiviteitsbalans. Minder ervaren developers profiteren sterker van AI (Cui et al., 2025), terwijl ervaren developers in vertrouwde codebases op netto-tijdsverlies kunnen uitkomen (Becker et al., 2025). Stap 1 (taakafstemming) en stap 4 (verificatietijd) zijn extra kritisch voor ervaren developers.

2. Projectfase, taaktype en -rijpheid. In repositories waar agents de eerste observeerbare AI-tool zijn, vinden Agarwal et al. (2026) vooral kortetermijnwinst in velocity; in omgevingen met eerdere AI-tooling is dat effect zwakker. In rijpe, grote codebases met complexe afhankelijkheden zijn de kwaliteitsrisico’s en verificatiekosten het hoogst. Afgebakende implementatietaken profiteren eerder; legacy-integratie en architectuurwerk het minst (Li et al., 2024; Becker et al., 2025). Autonome agents vereisen in rijpe projecten de zwaarste kwaliteitsborging.

3. Organisatorische context. Zonder governance, vertrouwen en een expliciete kwaliteitscultuur werken individuele workflowprincipes onvoldoende (Russo, 2024; Banh et al., 2025). De werkstroom werkt het best in een team dat gezamenlijke normen deelt over AI-gebruik, kwaliteitsstandaarden en eigenaarschap.

Samenvatting: de zeven stappen in één overzicht

Gebruikte bronnen en rol in de synthese

De tabel hieronder laat zien welke bronnen de hoofdargumentatie dragen en welke bronnen vooral als context of praktijkbewijs zijn gebruikt.

Referenties

Adalsteinsson, G. H., et al. (2025). Rethinking code review workflows with LLM assistance. Proceedings of the 2025 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, 488-497. https://doi.org/10.1109/ESEM64174.2025.00013

Agarwal, S., et al. (2026). AI IDEs or autonomous agents? Measuring the impact of coding agents. Proceedings of MSR 2026. https://doi.org/10.1145/3793302.3793589

Alami, A., & Ernst, N. A. (2024). Understanding the building blocks of accountability in software engineering. Empirical Software Engineering.

Alami, A., et al. (2025). Accountability in code review: The role of intrinsic drivers and the impact of LLMs. ACM Transactions on Software Engineering and Methodology, 34(8), 1-44. https://doi.org/10.1145/3721127

Bacchelli, A., & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. Proceedings of the 35th International Conference on Software Engineering (ICSE), 712–721.

Banh, L., et al. (2025). Copiloting the future: How GenAI transforms software engineering. Information and Software Technology, 183, 107751. https://doi.org/10.1016/j.infsof.2025.107751

Barke, S., James, M. B., & Polikarpova, N. (2023). Grounded Copilot: How programmers interact with code-generating models. Proceedings of the ACM on Programming Languages, 7(OOPSLA1), 85–111.

Becker, J., et al. (2025). Measuring the impact of early-2025 AI on experienced OSS developer productivity. METR Technical Report. https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf

Berabi, B., et al. (2024). DeepCode AI Fix: Fixing security vulnerabilities with large language models. ICML 2024.

Chen, V., et al. (2026). Beyond the commit: Developer perspectives on productivity with AI coding assistants. Proceedings of ICSE-SEIP 2026. https://doi.org/10.1145/3786583.3786848

Cihan, T., et al. (2025). Evaluating large language models for code review. arXiv:2505.20206.

Cui, Z., et al. (2025). The effects of generative AI on high-skilled work: Evidence from three field experiments with software developers. SSRN Working Paper, No. 4945566. https://doi.org/10.2139/ssrn.4945566

Della Porta, J., et al. (2025). Do prompt patterns affect code quality? Proceedings of the 29th International Conference on Evaluation and Assessment in Software Engineering, 181-192. https://doi.org/10.1145/3756681.3756938

Fan, G., et al. (2026). When help hurts: Verification load and fatigue with AI coding assistants. Proceedings of CHI 2026. https://doi.org/10.1145/3772318.3791176

Gerlich, M. (2025). From offloading to engagement: An experimental study on structured prompting and critical reasoning with generative AI. Data, 10, 172. https://doi.org/10.3390/data10110172

Hao, Y., et al. (2024). Developers’ shared conversations with ChatGPT in GitHub pull requests and issues. Empirical Software Engineering, 29(6). https://doi.org/10.1007/s10664-024-10540-x

Haroon, S., Khan, M. T., & Gulzar, M. A. (2026). Evaluating LLM-based test generation under software evolution. arXiv:2603.23443.

Li, M., et al. (2024). Prompting LLMs to tackle the full SDLC: DevEval. arXiv preprint.

Li, R., et al. (2026). Unveiling the role of ChatGPT in software development: Insights from developer-ChatGPT interactions on GitHub. ACM Transactions on Software Engineering and Methodology.

Liang, J., et al. (2024). Usability of AI programming assistants: Successes and challenges. Proceedings of ICSE 2024, 1-13. https://doi.org/10.1145/3597503.3608128

Lin, B., et al. (2024). Improving automated code reviews: Learning from experience. Proceedings of MSR 2024, 278-283. https://doi.org/10.1145/3643991.3644910

Liu, Y., et al. (2026). Debt behind the AI boom: A large-scale empirical study of AI-generated code in the wild. arXiv:2603.28592.

Mallya, M. A., Ferrari, A., Zadenoori, M. A., & Dąbrowski, J. (2025). From online user feedback to requirements: Evaluating large language models for classification and specification tasks. arXiv:2510.23055.

Mohamed, A., et al. (2025). The impact of LLM-assistants on software developer productivity: A systematic review and mapping study. arXiv:2507.03156.

Mozannar, H., et al. (2024). Reading between the lines: Modeling user behavior and costs in AI-assisted programming. Proceedings of CHI 2024.

Mu, F., et al. (2024). ClarifyGPT: A framework for enhancing LLM-based code generation via requirements clarification. Proceedings of the ACM on Software Engineering, 1(FSE), 2332-2354. https://doi.org/10.1145/3660810

Ogenrwot, D., & Businge, J. (2026). PatchTrack: A comprehensive analysis of ChatGPT’s influence on pull request outcomes. Empirical Software Engineering, 31(5). https://doi.org/10.1007/s10664-026-10869-5

Patcas, R., & Motogna, S. (2026). An evaluation study of large language models for addressing code quality issues. Empirical Software Engineering, 31, 118. https://doi.org/10.1007/s10664-026-10858-8

Peng, Y., Kim, K., Meng, L., & Liu, K. (2025). iCodeReviewer: Improving secure code review with mixture of prompts. arXiv:2510.12186.

Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology.

Sarkar, A., et al. (2024). AI should challenge, not obey. Communications of the ACM, 67(10), 18-21. https://doi.org/10.1145/3673413 (Preprint: arXiv:2412.15030)

Sergeyuk, A., et al. (2024). Using AI-based coding assistants in practice: State of affairs, perceptions, and ways forward. Information and Software Technology. https://doi.org/10.1016/j.infsof.2024.107610

Shao, D., & Ishengoma, F. (2026). Empirical analysis of generative AI tool adoption in software development. Information and Software Technology, 192, 108036.

Simões, M., & Venson, E. (2024). Evaluating source code quality with large language models. arXiv preprint.

Song, Y., et al. (2024). The impact of generative AI on collaborative OSS development. arXiv:2410.02091.

Sun, X., et al. (2026). Quality assurance of LLM-generated code: Addressing non-functional quality characteristics. Journal of Systems and Software, 238, 112885. https://doi.org/10.1016/j.jss.2026.112885

Tessa, M., et al. (2026). How secure is secure code generation? Adversarial prompts put LLM defenses to the test. arXiv:2601.07084.

Tony, C., et al. (2024). Prompting techniques for secure code generation. arXiv preprint.

Ullrich, J., et al. (2025). From requirements to code: Developer practices in LLM-assisted software engineering. Proceedings of IEEE RE 2025. https://doi.org/10.1109/RE63999.2025.00032

Vijayvergiya, M., et al. (2024). AI-assisted assessment of coding practices in modern code review. Proceedings of the 1st ACM International Conference on AI-Powered Software (AIware ’24), 85-93. https://doi.org/10.1145/3664646.3665664

Vigh, E., Sunesen, F., & Barkhuus, L. (2026). “AI does not understand the real world”: AI augmented software development. CHI EA ’26.

Wadhwa, N., et al. (2024). CORE: Resolving code quality issues using LLMs. Proceedings of the ACM on Software Engineering, 1(FSE), 789-811. https://doi.org/10.1145/3643762

Watanabe, M., et al. (2026). On the use of agentic coding: An empirical study of pull requests on GitHub. ACM Transactions on Software Engineering and Methodology.

Yu, L., et al. (2026). Evaluating the quality of GenAI applications in software engineering: A multi-case study. Empirical Software Engineering, 31, 29. https://doi.org/10.1007/s10664-025-10759-2

AI-verklaring

AI is gebruikt als ondersteuning bij het structureren van deze literatuursynthese, het vergelijken van bronnen, het controleren van consistentie tussen brongebruik en argumentatie, en het aanscherpen van formuleringen. De inhoudelijke keuzes, bronweging, interpretatie, eindredactie en verantwoordelijkheid voor de definitieve tekst blijven bij de auteur.