Meer AI-code, minder kwaliteit?

In mijn vorige blog schreef ik over wat AI verandert aan mijn werk als developer: meer contextswitches, minder voldoening en het risico dat we code accepteren die we niet volledig begrijpen. Maar er zit nog een andere kant aan. Als het steeds makkelijker wordt om code te produceren, wat doet dat dan met de kwaliteit van de software die we bouwen?

AI maakt het goedkoop om nieuwe code te schrijven. Een extra helper, abstraction of test is zo gegenereerd. Alleen: iedere regel die we toevoegen, moeten we daarna nog steeds begrijpen, testen en onderhouden. De snelheid waarmee we software produceren neemt toe, maar de verantwoordelijkheid voor wat we toevoegen blijft hetzelfde.

Meer vertrouwen betekent niet automatisch betere code

Als je AI vaak gebruikt en de uitkomsten meestal goed zijn, ga je erop vertrouwen. Een oplossing werkt, de tests slagen en je kunt verder. Maar juist daar moeten we volgens mij oppassen. Hoe vaker een oplossing direct lijkt te werken, hoe makkelijker het wordt om minder kritisch te kijken naar wat er precies is gegenereerd.

Een oplossing kan technisch correct zijn en toch niet de beste keuze. Misschien introduceert AI onnodige complexiteit, kiest het een patroon dat niet binnen de rest van de codebase past of lost het alleen het directe probleem op zonder rekening te houden met de gevolgen op langere termijn.

Juist omdat AI overtuigend code kan produceren, wordt reviewen wat mij betreft niet minder belangrijk, maar juist belangrijker. Niet alleen met de vraag: werkt dit? Maar ook: is dit de oplossing die we daadwerkelijk willen onderhouden? Hoe meer ik AI vertrouw om code te produceren, hoe kritischer ik wil zijn op de code die ik uiteindelijk accepteer.

Wat gebeurt er met onze eigen vaardigheden?

Programmeren leer je voor een groot deel door problemen zelf op te lossen. Je loopt vast, zoekt uit waarom iets niet werkt en bouwt ondertussen kennis op van de taal, het framework en de codebase waarin je werkt.

Wanneer AI steeds vaker direct met een oplossing komt, slaan we een deel van dat proces over. Dat hoeft geen probleem te zijn, zolang je al begrijpt wat er gebeurt. Maar als je voor ieder probleem meteen naar AI grijpt, bestaat het risico dat je vooral goed wordt in het beoordelen van oplossingen zonder zelf de kennis op te bouwen waarmee je die beoordeling kunt maken.

Vooral wanneer je iets nieuws leert, kan het daarom nuttig zijn om AI niet alleen om een oplossing te vragen. Ik vraag waarom een aanpak werkt, welke alternatieven er zijn of laat AI juist mijn eigen oplossing beoordelen. Zo wordt AI een hulpmiddel om sneller te leren in plaats van een manier om het leerproces over te slaan.

AI kan je ontwikkeling versnellen, maar alleen als je het gebruikt om meer te begrijpen in plaats van minder zelf te hoeven weten.

Meer code is niet altijd meer waarde

Een van de grootste veranderingen door AI is hoe makkelijk het is geworden om code te produceren. Waar je vroeger misschien nadacht of een bepaalde uitbreiding de extra complexiteit waard was, kan AI die uitbreiding nu in een paar minuten bouwen. Maar de kosten van software zitten niet alleen in het schrijven ervan. Code moet getest, gereviewd, gedebugd en uiteindelijk weer aangepast of verwijderd worden. Een oplossing die vandaag bijna gratis gegenereerd wordt, kan over een jaar nog steeds onderhoud kosten.

Daarom moeten we misschien juist kritischer worden op hoeveel code we toevoegen. Heeft deze abstraction echt waarde? Hebben we deze dependency nodig? Is een nieuwe functie noodzakelijk, of lossen we hiermee vooral een probleem op dat we zelf creëren?

AI maakt het schrijven van code goedkoper, maar onderhoud wordt daar niet automatisch goedkoper van. De beste gegenereerde code is soms de code die je besluit niet toe te voegen.

De rol van de developer verschuift opnieuw

Hoe beter AI wordt in het produceren van code, hoe minder waarde er zit in het simpelweg zo snel mogelijk schrijven ervan. Voor mij verschuift de waarde van een developer steeds meer naar het maken van keuzes.

Welk probleem proberen we eigenlijk op te lossen? Welke oplossing past bij onze architectuur? Wanneer is iets goed genoeg? Welke risico’s accepteren we en welke niet? En misschien wel de belangrijkste vraag: moeten we deze code überhaupt schrijven?

AI kan ons helpen om sneller bij een oplossing te komen, maar het kan die afwegingen niet volledig van ons overnemen. Juist doordat produceren makkelijker wordt, wordt selecteren belangrijker.

De developer van de toekomst schrijft misschien minder code dan vroeger, maar draagt niet minder verantwoordelijkheid. Integendeel: wanneer AI steeds meer kan bouwen, wordt het steeds belangrijker dat wij bepalen wat er gebouwd moet worden, waarom en onder welke voorwaarden.

Dat is misschien wel de grootste verandering van allemaal. We gaan niet van developer naar iemand die alleen nog maar op approve drukt. We gaan van code schrijven naar steeds bewuster bepalen welke code onze software daadwerkelijk beter maakt.