Hoe relevant is jouw IT-opleiding nog? (Spoiler alert: relevanter dan ooit)

ChatGPT kwam uit tijdens je studie. Je ziet mensen zonder programmeerkennis opeens webapps bouwen. En jij? Jij zit nog patronen uit je hoofd te leren en software architectuur te bestuderen. Is dat nog wel de moeite waard? Het korte antwoord volgens Jurre Brandsen, Software Engineer en Afstudeerbegeleider: absoluut. En wie dat niet ziet, mist de essentie van wat er nu aan het gebeuren is. 

Van Stack Overflow naar GitHub Copilot

 

Ik werk nu twee jaar als developer bij Info Support. In die tijd is mijn vak compleet veranderd. Waar het begon met simpele automatische aanvulling, besteed ik nu een groot deel van mijn ontwikkelingstijd aan het ontwerpen van oplossingen en het sparren met mijn AI. Het verschil is enorm groot, de snelheid ongekend hoog.

Maar die snelheid is waardeloos zonder de juiste basis. Want AI genereert alleen maar code. Dankzij jouw opleiding weet je of die code deugt.

Mijn werkdag ziet er radicaal anders uit dan twee jaar geleden. Waar ik eerst 70% bezig was met het schrijven van code, is dat nu 30%. De overige 70% besteed ik aan nadenken, architectuur ontwerpen, patronen kiezen, instructies formuleren.

Dit is geen verlies van werk, maar een upgrade van je rol.

Zonder solide fundament te groot vertrouwen in AI

Je IT-opleiding zorgt ervoor dat je die rol als architect op je kunt nemen. En die rol is, juist nu, belangijker dan ooit. Agents krijgen steeds meer verantwoordelijkheid. Daar gaat het mis bij mensen zonder een solide fundament; agents nemen verantwoordelijkheden over die jij als developer zou moeten houden.

In de samenwerking met AI zou je jezelf continu de vraag moeten stellen: ben ik nog in controle? Of laat ik AI te veel beslissen?

Dit is waar je opleiding het verschil maakt. Die software architectuur die je bestudeerde? Die design patterns? Die best practices? Dat zijn je controlemechanismen. Zonder die kennis weet je simpelweg niet welke vragen je moet stellen.

Een voorbeeld van zo’n controlemechanisme; vraag aan GitHub Copilot ‘voordat je dit gaat doen, stuur me het exacte plan op’. Dat biedt de mogelijkheid om controle te houden. Pas als je weet wat de agent wil gaan doen, kun je wijzigingen aanbrengen in dat plan.

Je wordt hierdoor niet alleen beter in prompten. Je leert de juiste controlevragen stellen op basis van je theoretische kennis.

Vibecoding vs AI Augmented Software Engineering

Je ziet in de praktijk steeds meer een onderscheid ontstaan tussen twee werelden, die alleen maar verder uit elkaar drijven.

Vibecoding: je gooit prompts naar AI en hoopt dat het werkt. Dat werkt heel goed iets nieuws te leren of te experimenteren. Maar het houdt geen stand in productiecode; je kent immers de patronen niet, je begrijpt de architectuur niet. Je bouwt wel iets, maar het is een kaartenhuis.

AI Augmented Software Engineering: je gebruikt AI als een krachtvermenigvuldiger. Je ontwerpt de architectuur. Je kiest de patronen. Je stelt de juiste vragen. Je controleert de output. Je bent de architect, AI is je uitvoerende kracht.

Het verschil? Je opleiding. Letterlijk. Dat is het enige verschil.

In mijn trainingen op het gebruik van AI-tooling gebruik ik een gaspedaal als metafoor. Op 0 staat vibecoding: geen gas, geen moeite, geen kennis. Op 100 staat AI Augmented Software Engineering: je drukt het gaspedaal in, je stuurt actief aan met je kennis, je bent volledig in controle.

Die vibecoders komen er in hobbyprojecten mee weg. Maar zodra het professioneel wordt (schaalbaarheid, onderhoudbaarheid, security, performance) dan houdt het op. Vibecoders kunnen een webapp bouwen, maar weten niet waarom die app niet schaalt. Ze zien niet dat de gegenereerde code security holes heeft. Ze herkennen niet wanneer patterns verkeerd worden toegepast.

De praktijk

Recent startte ik bij een nieuwe klant. De programmeertaal? Niet mijn primaire taal. En toch was ik binnen een week productief, omdat ik de patronen ken en weet welke vragen ik moet stellen.

Een ander project: een codebase die zo verweven zat in een SaaS-applicatie dat testen schrijven bijna onmogelijk was. Een grote architectuurwijziging was nodig. Dat hele proces hebben we in een week gerealiseerd. Waar het voorheen een maand had geduurd.

Ik kon dat alleen omdat ik wist hoe goede architectuur eruitziet. Ik heb het gedesigned, aan mijn AI verteld en laten uitvoeren. Af en toe stuur ik bij want ik zie meteen wanneer dat nodig is, omdat ik weet hoe het hoort.

Van individu naar team

Het gebruik van AI in development is tot nu toe vooral individualistisch geweest. Maar dat verandert. We gaan het steeds meer integreren in teams. Standaarden opstellen. Documenten schrijven die we kunnen voeden aan AI voor betere resultaten.

Teams met solide theoretische basis weten wat ze willen. Ze kunnen articuleren wat goede code is. Ze komen samen tot betere standaarden. Dat is de kracht van een gedeelde taal. Een taal die je leert in je opleiding.

Want alleen met die gemeenschappelijke basis kun je als team bepalen wat kwaliteit is. Wat goede architectuur is. Welke patronen je gebruikt. Die gedeelde kennis maakt het verschil tussen een team dat AI effectief inzet en een groep mensen die maar wat doet.

Gaat het plezier er niet vanaf?

Als je minder codeert, is het dan nog leuk?

Voor mij meer dan ooit. De reden dat ik ben begonnen met programmeren is dat ik puzzels oplossen leuk vind. Dat is niet veranderd. Sterker nog: je hebt het gevoel van oplossing vaker. Je bent sneller in je iteraties. Je kunt sneller experimenteren.

Maar het leuke is nu: je lost complexere puzzels op: architectuurpuzzels, designpuzzels, het soort puzzels waar je opleiding je echt op heeft voorbereid.