AI-ondersteunde programmeeropdrachten in HBO-ICT beoordelen
Een praktisch kader voor het beoordelen van programmeerwerk wanneer studenten generatieve AI of coding agents gebruiken, zonder de beoordeling te reduceren tot detectie.
TraceYield Inzichten
13 min leestijd · Bijgewerkt 10 augustus 2026
TraceYield
Bewijs van AI-ondersteund werk
AI-ondersteunde programmeeropdrachten in HBO-ICT beoordelen
Het beoordelingsprobleem is groter dan auteurschap
Een student levert een werkende applicatie in. De code is leesbaar, de tests slagen en een coding agent heeft substantieel geholpen. De docent moet dan meer beoordelen dan of het eindproduct draait: wat begreep de student, welke keuzes maakte die student en hoe werd het resultaat gecontroleerd?
Dat is een andere vraag dan “is AI gebruikt?”. In de beroepspraktijk kan AI-gebruik legitiem en verwacht zijn. De onderwijsopgave is bepalen of de beoordeling nog valide bewijs geeft voor de leeruitkomsten.
Begin bij de leeruitkomsten
Bepaal eerst wat de opdracht moet meten. Gaat het om een geteste service, dan zijn gedrag, ontwerp, tests en het kunnen uitleggen van trade-offs relevant. Gaat het om debugging, dan is de route van symptoom naar diagnose belangrijker dan het aantal gewijzigde regels.
Toegestaan AI-gebruik, onderwijsactiviteiten, opdracht en bewijs moeten dezelfde leeruitkomst ondersteunen. Een algemeen verbod kan ongeschikt zijn wanneer AI-geletterdheid deel is van het beroepsdoel.
Gebruik meerdere bewijssoorten
Het eindproduct omvat applicatie, broncode, tests, documentatie en demonstratie. Procesbewijs kan bestaan uit probleemformulering, onderzochte aanpakken, debugging, verworpen alternatieven en verificatie. Uitlegbewijs kan komen uit een code walkthrough, gerichte vragen of een kleine live wijziging.
Een docent heeft geen volledige transcriptie van elke prompt nodig. Het doel is een verdedigbare steekproef van hoe de student werkte en of die student het resultaat aan de gemaakte keuzes kan verbinden.
Maak de beoordeling proportioneel
Een werkbare structuur kan bestaan uit een korte planfase, een implementatiecheck, het eindproduct met tests, een AI-use-notitie en een korte uitleg of demonstratie. Weeg onderdelen volgens de leeruitkomsten.
Vraag bijvoorbeeld om één architectuurkeuze toe te lichten, één fout te diagnosticeren en één gedrag aan te passen. Zo toets je begrip zonder een rituele verdediging van elke regel te organiseren.
Beoordeel observeerbaar gedrag
Nuttige criteria zijn probleemframing, context voor de tool, evaluatie van suggesties, debugging, testen, zelfstandige aanpassing en reflectie op beperkingen. “AI effectief gebruikt” is te vaag; beschrijf bewijs dat een beoordelaar kan herkennen.
Behandel onzekerheid niet automatisch als fraude. Vraag om verduidelijking of een kleine transferopdracht wanneer dat nodig is. Goed procesbewijs ondersteunt een eerlijke beoordeling.
Het TraceYield-perspectief
De eindcode laat zien wat is opgeleverd. Een trajectory kan aanvullende context geven over waar de student verkende, context toevoegde, bijstuurde en controleerde. Dat ondersteunt het oordeel van de docent, maar vervangt de rubric, het gesprek of de professionele beoordeling niet.
Als een agent aangeeft klaar te zijn, is het ontwikkelwerk nog niet automatisch af.
Referenties
Pilotprogramma
Begrijp waarom uw team AI gebruikt zoals het dat doet.
TraceYield beoordeelt het traject achter AI-gebruik in plaats van alleen kosten en tokenaantallen te bekijken. Meld u aan voor de private pilot om AI-gebruik in Codex-, Claude Code- en Copilot-werkwijzen te onderzoeken, met aandacht voor technische context, security en vertrouwen bij developers.
Meld u aan voor de TraceYield-pilot