Individuele bijdrage beoordelen in AI-ondersteunde softwareprojecten

Bijdrage is niet hetzelfde als auteurschap

Auteurschap vraagt wie een bepaalde regel of wijziging heeft gemaakt. Bijdrage vraagt welk relevant werk een student heeft verricht, beïnvloed, begrepen, gecontroleerd of geïntegreerd. Weinig code typen betekent niet automatisch weinig relevante bijdrage; veel code typen bewijst op zichzelf evenmin dat de leeruitkomst is behaald. Wanneer implementatie zelf wordt beoordeeld, blijft de code wel relevant bewijs.

Softwarewerk is vaak gedeeld: studenten programmeren samen, bespreken architectuur, reviewen elkaars wijzigingen of debuggen gezamenlijk. Soms voert de ene student een ontwerpidee van een ander uit; AI-code kan door meerdere teamleden worden aangepast. Dat maakt een individueel oordeel niet onmogelijk, maar vraagt om een begrensde conclusie binnen die gedeelde context.

Wat repositorygegevens wel en niet laten zien

Commits, diffs, tijdstippen en reviewdiscussies kunnen geregistreerde wijzigingen en bepaalde interacties tonen. Ze stellen niet vanzelf vast wie een idee bedacht, een AI-aanroep aanstuurde, samen debugde, offline reviewde, de code begreep of de leeruitkomst beheerst. Squashen, rebasen, cherry-picken, pair programming, gedeelde accounts, gegenereerde code en latere wijzigingen kunnen de toeschrijving verder bemoeilijken.

Git-documentatie beschrijft commitmetadata en repositorygedrag; zij valideert geen onderwijsconclusies. Gebruik repositorygegevens waar ze bij de claim passen, maar behandel ze niet als volledig verslag van de bijdrage.

Combineer bewijs doelgericht

Een korte bijdrageverklaring kan context geven en aangeven welke beslissing of wijziging de docent kan bekijken. Zo’n verklaring is de eigen weergave van de student, geen onafhankelijke bevestiging. Peer-informatie kan review, afstemming of ondersteuning zichtbaar maken, maar kan ook worden beïnvloed door ongelijke zichtbaarheid, geheugen, conflict of strategische beoordelingen.

Als een concrete onzekerheid over de leeruitkomst blijft bestaan, kan een gerichte vervolgvraag helpen: leg een keuze uit, interpreteer een test, diagnoseer een fout of voer een kleine verwante aanpassing uit. Eén goed antwoord bewijst geen algemene competentie; het is bewijs voor een afgebakende vraag op een bepaald moment.

Voorbeeld: een afspraakdienst in een projectgroep

Voorbeeld ter illustratie — geen studentgegevens, klaslokaalonderzoek of TraceYield-bewijs. Vier HBO-ICT-studenten bouwen een afspraakdienst. De beoordeelde leeruitkomst gaat over integratie, debuggen en verificatie. Een student heeft een kleine zichtbare codebijdrage, maar bespreekt de API-contracten, onderzoekt een falende integratietest en past een testcorrectie toe.

De docent bekijkt het contractgesprek, de falende test en de relevante correctie. Die records tonen welke keuzes en wijzigingen zijn vastgelegd; ze bewijzen niet zelfstandig wie het probleem ontdekte of hoe goed de student het begrijpt. Een gerichte vraag over de mismatch of een kleine verwante aanpassing kan die onzekerheid verkleinen. De uiteindelijke uitspraak blijft beperkt tot wat het bewijs voor deze leeruitkomst ondersteunt.

Ontbrekend bewijs is geen bewijs van wangedrag

Ontbrekende registraties zijn ontbrekend bewijs. Ze bewijzen geen niet-bijdragen, meeliften, verborgen AI-gebruik, wangedrag of gebrek aan begrip. Ze kunnen wel betekenen dat de docent nog onvoldoende basis heeft voor een bepaalde leeruitspraak. Een andere relevante bron, gerichte opvolging of een smallere conclusie kan dan passend zijn.

De beoordelingsvraag — is er genoeg bewijs voor de leeruitkomst? — staat los van een formele vraag over mogelijke overtreding van regels. Die laatste volgt de daarvoor geldende instellingsprocedure. TraceYield kan, waar gegevens zijn vastgelegd, context bieden over taken, AI-interacties, bijsturing, keuzes, correcties en verificatie. Het bepaalt geen auteurschap, bijdragepercentage, competentie, cijfer of wangedrag.

Maak de beoordeling vooraf begrijpelijk

Maak leeruitkomsten en bewijsverwachtingen vooraf bekend en geef studenten redelijke kansen om die uitkomsten te laten zien. Rollen en zichtbaarheid verschillen; beloon niet simpelweg wat het makkelijkst te tellen is. Houd rekening met passende voorzieningen en overweeg moderatie bij ingrijpende beslissingen. Verzamel alleen gegevens die voor het beoordelingsdoel nodig zijn en leg verwachtingen uit zonder onnodige surveillance. Voor verantwoordelijkheid en begrip, zie Verantwoordelijkheid van de student voor het werk; voor de selectie van ontwikkelgegevens, zie Bewijs uit het ontwikkelproces.