Hoe beoordeel je de verantwoordelijkheid van een student voor AI-ondersteunde code?

Begin bij de leeruitkomst

Benoem eerst welke vaardigheid de opdracht toetst: bijvoorbeeld een autorisatieregel uitleggen, een falende test diagnosticeren, een ontwerp aanpassen aan een nieuwe eis of een passende controle kiezen voor een risico. Elke leeruitkomst vraagt om ander bewijs.

De visie van Npuls op toetsing en AI benadrukt eerlijke, valide en leergerichte beoordeling, maar definieert geen “eigenaarschap van de student” en schrijft de onderstaande interpretatie niet voor. Dit is een redactionele toepassing van TraceYield.

Wat bewijs kan ondersteunen — en openlaat

Een codewijziging, testresultaat, toelichting, reviewnotitie of vastgelegde beslissing kan een begrensde uitspraak ondersteunen over wat is ingeleverd, gewijzigd, gecontroleerd of gezegd. Zo’n gegeven kan relevant zijn voor de leeruitkomst als het verband duidelijk is. Het laat niet automatisch zien waarom de student handelde, hoeveel hulp die kreeg of of de vaardigheid naar ander werk overdraagbaar is.

Een prompt kan tonen wat is gevraagd, maar niet of de student het antwoord begreep, overnam of controleerde. Het ACM Task Force-rapport beschrijft praktijken van docenten, zoals vragen over codebegrip en mondelinge beoordeling; het toont geen validatie van deze interpretatie. Een conceptueel artikel over AI-bestendige toetsing gebruikt “ownership of learning” voor het uitleggen, onderbouwen en uitbreiden van redeneringen, maar noemt de voorgestelde hulpmiddelen niet-gevalideerd. Dat zijn standpunten uit specifieke bronnen, geen universele definitie. Bewijs uit het ontwikkelproces gaat vooraf aan de vraag welke gegevens bruikbaar zijn; hier staat centraal wat geselecteerd bewijs kan ondersteunen.

Voorbeeld: een autorisatieregel in een API wijzigen

Voorbeeld ter illustratie — geen studentgegevens, klaslokaalonderzoek of TraceYield-pilotbewijs. Een HBO-ICT-student breidt een projectbeheer-API uit. Alleen de projecteigenaar mag een lid verwijderen. De leeruitkomst vraagt dat de student autorisatie op objectniveau uitlegt en implementeert, en toegang voor toegestane én geweigerde verzoeken controleert.

Een AI-codeeragent stelt een routehandler voor die controleert of de gebruiker is ingelogd en daarna het lid verwijdert. Een test met een gebruiker uit een ander project faalt: de gebruiker is wel geauthenticeerd, maar heeft geen rechten op dit project. De student past de handler aan zodat de rol wordt gecontroleerd voor het project waarop de wijziging betrekking heeft, voegt tests voor eigenaar en niet-eigenaar toe en voert de relevante tests opnieuw uit. In een korte toelichting zegt de student dat de eerste controle identiteit vaststelde, maar geen toestemming voor deze specifieke resource.

De opeenvolging is bruikbare context, maar laat de redenering niet zelfstandig zien. Misschien zag de student zelf de falende test, volgde die een suggestie van een medestudent of begreep die alleen deze route. Beoordeel het bewijs tegen de genoemde leeruitkomst; maak er geen algemeen oordeel over verantwoordelijkheid van.

Lees de gegevens als begrensd bewijs

Een vastgelegde wijziging toont dat de handler na het testresultaat is aangepast; zij bewijst niet wie het probleem bedacht. De tests tonen welke toegestane en geweigerde gevallen zijn gecontroleerd, niet dat elk autorisatierisico is afgedekt. De toelichting toont hoe de student in deze situatie reageerde; ze bewijst geen auteurschap, zelfstandigheid, blijvend begrip of transfer. Een gerichte vervolgvraag kan resterende onzekerheid verkleinen zonder die weg te redeneren.

Kies een vervolg dat de onzekerheid adresseert

Vraag alleen om vervolg wanneer een specifieke leeruitkomst onduidelijk blijft, niet enkel omdat AI is gebruikt of een registratie ontbreekt. Denk aan een gerichte codebespreking, een test laten uitleggen, een kleine verwante wijziging, een korte schriftelijke onderbouwing of een demonstratie. Kies een vorm die past bij de leeruitkomst en bied redelijke aanpassingen.

Kondig de aanpak waar mogelijk vooraf aan, gebruik dezelfde gepubliceerde criteria en houd de vraag in verhouding tot de resterende onzekerheid. Een onvolledige toelichting kan betekenen dat er nog onvoldoende bewijs is voor die leeruitkomst; zij bewijst op zichzelf geen fraude.

Waarom een score of percentage tekortschiet

Een percentage “door de student geschreven code” vertelt niet of die een eis kan uitleggen, een fout kan diagnosticeren of een implementatie kan controleren. Eén score voor verantwoordelijkheid voegt uiteenlopende vaardigheden samen en suggereert een nauwkeurigheid die het bewijs niet biedt.

Als een cijfer nodig is, beoordeel dan de genoemde leeruitkomsten met de criteria van de cursus. Beschrijf waarop het oordeel berust en wat de grenzen ervan zijn; beoordeel geen abstracte eigenschap.

Houd bewijs en beoordeling uit elkaar

TraceYield kan geselecteerde informatie uit sessies, projecten en profielen met elkaar verbinden, voor zover die gegevens zijn vastgelegd. Dat is een productbeschrijving, geen bewijs dat het product leren vaststelt of de verantwoordelijkheid van een student beoordeelt. De interpretatie van bewijs in dit artikel is geen onderwijskundig gevalideerde methode.

De docent beoordeelt het bewijs tegen de leeruitkomst, het toetsontwerp en de institutionele procedure. Voor de bredere vraag welke gegevens relevant kunnen zijn, zie Bewijs uit het ontwikkelproces. De individuele bijdrage binnen gezamenlijk geproduceerd werk is een andere vraag: Individuele bijdrage in een softwareproject.