Als je op social media kijkt, of de berichtgeving van TechEd-bedrijven volgt, lijkt softwareontwikkeling tegenwoordig volledig in het teken te staan van AI-gestuurde codegeneratie. Elke paar dagen verschijnt er wel een nieuwe coding editor die beweert beter te zijn dan alle anderen. Termen als agentic coding en MCP (Model Context Protocol) vliegen je om de oren.

Productiviteit in softwareontwikkeling

Al deze tools claimen dat ze de productiviteit van ontwikkelaars drastisch verhogen, of zelfs bijna overbodig maken. Tegelijkertijd verschijnen er onderzoeken die deze productiviteitswinst in twijfel trekken. De wetenschappelijke betrouwbaarheid van die onderzoeken kun je overigens ook weer ter discussie stellen.

Maar wat verstaan we eigenlijk onder productiviteit van een ontwikkelaar? Meet je dat aan het aantal regels code per dag? Of is velocity—vaak gebruikt in Scrum-projecten—een betere maatstaf? Velocity meet echter niet de individuele snelheid, maar die van het team. Is dat erg? Softwareontwikkeling is immers nog steeds een teamaangelegenheid. Kortom: het is lastig om de meerwaarde van AI voor individuele ontwikkelaars hard te maken.

De relatie tussen codegeneratie en codekwaliteit

Dit artikel gaat niet over het bewijzen van productiviteitswinst door AI. De meeste ontwikkelaars gebruiken inmiddels tools als GitHub Copilot, JetBrains AI Assistant, ChatGPT, Claude en vele anderen. Deze tools zijn vooral handig voor het schrijven van boilerplate code—het saaie werk. Ik gebruik ze dagelijks.

Maar alle tools waarschuwen: gegenereerde code kan fouten bevatten. Sommige fouten zijn eenvoudig te herkennen, bijvoorbeeld omdat de code niet compileert of unit tests falen. Lastiger zijn fouten in de structuur: code die niet voldoet aan clean code-principes zoals SOLID, DRY of YAGNI. Deze fouten zijn subtieler, maar hebben grote impact op onderhoudbaarheid, testbaarheid en uitbreidbaarheid op de lange termijn. De snelheid waarmee een product doorontwikkeld kan worden, hangt sterk af van deze kwaliteit. Veel ervaren ontwikkelaars kennen voorbeelden van software die door slechte interne structuur nauwelijks nog te onderhouden was.

Kan AI codekwaliteit beoordelen?

Voor AI is het lastig om te herkennen wanneer gegenereerde code niet voldoet aan clean code-richtlijnen. De trainingsdata komt vaak uit open-source repositories en sites als StackOverflow. Maar hoe goed is die code? Mijn eigen repositories voldoen er niet aan; ze zijn bedoeld om concepten uit te leggen, niet om productiecode te tonen. Hoeveel andere repositories hebben hetzelfde probleem?

Bij StackOverflow kun je stemmen op antwoorden, maar zegt die score iets over codekwaliteit, toepasbaarheid, of beide? Kortom: kwaliteit is geen objectieve parameter in de training van deze modellen. Daar komt nog een beperking bij: het contextvenster. Hoe kan AI duplicatie herkennen als niet de volledige codebase in context zit? Tegelijk wil je die context juist beperken voor performance. Twee conflicterende doelen dus.

De rol van de ontwikkelaar in kwaliteitsbewaking

Voor het bewaken van clean code-principes hoeven we voorlopig niet veel van AI te verwachten. Ontwikkelaars moeten zelf kritisch blijven. Hier liggen twee risico’s:

  1. Gemakzucht
    Het is verleidelijk om een antwoord dat correct lijkt direct te accepteren. Zeker als management sterk op productiviteit stuurt. Dit zag ik vroeger al bij junioren die oplossingen van StackOverflow kopieerden zonder te begrijpen hoe ze werkten—laat staan dat ze de clean code-principes toetsten. Hetzelfde zie je bij pull requests: feedback beperkt zich vaak tot naamgeving, terwijl clean code veel verder gaat.
  2. Gebrek aan kennis
    Hoe leren ontwikkelaars clean coding? Soms op school, maar meestal niet meer dan een theoretische uitleg. Inhoudelijke feedback op studentcode ontbreekt vaak, simpelweg door tijdgebrek of gebrek aan expertise. En als feedback geen onderdeel is van de beoordeling, doet een student er weinig mee. Niet uit desinteresse, maar omdat studiepunten elders liggen.


Clean coding aanleren in het bedrijfsleven

Het echte leren gebeurt in bedrijven. Maar daar zijn uitdagingen. Veel actieve ontwikkelaars hebben geen IT-opleiding en missen basiskennis. Gelukkig leren sommigen zichzelf deze principes aan en geven feedback aan junioren—een soort meester-gezelconstructie.

Maar nu ontstaan twee nieuwe problemen:

  • Junioren vertrouwen sterk op AI en schrijven minder eigen code. Feedback voelt daardoor niet als persoonlijke leerervaring.
  • Bedrijven nemen minder junioren aan omdat AI als vervanging wordt gezien. Senior ontwikkelaars krijgen minder kans om kennis over te dragen. Als zij vertrekken of met pensioen gaan, ontstaat een gat dat niet gevuld kan worden door ervaren junioren—alleen door nieuwe ontwikkelaars die volledig op AI vertrouwen. Een groot risico dus.


Conclusie

Betekent dit dat ons beroep uitsterft? Hopelijk niet. Maar we moeten wél meer aandacht besteden aan kritische denkvaardigheden over codekwaliteit, vooral rond clean coding. Onderwijs speelt een rol, maar ook wij als beroepsgroep moeten verantwoordelijkheid nemen. Deel kennis via social media, waar jongeren actief zijn. Zo zorgen we dat alle ontwikkelaars de kans krijgen om deze principes te leren en toe te passen.

Johan Smarius