AI kan prima code schrijven. De vraag is wie er daarna nog oplet
Er is iets verleidelijks aan AI-code die er meteen goed uitziet.
Je vraagt om een kleine wijziging. De assistent denkt even na. Daarna verschijnt er een patch met nette functienamen, redelijke tests en een samenvatting die klinkt alsof iemand met een clipboard door de codebase is gelopen.
Build groen. Tests groen. AI-summary groenig van toon.
Dan komt het moment waarop je eigenlijk even moet vertragen.
Begrijp ik deze code zelf? Past dit bij de rest van het systeem? Is dit echt getest, of vooral geruststellend aangekleed? Kan ik dit over zes maanden nog uitleggen aan een collega zonder te wijzen naar een chatvenster?
Dat is voor mij de kern van AI-assisted software development. Niet de vraag of AI code kan schrijven. Dat weten we inmiddels. De betere vraag is: wat blijft er van onze engineeringstandaarden over nadat AI iets heeft geschreven?
Het probleem is niet dat AI helpt
AI-codeassistenten zijn niet meer experimenteel. Ze zitten in editors, chattools, agents, pull requests en reviewflows. Ze schrijven boilerplate, tests, documentatie, scripts, refactors en soms ook dingen waarvan je pas later denkt: wacht even, waarom is hier een tweede cachelaag ontstaan?
Dat klinkt cynisch, maar zo bedoel ik het niet.
AI kan echt helpen. Zeker bij duidelijk afgebakende taken. Een test opzetten. Een API-call uitschrijven. Een bestaande functie aanpassen volgens een zichtbaar patroon. Een foutmelding verklaren. Een eerste reviewlijst maken. Dat zijn momenten waarop AI voelt als iemand die alvast de steigers neerzet terwijl jij nog naar de bouwtekening kijkt.
De literatuur laat dat ook zien. In grote veldstudies leveren AI-tools gemiddeld productiviteitswinst op. Developers ronden meer taken af, maken meer commits en komen sneller door routinematig werk heen. Vooral minder ervaren developers kunnen daarvan profiteren, omdat ze minder tijd kwijt zijn aan syntax, boilerplate en zoeken (Cui et al., 2025).
Maar gemiddeld is een gevaarlijk woord.
Gemiddeld vertelt niet wat er gebeurt in een oude codebase met impliciete conventies. Gemiddeld vertelt niet hoeveel tijd je kwijt bent aan controleren. Gemiddeld vertelt niet of de developer de code nog begrijpt. En gemiddeld vertelt al helemaal niet of het team over drie maanden blij is met wat vandaag snel werd geaccepteerd. Productiviteit is meer dan commits; het gaat ook om begrip, onderhoudbaarheid en eigenaarschap (Chen et al., 2026).
Snel voelt niet altijd sneller
Een van de interessantste bevindingen uit de recente literatuur is juist dat ervaren developers soms langzamer worden met AI (Becker et al., 2025).
Niet omdat ze AI niet kunnen gebruiken. Niet omdat ze terug willen naar de typemachine. Maar omdat ze — in het experiment van Becker en collega’s — werkten in eigen, vertrouwde open-source projecten, met conventies en impliciete kennis die niet allemaal in de prompt passen.
In zo’n omgeving is een AI-suggestie vaak bijna goed.
Bijna goed is verraderlijk.
Helemaal fout herken je snel. Dan gaat de suggestie weg en schrijf je zelf verder. Maar bijna goed vraagt aandacht. Je leest. Je vergelijkt. Je past aan. Je denkt: dit is op zich netjes, maar niet hoe wij errors afhandelen. Of: deze test test de mock, niet het gedrag. Of: deze oplossing werkt voor het voorbeeld, maar vergeet de randgevallen waar productie altijd op lijkt te wachten.
Daar zit de verborgen rekening.
AI bespaart schrijftijd, maar voegt verificatietijd toe. En die verificatietijd is niet gratis. Onderzoek naar AI-assisted programming laat zien dat developers veel tijd kwijt zijn aan lezen, beoordelen en herstellen van AI-output (Mozannar et al., 2024). Andere studies laten zien dat verificatiebelasting kan opstapelen: hoe langer je achter elkaar AI-output controleert, hoe groter de kans dat je oppervlakkiger gaat kijken (Fan et al., 2026).
Dat herken ik ook uit de praktijk. De eerste suggestie controleer je scherp. Bij de vijfde denk je sneller: ja, ziet er logisch uit. Dat is precies het moment waarop je eigenlijk koffie nodig hebt, geen mergeknop.
De eerste vraag is: is dit wel een AI-taak?
Een goede AI-workflow begint niet met een prompt.
Hij begint met de vraag of je deze taak überhaupt aan AI moet geven.
Er is een nuttig onderscheid tussen twee modi. In de eerste modus weet je wat je wilt. Je gebruikt AI als versneller. De taak is klein, de richting is helder en je kunt de output snel beoordelen. Denk aan een testvariant, een refactor binnen een bekend patroon, een stukje documentatie of het uitschrijven van saaie maar noodzakelijke code (Barke et al., 2023).
In de tweede modus weet je nog niet precies wat je wilt. Je gebruikt AI om opties te verkennen. Dat kan nuttig zijn, maar het vraagt zwaardere controle. Want als jij de richting nog niet kent, kan AI heel overtuigend de verkeerde kant op lopen. Met keurige variabelenamen. Dat helpt niet.
Daar komt nog iets bij: AI begrijpt niet vanzelf jouw wereld. Niet de codebase, niet de gebruikers, niet het beleid, niet het release-risico. In interviews met developers komt precies die grens terug: AI kan helpen met een taak, maar mist vaak de real-world context waarin die taak betekenis krijgt (Vigh et al., 2026).
Daarom hoort er nog een tweede vraag bij: wat is de risicograad?
Voor boilerplate is AI vaak prima. Voor securitygevoelige code, architectuurbeslissingen, compliance-logica of release-inschatting ligt dat anders. Daar kun je AI laten meedenken, maar het oordeel blijft menselijk. Niet ceremonieel menselijk. Echt menselijk. Iemand moet begrijpen wat er gebeurt en verantwoordelijkheid nemen voor wat er wordt ingecheckt.
Dat is geen nostalgie naar handwerk. Dat is professioneel eigenaarschap.
Specificatie is geen papierwerk
Veel slechte AI-output begint met een te makkelijke opdracht.
“Maak deze functie af.”
“Fix deze bug.”
“Schrijf tests.”
Dat klinkt efficiënt. Het is meestal gewoon vaag.
AI vult de gaten op. Dat is zijn werk. Alleen vult het model die gaten niet met jouw domeinkennis, jouw releasecontext of de afspraken die drie jaar geleden in een pull request zijn ontstaan en daarna nooit meer zijn opgeschreven. Het vult ze met waarschijnlijkheid.
Soms is dat goed genoeg. Vaak net niet.
Daarom is specificatie een van de belangrijkste stappen in AI-assisted development. Requirements clarification kan de kwaliteit van gegenereerde code aantoonbaar verbeteren, juist omdat het model minder hoeft te gokken (Mu et al., 2024). Niet als zwaar document. Wel als expliciete voorbereiding:
- Wat moet er functioneel gebeuren?
- Welke constraints gelden hier?
- Welke bestaande code of interface is leidend?
- Wat valt juist buiten scope?
- Welke risico’s moeten getest of gereviewd worden?
Dat voelt misschien als vertragen, maar het is de goedkoopste plek om fouten te voorkomen. Een onduidelijke prompt produceert een onduidelijke patch. Daarna mag jij de archeoloog spelen in je eigen diff. Met een beetje pech vind je nog aardewerk ook.
Goede specificatie maakt AI niet magisch. Het maakt AI begrensd. En begrensd is precies wat je wilt in softwareontwikkeling. Het doel is niet om denken uit te besteden, maar om betrokken te blijven terwijl AI de wrijving verlaagt (Gerlich, 2025; Sarkar et al., 2024).
Verificatie is waar het echte werk zit
De belangrijkste workflowregel is simpel:
AI-output is een conceptversie.
Niet een beslissing. Niet een bewijs. Niet een mini-collega die alvast verantwoordelijkheid heeft genomen. Een conceptversie.
Daarom moet verificatie expliciet zijn. Niet even scrollen. Niet “de tests draaien, dus prima”. Maar bewust controleren wat de wijziging doet.
Ik kijk daarbij naar vier dingen.
Ten eerste: begrijp ik de code zelf? Als ik een regel niet kan uitleggen, is dat geen teken dat AI slim is. Dat is een teken dat ik nog niet klaar ben.
Ten tweede: klopt het gedrag? Niet alleen voor het voorbeeld in de prompt, maar ook voor representatieve input en randgevallen.
Ten derde: past het in de codebase? Naamgeving, foutafhandeling, logging, performance, afhankelijkheden, teststijl. AI schrijft vaak generiek nette code. Een codebase vraagt specifiek passende code.
Ten vierde: wat zijn de niet-functionele gevolgen? Onderhoudbaarheid, security, leesbaarheid, observability. De saaie woorden waar productie op draait.
Hier helpt tooling. Tests, linters, typechecks, static analysis, security scanners. Niet omdat tooling alles ziet. Wel omdat tooling consequent ziet wat mensen op vrijdagmiddag graag overslaan.
De literatuur is daar vrij duidelijk over: AI-output introduceert structureel kwaliteitsproblemen. In een grootschalige studie van ruim 300.000 AI-gegenereerde commits bleef 22,7 procent van de gevonden issues hangen in de laatste repositoryversie, met code smells als veruit dominant probleemtype (Liu et al., 2026). Bij security is het nog gevoeliger. Onderzoek naar secure code generation laat zien dat “veilig” en “werkend” niet vanzelf samen vallen, zeker niet onder adversarial prompting (Tessa et al., 2026). Een model dat zegt dat code veilig is, heeft geen autoriteit. Het heeft tekst geproduceerd. Dat is iets anders.
Review wordt belangrijker, niet minder belangrijk
Een misverstand over AI is dat het review minder nodig maakt.
Ik denk dat het omgekeerde waar is.
AI kan de eerste laag helpen. Het kan conventies signaleren, verdachte patronen aanwijzen, een diff samenvatten of vragen voorstellen voor de reviewer. Dat is nuttig; bij Google is AI bijvoorbeeld juist als eerste filter voor coding practices ingezet, zodat menselijke reviewers meer aandacht overhouden voor inhoud en ontwerp (Vijayvergiya et al., 2024). Niemand wordt een betere engineer van de twaalfde opmerking over formatting.
Maar peer review is meer dan foutopsporing.
Review is ook kennisoverdracht. Het is teamgeheugen. Het is de plek waar iemand vraagt: waarom doen we dit eigenlijk zo? Het is de plek waar impliciete standaarden expliciet worden. En het is een sociaal moment van accountability: ik lever iets in bij mensen met wie ik morgen weer werk (Bacchelli & Bird, 2013).
Een AI-review kan daar niet zomaar voor invallen. Je kunt verantwoording voelen richting een teamgenoot. Richting een model werkt dat anders (Alami et al., 2025).
Dat betekent niet dat AI uit review moet blijven. Het betekent dat AI een filter mag zijn, geen finale poort. Laat AI de makkelijke signalen verzamelen. Laat mensen oordelen over semantiek, architectuur, risico en eigenaarschap.
De reviewer moet uiteindelijk niet vragen: “Heeft AI hier iets van gevonden?”
De reviewer moet vragen: “Begrijpt de auteur deze wijziging, en past dit bij wat wij als team willen onderhouden?”
Eigenaarschap is niet overdraagbaar
Dit is misschien het meest praktische punt.
Als ik code commit, is het mijn code.
Ook als AI hem heeft voorgesteld. Ook als een agent hem heeft geschreven. Ook als de suggestie er beter uitzag dan mijn eerste versie. De repository kent geen moreel voetnootje waarin staat: “Niet boos worden, dit kwam uit een model.” Als code fout is, is “AI schreef het” geen verdediging (Vigh et al., 2026).
Eigenaarschap betekent niet dat je alles zelf moet typen. Dat is een romantisch maar onpraktisch idee. Eigenaarschap betekent dat je snapt wat je accepteert. Dat je kunt uitleggen waarom deze oplossing past. Dat je weet welke checks zijn gedaan. Dat je de risico’s durft te noemen. En dat je bereid bent de code later te onderhouden.
Daarom vind ik de vraag “hoeveel code heeft AI geschreven?” niet zo interessant. Die vraag zegt vooral iets over herkomst.
De betere vraag is: hoeveel van de AI-output is begrepen, aangepast, getest en bewust geaccepteerd?
In studies naar pull requests met ChatGPT-gebruik zie je dat developers AI-patches vaak niet volledig overnemen. Ze selecteren, wijzigen, herschrijven en combineren (Ogenrwot & Businge, 2026). Dat is geen zwakte van de tool. Dat is hoe professioneel gebruik eruitziet.
AI mag een startpunt zijn. Het mag zelfs een heel goed startpunt zijn. Maar het eindpunt blijft menselijk oordeel.
Een werkstroom die wel werkt
Als je AI in development serieus wilt gebruiken, heb je geen groot manifest nodig. Je hebt een werkstroom nodig die saai genoeg is om vol te houden.
Voor mij komt die neer op zeven stappen:
- Bepaal eerst of de taak geschikt is voor AI.
- Maak intentie, context en constraints expliciet.
- Laat AI een kleine conceptversie maken.
- Controleer de output gestructureerd.
- Draai tests, static analysis en waar nodig security-checks.
- Gebruik review als menselijke finale poort.
- Maak AI-gebruik en verificatie zichtbaar in de overdracht.
Dat klinkt minder spectaculair dan “agent bouwt feature zelfstandig”.
Mooi.
Spectaculair is niet het doel. Werkende software die mensen durven aanpassen is het doel.
De beste AI-workflow voelt daarom niet als magie. Hij voelt als normaal professioneel werk, maar met een snelle assistent in de buurt. De tool doet ertoe, maar de workflow eromheen minstens zo veel. Die assistent kan veel, maar hij kent jouw systeem niet zoals je team het kent. Hij voelt geen productierisico. Hij hoeft de code over zes maanden niet uit te leggen. Hij zit niet in de retro wanneer iemand vraagt waarom de complexiteit ineens omhoog is gegaan.
Jij wel.
De vraag die blijft hangen
Ik ben niet tegen AI in softwareontwikkeling. Integendeel. Ik gebruik het graag, juist omdat het veel werk sneller, scherper en overzichtelijker kan maken.
Maar ik wil niet dat snelheid wordt verward met kwaliteit.
Een AI-patch die snel verschijnt, is nog geen afgeronde wijziging. Het is een voorstel. Soms een goed voorstel. Soms een voorstel met nette schoenen en modder aan de zolen. Snelle code kan nog steeds schuld achterlaten als validatie en review zwakker worden (Liu et al., 2026; Sun et al., 2026).
De professionele vraag is dus niet: kunnen we AI code laten schrijven?
De vraag is: kunnen we AI gebruiken zonder onze eigen standaarden uit handen te geven?
Daar begint het echte werk. Niet bij de prompt. Bij wat je daarna doet.
Bronnen
Dit artikel is gebaseerd op de literatuursynthese AI als versneller, niet als vervanger.
Alami, A., Jensen, V., & Ernst, N. (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, 712-721.
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., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity. arXiv. https://doi.org/10.48550/arXiv.2507.09089
Chen, V., He, J., Williams, B., Valentino, J., & Talwalkar, A. (2026). Beyond the commit: Developer perspectives on productivity with AI coding assistants. arXiv. https://doi.org/10.48550/arXiv.2602.03593
Cui, Z., Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2025). The effects of generative AI on high-skilled work: Evidence from three field experiments with software developers. SSRN. https://doi.org/10.2139/ssrn.4945566
Fan, G., Liu, D., Pan, L., & Zhang, R. (2026). When help hurts: Verification load and fatigue with AI coding assistants. Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems, 1-25. 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(11), 172. https://doi.org/10.3390/data10110172
Liu, Y., Widyasari, R., Zhao, Y., Irsan, I. C., Chen, J., & Lo, D. (2026). Debt behind the AI boom: A large-scale empirical study of AI-generated code in the wild. arXiv. https://doi.org/10.48550/arXiv.2603.28592
Mozannar, H., Bansal, G., Fourney, A., & Horvitz, E. (2024). Reading between the lines: Modeling user behavior and costs in AI-assisted programming. Proceedings of the CHI Conference on Human Factors in Computing Systems, 1-16. https://doi.org/10.1145/3613904.3641936
Mu, F., Shi, L., Wang, S., Yu, Z., Zhang, B., Wang, C., Liu, S., & Wang, Q. (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
Sarkar, A., Xu, X., Toronto, N., Drosos, I., & Poelitz, C. (2024). When Copilot becomes Autopilot: Generative AI’s critical risk to knowledge work and a critical solution. arXiv. https://doi.org/10.48550/arXiv.2412.15030
Sun, X., Ståhl, D., Sandahl, K., & Kessler, C. (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., Olatunji, I. E., War, A., Klein, J., & Bissyande, T. F. (2026). How secure is secure code generation? Adversarial prompts put LLM defenses to the test. arXiv. https://doi.org/10.48550/arXiv.2601.07084
Vigh, E., Sunesen, F., & Barkhuus, L. (2026). “AI does not understand the real world.”: AI augmented software development. Proceedings of the Extended Abstracts of the 2026 CHI Conference on Human Factors in Computing Systems, 1-5. https://doi.org/10.1145/3772363.3799079
Vijayvergiya, M., Salawa, M., Budiselić, I., Zheng, D., Lamblin, P., Ivanković, M., Carin, J., Lewko, M., Andonov, J., Petrović, G., Tarlow, D., Maniatis, P., & Just, R. (2024). AI-assisted assessment of coding practices in modern code review. Proceedings of the 1st ACM International Conference on AI-Powered Software, 85-93. https://doi.org/10.1145/3664646.3665664
AI-verklaring
AI is gebruikt als ondersteuning bij het omzetten van de literatuursynthese naar een publieksgericht blogartikel, inclusief structuur, formulering en consistentiecontrole. De inhoudelijke keuzes, broninterpretatie, eindredactie en verantwoordelijkheid voor de definitieve tekst blijven bij de auteur.