How to Assess Individual Contribution in AI-Assisted Software Projects

Contribution is not the same as authorship

Authorship asks who produced a particular artifact or change. Contribution asks what assessment-relevant work a student performed, influenced, understood, verified or integrated. Typing most of the code does not by itself establish the learning outcome; typing little code does not by itself mean little relevant contribution. Neither claim should be accepted without appropriate evidence.

Software work is often shared: students pair or debug together, discuss architecture, review changes, shift responsibilities, or build on one another’s ideas. One student may implement a decision another developed; multiple people may revise one change. These are normal collaborative conditions, not contamination to be removed. The assessment task is to make a bounded individual judgment within that shared work.

Use repository evidence for what it shows

Commits, diffs, timestamps, configured author/committer metadata, and platform reviews can provide useful evidence about recorded repository changes. They do not automatically establish who conceived a change, understood it, directed an AI interaction, debugged with a partner, or reviewed work outside the repository. Squashing, rebasing, cherry-picking, shared environments, pair programming, generated code and later edits can further complicate attribution. Git’s own documentation describes the fields it records; it does not make those fields proof of a student’s identity or learning (git-commit documentation).

Constructed example: integrating an appointment-scheduling service

Constructed example — not student data, classroom research or TraceYield evidence. Four HBO-ICT students build an appointment-scheduling service with AI tools permitted. The outcome for one student is: “Integrate a client and scheduling API against a defined contract, diagnose a mismatch, and verify the correction.” Responsibilities shift during the project, and the student under review has a relatively small visible code footprint.

Project context: An API-contract discussion records that the client sends a time-zone offset. A failing integration test shows the service interpreting a slot differently from the client. A review thread and a focused test change record the team’s investigation and correction. These records show parts of shared work; task allocation or a small diff alone would not establish who diagnosed the issue.

Relevant follow-up: The lecturer asks the student to interpret the failing test, explain the contract mismatch, and describe or make a small related adaptation. The student connects the test condition to the API contract and identifies what the revised check verifies.

Bounded judgment: Taken together, these records and the follow-up may support a claim that the student demonstrated diagnosis and verification relevant to this integration outcome in this project. They do not establish that the student originated every decision, authored all related code, worked independently, or has general competence across integration problems. The small code footprint is neither a reason to award credit nor to withhold it.

Use proportionate evidence and follow up fairly

Evidence might include a relevant change or test, a design or review discussion, a student’s short account, or peer/context evidence. Each answers a different question. A student statement can identify work to inspect or guide a follow-up, but it does not independently verify the claim. Peer evidence may surface coordination or support that is less visible elsewhere; it can also reflect unequal visibility, memory, conflict or strategic ratings. A 2026 review mapped 75 peer-evaluation instances across 50 software-engineering education studies and interviewed seven educators; it documents varied practice, not a universal fairness guarantee (review). Select only evidence relevant to the assessment purpose, rather than requiring logs or records for every action.

Tell students the learning outcomes and relevant evidence expectations in advance. Collect only evidence relevant to that purpose and explain what will be considered; do not collect a complete activity trail simply because it is available. Ensure students have reasonable opportunities to demonstrate the outcomes, account for changing roles, and use proportionate accommodations. Moderate consequential judgments where appropriate. A focused explanation, test interpretation or small modification may address a named uncertainty; it is one evidence source, not proof of general competence. For selecting process records, see Process Evidence; for an oral exchange as one method, see Oral Defense.

Missing records are missing evidence. They do not establish non-contribution, free-riding, hidden AI use, misconduct or lack of understanding. They may mean that the lecturer cannot yet support a particular assessment claim. Seek another relevant source, use a proportionate follow-up, or narrow the conclusion rather than inventing certainty in either direction.

Keep assessment insufficiency separate from a misconduct question. Whether there is enough evidence for a learning judgment is not the same question as whether an institutional rule was violated under the institution’s procedures. Do not infer misconduct from low commit counts, missing logs, AI use or limited visibility.

TraceYield may provide context around task framing, AI interactions, human steering, technical decisions, corrections and verification where those records are captured. They do not determine a contribution percentage, authorship, competence, learning, misconduct, fairness or grade. The lecturer retains the assessment judgment.