Er verandert iets fundamenteels in de wereld van de informatica. Wie vandaag een beetje vertrouwd is met AI, merkt hoe snel de mogelijkheden evolueren. Code schrijven, websites bouwen, gegevens analyseren of toepassingen ontwikkelen: wat vroeger behoorlijk wat technische kennis en programmeeruren vroeg, wordt steeds toegankelijker.

Ook in het onderwijs roept dat vragen op. Hoe zorgen we ervoor dat leerlingen nog zelfstandig leren programmeren? Hoe evalueren we hun vaardigheden wanneer ChatGPT steeds vaker een deel van het werk overneemt? En moeten we AI tijdens examens niet gewoon verbieden?

Allemaal begrijpelijke vragen. Maar ik vraag me af of we daarmee niet vooral proberen een werkelijkheid tegen te houden die ondertussen al lang aan onze klasdeuren staat te kloppen.

Misschien moeten we een fundamentelere vraag stellen: leiden we onze leerlingen nog op voor de wereld waarin wij zelf hebben leren werken, of voor de wereld waarin zij straks moeten functioneren?

De waarde van code verschuift

Decennialang was programmeerkennis een schaars en waardevol goed. Wie code kon schrijven, kon oplossingen bouwen en had daarmee een bijzonder waardevolle vaardigheid in handen.

Vandaag kan AI steeds beter code genereren. Niet foutloos, niet altijd betrouwbaar en zeker niet zonder menselijke controle. Maar wel snel genoeg om de waarde van louter code produceren grondig te veranderen.

Organisaties kampen immers niet noodzakelijk met een tekort aan code. Ze kampen vooral met een tekort aan mensen die begrijpen welke problemen opgelost moeten worden.

Mensen die processen kunnen doorgronden, verbanden zien, de juiste vragen stellen en menselijke behoeften kunnen vertalen naar technische oplossingen.

Iemand die begrijpt waarom een ziekenhuis zijn planning anders moet organiseren, waarom een bedrijf verdrinkt in Excelbestanden of waarom een productieproces efficiënter kan. En die vervolgens kan bepalen welke technologie daarvoor zinvol is.

We hebben misschien minder nood aan codekloppers en meer aan vertalers.

Niet mensen die zomaar wat prompts in ChatGPT gooien en hopen dat er iets bruikbaars uit rolt. Wel mensen die de taal van de gebruiker begrijpen én voldoende technische bagage hebben om met AI, softwareontwikkelaars en informaticasystemen samen te werken.

Maar een vertaler moet toch de taal kennen?

Uiteraard! Wie AI code laat schrijven zonder te begrijpen wat die code doet, is geen informaticus maar een gokker met een toetsenbord.

Een software engineer moet begrijpen wat hergebruik, schaalbaarheid, geheugenbeheer, beveiliging en onderhoudbaarheid betekenen. Hij moet kunnen beoordelen of een oplossing technisch deugt, of een AI-agent niet telkens opnieuw het warm water probeert uit te vinden en of de gekozen architectuur ook morgen nog overeind blijft.

AI mist immers nog regelmatig de context en het grotere plaatje. Ze kan een technisch correct antwoord geven op een vraag die vanuit het volledige systeem bekeken helemaal niet deugt.

Net daar zit voor ( volgens ) mij het onderscheid.

Een vertaler moet de taal kennen, maar hoeft niet noodzakelijk elk woord zelf te schrijven. Een architect moet begrijpen hoe een gebouw wordt geconstrueerd, maar hoeft daarom niet zelf elke baksteen te metselen. De technische basiskennis blijft essentieel. Alleen verschuift de manier waarop we die kennis inzetten.

Een interessante vergelijking is die met wiskunde. AI kan vandaag ook behoorlijk goed wiskundige problemen oplossen. Toch schaffen we wiskunde niet af. Terecht, want wiskunde is veel meer dan het uitvoeren van berekeningen. Het leert ons logisch redeneren, abstraheren en problemen ontleden.

Waarom zouden we die redenering niet doortrekken naar programmeren?

Leren denken vóór we leren produceren

Ik zie leerlingen soms zoveel energie steken in het correct plaatsen van haakjes, dubbele punten en inspringingen dat er nauwelijks nog ruimte overblijft om over het eigenlijke probleem na te denken.

Natuurlijk moeten ze syntax leren. Wie een programmeertaal niet begrijpt, kan ook de output van AI moeilijk beoordelen. Maar is het echt de bedoeling dat we hun probleemoplossend vermogen laten verdrinken in een zee van dubbele punten?

Misschien moeten we de verhouding eens omdraaien.

Niet vertrekken vanuit een lijst programmeercommando’s die leerlingen moeten inoefenen, maar vanuit een probleem waarvoor ze kennis nodig hebben. Eerst leren nadenken over een oplossing, vervolgens leren hoe we die technisch realiseren.

Dat is ook de richting waarin ik zelf probeer te werken.

Waarom zou een leerling Python alleen gebruiken om Python te leren? Laat hem een simulatie bouwen voor fysica, gegevens analyseren voor aardrijkskunde of een toepassing ontwikkelen voor een vraagstuk uit economie.

Dan krijgt programmeren plots een betekenis buiten het programmeerlesje zelf.

De code wordt een middel. Het denkwerk zit in het herkennen van het probleem, het bedenken van een oplossing, het aansturen van de technologie en het controleren van het resultaat.

Er bestaat trouwens al een interessante didactische aanpak die volgens mij perfect aansluit bij deze evolutie: PRIMM. Predict, Run, Investigate, Modify, Make.

Het uitgangspunt is eenvoudig: leerlingen beginnen niet noodzakelijk met zelf code te schrijven. Ze voorspellen eerst wat een stukje code zal doen, voeren het uit, onderzoeken hoe het werkt, passen het aan en bouwen uiteindelijk zelf een toepassing.

Waarom zouden we die aanpak niet doortrekken naar programmeren met AI?

Laat leerlingen eerst nadenken over het probleem en voorspellen welke oplossing mogelijk is. Vervolgens leren ze hun vraag vertalen naar een goede prompt. AI genereert code, maar daarmee begint het eigenlijke leerproces pas.

Werkt de oplossing? Heeft AI begrepen wat de bedoeling was? Is de code efficiënt? Wordt er geen onnodige omweg gemaakt? Wat gebeurt er wanneer we bepaalde parameters veranderen?

Leerlingen onderzoeken, testen, corrigeren en verfijnen. Soms passen ze de code aan, soms verbeteren ze hun prompt. En uiteindelijk bouwen ze zelf iets nieuws met de kennis die ze onderweg hebben opgedaan.

Daarmee wordt prompten geen trucje om het denkwerk uit te besteden, maar een nieuwe vorm van probleemformulering en communicatie met technologie.

Een goede prompt schrijven vraagt immers dat je weet wat je wilt bereiken, dat je een probleem kunt opdelen en dat je de juiste randvoorwaarden kunt formuleren. En vervolgens moet je nog kunnen beoordelen of het antwoord deugt.

Dat is geen gemakkelijkere vorm van leren. Het is een andere vorm van leren, waarin technische kennis, kritisch denken en probleemoplossend vermogen voortdurend samenkomen.

Misschien moeten we leerlingen dus niet leren om AI de juiste antwoorden te laten geven, maar om AI de juiste opdrachten te kunnen geven én de antwoorden kritisch te beoordelen.

PRIMM krijgt daarmee een extra dimensie: de leerling leert niet alleen code begrijpen, maar ook technologie aansturen.

Dat is voor mij de essentie van probleemgestuurd leren.

Intelligentie is creatief bouwen met blokjes kennis

Ik heb daar een vrij eenvoudige kijk op intelligentie.

Intelligentie is niet hoeveel feiten je uit je hoofd kunt reproduceren. Het is het vermogen om kennis die je bezit op een creatieve manier met elkaar te verbinden.

Vergelijk het met LEGO.

Je kunt duizenden blokjes verzamelen en perfect weten hoe elk blokje heet. Maar dat maakt je nog geen architect. De kunst zit in het zien van mogelijkheden, het leggen van verbanden en het bouwen van iets wat er voordien nog niet was.

AI geeft onze leerlingen een gigantische extra doos bouwstenen.

Zouden we hen dan echt moeten leren om die doos vooral gesloten te houden?

Dat betekent uiteraard niet dat alles zomaar aan AI moet worden overgelaten. Integendeel. Basiskennis is noodzakelijk om te kunnen beoordelen, corrigeren en verbeteren. Kritisch denken is geen optionele uitbreiding van informatica. Het is een voorwaarde.

Maar misschien moeten we ook onze manier van evalueren herbekijken.

Een examen waarop AI verboden is, kan perfect zinvol zijn om bepaalde basisvaardigheden te toetsen. Ik heb daar geen principieel probleem mee.

Maar als we daarmee ook de indruk wekken dat zelfstandig code produceren de ultieme maatstaf voor informaticabekwaamheid is, dan missen we volgens mij de essentie.

In de echte wereld zal niemand bijzonder onder de indruk zijn omdat je een halve dag zonder AI aan een programma hebt geschreven dat met AI in vijf minuten klaar was.

Men zal willen weten of je het juiste probleem hebt aangepakt, of de oplossing werkt, of ze veilig en schaalbaar is en of je begrijpt wat je gebouwd hebt.

Dat vraagt andere competenties. En misschien ook andere examens.

Een andere opdracht voor het onderwijs

Ik pleit dus niet voor minder informatica, minder technische kennis of minder programmeren. Ik pleit voor een ander einddoel.

We moeten jongeren leren systemen begrijpen, problemen herkennen, kennis combineren en technologie doelgericht inzetten. Ze moeten kunnen programmeren, maar ook kunnen beoordelen wanneer programmeren de beste oplossing is. Ze moeten AI kunnen gebruiken, maar vooral begrijpen wanneer AI hen op het verkeerde been zet.

De programmeur van morgen wordt misschien steeds meer iemand die een team van AI-agents aanstuurt. Maar ook dat vraagt technische kennis, inzicht in architectuur en het vermogen om beslissingen te nemen.

De uitdaging is dus niet om de programmeur te vervangen door iemand die goed met prompts overweg kan.
De uitdaging is om de programmeur te laten doorgroeien tot iemand die technologie richting kan geven.

En dat begint in het onderwijs.

Misschien moeten we wat minder energie steken in het bewaken van wat leerlingen niet mogen gebruiken, en wat meer in het ontwikkelen van wat ze ermee kunnen bereiken.

Want de grootste fout die we kunnen maken, is jongeren opleiden voor een wereld die stilaan verdwijnt.

Ik wil geen leerlingen afleveren die zonder AI code kunnen schrijven. Ik wil leerlingen afleveren die mét of zonder AI weten wat ze aan het bouwen zijn.

Misschien is dat wel de belangrijkste verschuiving die het informaticaonderwijs de komende jaren moet maken.

Niet van programmeren naar prompten.

Maar van code produceren naar problemen oplossen.

En laat ons vooral niet vergeten: de beste programmeur van morgen is misschien niet degene die de meeste code schrijft, maar degene die weet welke code helemaal niet meer geschreven hoeft te worden.

Wordt vervolgd. Er valt nog heel wat te bouwen!