Van code schrijven naar code bewaken

Het afgelopen jaar is het gebruik van AI bij het schrijven van code explosief gegroeid. Tools als Codex en Claude zijn voor veel developers een vast onderdeel van het ontwikkelproces geworden: de tools schrijven code, denken mee en helpen bij het beoordelen van oplossingen. Daardoor hoeven we zelf minder tijd te besteden aan het daadwerkelijk typen van code en ontstaat er meer ruimte om ons te richten op zaken als kwaliteit, veiligheid en innovatie.

Die ontwikkeling verandert ook de rol van de developer. Mijn werk ziet er inmiddels behoorlijk anders uit dan een paar jaar geleden. Maar zoals bij vrijwel iedere grote technologische verandering heeft ook deze ontwikkeling een schaduwzijde. In deze blog ga ik in op drie valkuilen die vooral invloed hebben op hoe we als developers werken.

Context fatigue

Met AI is het verleidelijk om meerdere taken tegelijk op te pakken. Terwijl de ene agent een bug onderzoekt, laat je een andere alvast tests schrijven en begin je zelf aan het volgende probleem. Dat lijkt efficiënt, maar iedere taak vraagt om een ander stuk van je aandacht. Je moet steeds opnieuw bedenken: waar ging dit ook alweer over, welke keuzes hadden we gemaakt en wat moet ik hier precies beoordelen?

Dat voortdurende schakelen tussen verschillende problemen, oplossingen en stukken code kost mentale energie. Het gevolg is een soort context fatigue: je bent vooral bezig om opnieuw te begrijpen waar je gebleven was, in plaats van echt diep met een probleem bezig te zijn. AI versnelt het werk, maar kan er tegelijkertijd voor zorgen dat je aandacht steeds verder versnippert.

Je kunt context fatigue beperken door bewust grenzen te stellen aan het aantal taken dat je parallel uitvoert. Laat bijvoorbeeld maximaal één of twee AI-taken tegelijk lopen en begin niet automatisch aan iets nieuws zodra een agent bezig is. Gebruik die wachttijd liever om de huidige taak te reviewen, tests te draaien of documentatie bij te werken.

AI maakt parallel werken makkelijker, maar dat betekent niet dat parallel werken ook beter is. Bescherm je focus net zo bewust als je je codekwaliteit beschermt.

Waar blijft de voldoening van zelf iets bouwen?

Een groot deel van mijn voldoening uit programmeren zit niet in het eindresultaat, maar juist in de weg ernaartoe. Een probleem uitpluizen, verschillende oplossingen proberen en uiteindelijk dat moment waarop alles op zijn plek valt. Wanneer AI een groot deel van dat proces overneemt, kan die voldoening langzaam verdwijnen. Ik krijg misschien sneller werkende code, maar het gevoel van ‘dit heb ik zelf bedacht en gebouwd’ wordt minder sterk. Programmeren kan daardoor steeds meer gaan voelen als het beoordelen van werk dat iemand anders heeft gemaakt.

Dat betekent niet dat je AI daarom minder moet gebruiken. Wel kan het helpen om bewust te kiezen wanneer je AI inzet en wanneer niet. Niet ieder probleem hoeft zo snel mogelijk opgelost te worden. Soms is het juist waardevol om eerst zelf na te denken, een oplossing uit te werken of bewust zonder AI te debuggen. Zeker bij onderwerpen waarin ik mezelf wil ontwikkelen, kan het proces belangrijker zijn dan de tijdwinst.

AI kan veel van het schrijfwerk van ons overnemen, maar plezier, nieuwsgierigheid en het gevoel iets zelf te hebben gemaakt zijn voor mij ook onderdeel van het vak. Niet alles wat je met AI kunt versnellen, hoef je ook uit handen te geven.

Code begrijpen blijft jouw verantwoordelijkheid

AI kan in een paar seconden een oplossing produceren waar ik zelf misschien veel langer over zou doen. Dat is krachtig, maar het brengt ook een risico met zich mee: omdat de code er snel en overtuigend uitziet, ben je sneller geneigd om te denken dat het wel goed zit. Voor je het weet keur je code goed die je zelf niet volledig begrijpt.

Daarom blijft het belangrijk om gegenereerde code net zo kritisch te beoordelen als code van een collega. Kun je uitleggen waarom deze oplossing werkt? Begrijp je welke keuzes er zijn gemaakt? Zou je de code zelf kunnen debuggen als er morgen iets misgaat? En past de oplossing eigenlijk wel binnen de architectuur en afspraken van je project? Als je die vragen niet goed kunt beantwoorden, begrijp je waarschijnlijk nog niet genoeg van de code om er verantwoordelijkheid voor te nemen.

AI mag het denkwerk ondersteunen, maar niet vervangen. Uiteindelijk ben jij degene die de code toevoegt aan de codebase en dus ook degene die moet begrijpen wat er gebeurt. Genereer zo snel als je wilt, maar approve nooit sneller dan je kunt begrijpen.

Dit is pas het begin

AI verandert niet alleen hoe snel we software kunnen bouwen, maar ook wat er van ons als developers wordt gevraagd. Minder tijd besteden aan het schrijven van code betekent niet automatisch dat het werk eenvoudiger wordt. Mijn aandacht verschuift juist steeds meer naar begrijpen, beoordelen en bewaken.

Context fatigue, minder voldoening en het risico dat we code accepteren die we niet volledig begrijpen zijn daar drie voorbeelden van. Maar er zijn meer vragen. Wat doet AI op de langere termijn met onze eigen vaardigheden? Worden we minder kritisch naarmate we AI meer vertrouwen? En wat gebeurt er met een codebase wanneer het steeds makkelijker wordt om nieuwe code te produceren?

Daar ga ik in een volgende blog verder op in.

Bas Everaarts
Technologie