De kunstvorm van het programmeren

Ik zie softwareontwikkeling daarom nog steeds als een kunstvorm. Je kunt vaak zien of een applicatie goed of minder goed is ontwikkeld, zonder dat je direct alle details kent. Dat zit in de structuur van de code, de manier waarop dependencies worden beheerd en de keuzes die onder de motorkap zijn gemaakt. Ik kon uren werken aan het implementeren van een design pattern en daarna zien hoe de applicatie precies deed wat hij moest doen. Het voelde een beetje als magie, waarbij ik de tovenaar was. Ook het bestuderen van goede open source-projecten en hun structuren hoorde daarbij.

Flash forward naar nu. Binnen developmentland gaat het veel over AI en de impact van AI, specifiek ook vibe coding, op het vak van developer. De perceptie ontstaat dat developers straks niet meer nodig zijn, of dat alleen senior developers overblijven omdat AI het werk overneemt.

Maar zo eenvoudig is het niet.

Van developer naar engineer

De natuurlijke ontwikkeling van een developer is vaak dat je begint met coderen en daarna doorgroeit richting ontwerp en engineering. Engineering omvat in ieder geval meer dan alleen het programmeren van code. Development gaat vaak over het bouwen van functionaliteit: zorgen dat iets werkt, dat een gebruiker een actie kan uitvoeren en dat de code doet wat gevraagd wordt. Engineering gaat een laag dieper. Daar gaat het over de vraag hoe je software zo ontwerpt dat het veilig, onderhoudbaar, schaalbaar en betrouwbaar blijft. Niet alleen vandaag, maar ook als het product groeit, als andere developers eraan werken en als de eisen veranderen.

Daarmee zit engineering meer op de structuur achter de software: architectuur, technische keuzes, afhankelijkheden, foutscenario’s, security, performance en de manier waarop onderdelen met elkaar samenwerken. Goede engineering bepaalt uiteindelijk of code alleen werkt, of dat software ook goed blijft werken.

Een nieuwe developer begint vaak met het schrijven van losse stukken code of kleine functionaliteiten. In die fase kijk je veel naar voorbeeldcode van andere developers. Je probeert te begrijpen hoe bepaalde keuzes zijn gemaakt, welke patronen steeds terugkomen en waarom iets op een bepaalde manier is opgebouwd. Langzaam verschuift de focus. Eerst gaat het vooral om de vraag: werkt mijn code? Daarna komt de vraag: past mijn code binnen de rest van de applicatie? Je leert rekening houden met structuur, foutafhandeling, herbruikbaarheid, leesbaarheid en de manier waarop andere developers later met jouw code moeten werken. Zo groeit een junior developer stap voor stap door. Niet alleen door zelf code te schrijven, maar ook door bestaande code te lezen, feedback te krijgen, fouten te maken en te zien hoe andere developers problemen oplossen. De ontwikkeling zit dus niet alleen in sneller of beter programmeren, maar in steeds beter begrijpen hoe software als geheel in elkaar zit.

Wat begint als leren programmeren, groeit daarmee langzaam uit tot het vak van software engineering en/of softwarearchitectuur. Je gaat niet alleen meer nadenken over de code die je vandaag schrijft, maar over de structuur waarin die code moet blijven werken. Over keuzes die later onderhoud, veiligheid, performance en doorontwikkeling mogelijk maken. Dat is uiteindelijk waar het vak breder wordt dan development alleen.

De invloed van AI op developers

De invloed van AI op developers zit denk ik niet alleen in het sneller schrijven van code. Maar daarmee verandert niet automatisch het hele vak. Wat wel verandert, is de manier waarop developers leren, werken en keuzes maken. Een developer zal minder tijd kwijt zijn aan het zelf uitschrijven van standaardcode, maar moet juist beter worden in het beoordelen van wat er gegenereerd wordt. Klopt de oplossing? Past deze binnen de bestaande architectuur? Is het veilig? Is het onderhoudbaar? En wat betekent deze keuze over een half jaar, als iemand anders ermee verder moet?

Daarmee schuift het werk van developers sneller op richting engineering. Niet omdat code schrijven niet meer belangrijk is, maar omdat het schrijven van code minder de beperkende factor wordt. De kwaliteit zit steeds meer in het begrijpen van de context, het stellen van de juiste vragen en het ontwerpen en bewaken van de structuur waarin software wordt gebouwd. Voor junior developers maakt dat het vak anders. Ze kunnen sneller iets werkends maken, maar juist daardoor wordt het belangrijker dat ze leren kijken naar de engineeringkant van softwareontwikkeling. Het uitwerken van softwarearchitectuur, het vastleggen van gemaakte keuzes, het begrijpen van technische en functionele requirements en de traceerbaarheid van die keuzes naar code en testen worden belangrijker.

Juist op dat vlak schuurt het in softwareontwikkeling nog weleens met documentatie. Veel keuzes zitten in het hoofd van een engineer, in een pull request, of ergens verspreid over tickets en codecomments. Maar als AI een grotere rol krijgt in het ontwikkelproces, wordt het belangrijker dat keuzes expliciet worden vastgelegd en omschreven. Niet alleen voor mensen, maar ook voor de systemen die op basis van die context code genereren of aanpassen.

Het maken van goede ontwerpen, het valideren van code en het bewaken van de structuur is dus juist nu van belang. De manier waarop een nieuwe developer dit kan leren, wordt misschien zelfs beter. Niet omdat AI alles oplost, maar omdat we eindelijk meer noodzaak voelen om vast te leggen waarom software op een bepaalde manier is opgebouwd. Waar een junior developer vroeger vooral leerde door code van anderen te lezen, leert hij straks ook door documentatie, prompts, technische ontwerpen en design decisions te lezen. Code bevat dan niet alleen de oplossing, maar wordt steeds meer verbonden met de context waaruit die oplossing is ontstaan.

Daarmee wordt de groei van developer naar engineer belangrijker, sneller en die werelden gaan mogelijk integreren. AI kan helpen bij het bouwen, maar iemand moet blijven begrijpen wat er gebouwd wordt, waarom het zo gebouwd wordt en of het over een jaar nog steeds een goede keuze is. Nu is de vraag: bestaat deze pure developer eigenlijk wel? Ik denk van niet. Ongeacht of je vanuit school hebt leren ontwikkelen, gaat het altijd verder dan alleen maar het bouwen. Developers groeien normaal al snel door naar de engineeringhoek en willen dit vaak ook. Er verandert wat met de focus, de ontwikkeling zal richting architectuur en engineering gaan, maar dat was eigenlijk al het pad dat we volgden.

AI als ondersteuning voor engineers

AI kan engineers helpen om betere documentatie, ontwerpen en technische keuzes vast te leggen. Maar zoals bij iedere AI geldt ook hier: als je geen goede input levert, krijg je ook geen goede output. Een prompt als “geef mij de architectuur voor deze applicatie” gaat niet werken. Daarvoor is softwareontwikkeling te contextafhankelijk. Het gaat juist om de balans tussen wat nu goed ontworpen moet worden en wat later met beperkte impact aangepast kan worden. Welke eisen zijn fundamenteel? Welke keuzes hebben invloed op security, onderhoudbaarheid of schaalbaarheid? En welke onderdelen kunnen bewust eenvoudiger blijven omdat de impact beperkt is?

Door deze manier van werken gaan technische keuzes steeds vaker mee de Git-repository in. Niet alleen de uiteindelijke implementatie wordt vastgelegd, maar ook de redenering erachter. Design decisions, requirements, technische afspraken, prompts en instructies worden onderdeel van dezelfde ontwikkelstructuur. Daarmee worden keuzes beter traceerbaar, consistenter en makkelijker overdraagbaar.

Daarnaast kan een engineer AI gebruiken om de consistentie tussen documentatie en code te valideren. Klopt de implementatie nog met de gemaakte keuzes? Zijn er onderdelen die afwijken van de architectuur? Juist daar zit een mooie ontwikkeling. Waar je normaal vooral afhankelijk bent van de mening en ervaring van één engineer, krijgt die engineer nu vanuit een andere hoek extra inzichten. Niet als vervanging van expertise, maar als ondersteuning om betere vragen te stellen, mogelijke omissies te vinden en een architectuur te ontwikkelen die beter recht doet aan onderhoudbaarheid, structuur en toekomstige groei.

Nu zit hier ook een gevaar in. Een engineer kan perfect uitgewerkte requirements schrijven die door AI ook echt geïmplementeerd kunnen worden. De vraag wordt daardoor steeds belangrijker of die requirements op dat moment nodig zijn, of dat ze later met beperkte impact toegevoegd kunnen worden. Denk bijvoorbeeld aan SSO, RBAC of 2FA. Dergelijke security-by-design zaken moet je vanaf het begin goed doen. Iedere organisatie kan daarin zijn eigen standaard maken voor hoe dit geïmplementeerd moet worden. Als er wijzigingen komen in die standaard, kan een engineer die vervolgens toepassen op alle applicaties waar dat nodig is.

Het hergebruiken van dergelijke instructies is een vliegwiel dat nog niet altijd volledig benut wordt in softwareontwikkeling, maar wel steeds belangrijker wordt. Versiebeheer gaat daarom niet meer alleen over code, maar ook over de meta-laag van prompts, instructies, skills en technische afspraken die bijdragen aan het maken van code met de gewenste kwaliteit en garanties. Daar zit ook een nieuwe vorm van complexiteit. Hoe uitgebreider deze structuren worden, hoe meer context AI nodig heeft om goede wijzigingen door te voeren. Die complexiteit vertaalt zich niet alleen naar onderhoudbaarheid, maar ook direct naar tokenkosten en de efficiëntie waarmee teams met AI kunnen werken.

Daarmee verschuift de rol van de engineer ook. Waar product owners gemeengoed zijn voor de functionele kant van een applicatie, krijgt de engineer steeds meer een vorm van technisch product ownership. Iemand moet niet alleen bewaken wat de applicatie functioneel moet doen, maar ook of de applicatie technisch gezond blijft. Of de keuzes nog kloppen. Of de structuur nog past. En of de software ook op langere termijn goed te onderhouden is.

Iedereen kan met AI developen, maar niet iedereen is een engineer

In een tijd van supply chain attacks en mensen die al vibe-codend applicaties in het publieke domein brengen, schuilt een risico. De stap van developer naar engineer of architect is normaal gesproken een groeiproces. Mensen die nooit aan de developmenttafel hebben gezeten, missen die ontwikkeling. Niet omdat ze niet slim genoeg zijn, maar omdat ze bepaalde fouten, afwegingen en risico’s nog niet van dichtbij hebben meegemaakt of simpelweg het vak niet hebben geleerd. Als een applicatie werkt, kan al snel de indruk ontstaan dat iemand ook begrijpt waarom en hoe die applicatie werkt. Daar zit precies het probleem.

De vraag is niet of mensen zonder softwareachtergrond met AI iets werkends kunnen bouwen. Dat kunnen ze zeker. De vraag is of ze daarmee ook direct de rol van een engineer kunnen innemen. Ik denk zelf van niet. Engineering is een expertise. Veel mensen kunnen koken, maar dat maakt iemand nog geen chef in een professionele keuken. Het gaat over het opzetten van software die niet alleen vandaag werkt, maar ook blijft werken als het gebruik groeit, de eisen veranderen of andere mensen ermee verder moeten. Het gaat over onderhoudbaarheid, veiligheid en technische keuzes die later duur kunnen worden als ze verkeerd zijn gemaakt.

Want iedereen kan straks misschien iets bouwen dat werkt. Maar dat maakt nog niet iedereen een engineer.

Mijn visie voor nu

De wereld van AI ontwikkelt zich razendsnel. Voor nu zie ik het als volgt. Developers zullen zich sneller ontwikkelen richting engineers en mogelijk moeten we het helemaal niet over developers hebben. Engineers zijn niet alleen beheerders van de code zelf, maar ook van de documentatie, prompts, design decisions, instructies en andere documenten die nodig zijn om tot die code te komen.

Startende en ervaren engineers kunnen productiever worden door het gebruik van AI en zich waarschijnlijk ook sneller ontwikkelen dan voorheen. De focus komt meer op structuur te liggen. Maar laten we eerlijk zijn, dat is ook de essentie van ontwikkelen: het maken van een applicatie die doet wat het moet doen, in een structuur die recht doet aan het doel. Hoeveel engineers er in de toekomst nodig zijn, vind ik lastig te voorspellen. Wel is het zo dat het maken van software sneller kan. Daardoor wordt ook het risico groter dat je ingehaald wordt door iemand anders die sneller van idee naar werkend product gaat of niet de technical debt heeft die jij hebt. Ik denk niet dat ondernemerschap wordt beperkt door AI. Eerder andersom. Het aantal ideeën voor nieuwe toepassingen zal toenemen en veel van die ideeën zullen sneller hun weg vinden naar prototypes en uiteindelijk volwassen applicaties.

Juist daar blijven engineers nodig. Niet alleen om iets werkend te krijgen, maar om applicaties te ontwikkelen die beter zijn dan hun concurrenten. Applicaties die veilig zijn, onderhoudbaar blijven en niet bij de tweede versie uit elkaar vallen. Dat zijn geen applicaties die je eenmalig “one shot” vibe-codeert en daarna vergeet. Gebruikers willen immers ook niet iedere maand overstappen naar iets nieuws omdat de vorige oplossing technisch niet meer houdbaar is.

De strategische laag

Daarmee is AI in softwareontwikkeling niet alleen een technisch vraagstuk. Het is ook een strategisch vraagstuk. Organisaties die AI alleen zien als manier om sneller code te schrijven, missen een belangrijk deel van de verandering. De echte vraag is niet alleen hoeveel sneller een team functionaliteit kan bouwen, maar of de organisatie in staat is om die snelheid verantwoord te absorberen en in te zetten.

Juist daar ligt de strategische opgave voor CTO’s, CIO’s, product owners en engineering leaders. AI vergroot de executiekracht van teams, maar maakt ook duidelijker waar de zwakke plekken in de organisatie zitten. Onduidelijke requirements, ontbrekende architectuurprincipes, versnipperde documentatie, zwakke securitystandaarden of onvoldoende eigenaarschap worden niet opgelost door AI. Ze worden eerder uitvergroot.

Daarom wordt software engineering steeds meer een strategische capability. Niet alleen een uitvoerende functie die code oplevert, maar een vermogen van de organisatie om ideeën betrouwbaar om te zetten in schaalbare, veilige en onderhoudbare digitale producten. Wie dat goed organiseert, kan sneller experimenteren, goedkoper leren en met meer vertrouwen opschalen. Wie dat niet goed organiseert, bouwt misschien sneller, maar creëert ook sneller complexiteit.

Dat vraagt om duidelijke technische kaders, herbruikbare standaarden, expliciete design decisions, goede documentatie, security-by-design en engineers die niet alleen code schrijven, maar ook verantwoordelijkheid nemen voor de technische gezondheid van het product. AI verandert de manier waarop organisaties naar softwareontwikkeling moeten kijken. Van losse delivery-capaciteit naar een strategisch vermogen om technologie betrouwbaar, schaalbaar en onderscheidend in te zetten.

Misschien is dat wel de belangrijkste verschuiving. De vraag is niet alleen of we met AI sneller software kunnen maken. Dat kunnen we. De vraag is of organisaties ook de engineering capability hebben om die snelheid verantwoord te benutten. Blijf daarom investeren in startende engineers. Blijf mooie software ontwikkelen. Maar vergeet niet de rest van de organisatie mee te schalen: architectuur, governance, security, product ownership, documentatie, besluitvorming en leiderschap.

Want AI kan softwareontwikkeling versnellen. Maar alleen goede engineering maakt die versnelling duurzaam.