Waarom code geen kunst is (en we in het AI-tijdperk vooral moeten bezinnen eer we beginnen)

>Code is art that does something. Ik zag deze tekst onlangs op een sticker op de laptop van een medereiziger in de trein. En ergens begrijp ik het wel. Ik hou van de trots en het vakmanschap van een steengoede developer. Mensen die met focus en elegantie een complex probleem weten te vertalen naar efficiënte software, verdienen enorm veel respect. Ontwikkelaars zijn de motor van onze digitale wereld. Maar als IT-architect keek ik naar die sticker en dacht: Neen. Absoluut niet. Vanuit een architecturaal en zakelijk perspectief is code namelijk geen kunst. Sterker nog: in de basis is code een liability, geen asset. Het is ballast. ## Het machinepark van de organisatie Laat me dat nuanceren. Code is geen doel op zich, het is een middel. Het is de afspiegeling van een bedrijfsorganisatie en hét middel waarmee we als bedrijf waarde creëren. Vergelijk het met het machinepark in een fabriek. Je hebt die indrukwekkende machines keihard nodig om te produceren en je koestert de technici die ze draaiende houden. Maar elke meter extra kabel, elke lopende band en elk extra tandwiel kost geld. Het vreet onderhoud, vraagt om beveiliging en gaat vroeg of laat kapot. Je zet toch ook geen sticker op je industriële persmachine met de tekst "Staal is kunst"? (Tenzij het misschien in het Centre Pompidou staat). In softwareontwikkeling geldt precies hetzelfde: hoe meer onderdelen, hoe meer miserie. Waarom doen we dan toch vaak alsof elke extra regel code automatisch een meerwaarde is? Een plotse explosie in de hoeveelheid code is voor mij geen toename in waarde, tenzij dit één-op-één gedragen wordt door een keiharde business case of een broodnodig proces. Anders is het gewoon extra gewicht in de rugzak van je IT-afdeling. Bezinnen eer we beginnen is dus cruciaal. ## De AI-versneller en de code-explosie Met de komst van Generatieve AI, 'Agentic AI' en 'Vibecoding' zie ik de uitdaging rondom dit volume alleen maar groter worden. Iedereen schept op dat ze 10 keer sneller kunnen bouwen. We prompten in no-time hele applicaties en features bij elkaar. AI is een fantastische versneller, begrijp me niet verkeerd. Maar als code met één druk op de knop uit een Large Language Model rolt, verandert er iets fundamenteels. De 'art' is er definitief vanaf; code wordt een commodity. Wat overblijft na die snelle AI-generatie is een gigantische berg syntax. Een berg tekst die we morgen nog steeds moeten begrijpen, patchen, hosten en beveiligen. En nog moeilijker: die we moeten overdragen aan een nieuw team of een junior developer. Hoe meer code AI voor ons uitspuwt, hoe moeilijker het wordt om het geheel te beheersen. ## Van code kloppen naar code reviewen: Willen we dit wel? Deze verschuiving heeft een enorme impact op de rol van de developer. Waar de focus vroeger lag op het creatieve proces van 'code kloppen' en het zelf bedenken van de oplossing, verschuift de taak nu steeds meer naar het nakijken en valideren. De developer wordt een reviewer. En laten we eerlijk zijn: het reviewen van andermans code (of in dit geval, de code van een machine) is een totaal ander, en vaak veel saaier, werk dan het zélf engineeren. Het vereist een andere mindset. De vraag is of de gepassioneerde developer, die juist hield van het vakmanschap en de creativiteit, hier op de lange termijn wel gelukkig van wordt. ## De verschuiving naar architectuur Hetzelfde geldt voor het nadenken over architectuur. Hoe makkelijker AI het maakt om méér te schrijven, hoe belangrijker het overzicht wordt. De rol van architectuur is niet om die AI-kraan nóg verder open te draaien. De rol van architectuur is juist beslissen wat we vooral niet moeten bouwen. Mijn vuistregel als architect is simpel: de beste code is geen code. De échte waarde zit niet in de gegenereerde syntax, maar in de businessflow die eronder ligt. Het zit in een architectuur die alles pragmatisch en simpel houdt. Een fundament dat de organisatie in staat stelt om waarde te creëren zonder te verdrinken in een zee van complexiteit. Ik zie het niet als mijn taak om repositories te vullen, maar om de complexiteit — en dus de operationele en financiële kost die we software noemen — zo laag mogelijk te houden. Dus, de volgende keer dat je een AI-tool aanzet: gebruik je het om slimmere, strakkere architecturen te ontwerpen en de businessflow te dienen? Of ben je op topsnelheid aan het investeren in de technische schuld van morgen?