How to Design AI-Resilient Programming Assignments
How to design programming tasks that still require meaningful student decisions when AI is available, without claiming any task can be AI-proof.
TraceYield Insights
6 min read · Updated October 6, 2026
Resilience is not proof against AI
An AI-resilient programming task does not guarantee that a student cannot obtain assistance or that a model cannot produce a plausible solution. The narrower design question is whether the task still asks students to make a meaningful programming decision in context when AI is available.
That is different from designing the whole assessment. The broader HBO-ICT assignment guide covers alignment among learning outcomes, AI conditions, evidence and assessment. This page focuses on the task the student has to solve.
Compare the programming task
Before — underspecified: “Add retry handling to the event-registration API.” This names a feature, but leaves the relevant behavior, constraints and technical decision unclear.
After — context with a decision to make: “The registration client may retry a request after a timeout, even when the server has already created the registration. Existing clients also depend on the API’s current error response format. Extend the service so a retry does not create a second registration. Use the supplied API contract and repository tests. Choose where duplicate-request protection belongs, explain the trade-off for this service, and test both a repeated request and a rejected request.”
The intended performance is not simply producing retry code. The student must interpret the service contract and decide how this service should distinguish a repeated request from a new registration. A code assistant can suggest an idempotency key, a database constraint or another approach; the student still has to determine which fits the provided contract and demonstrate the behavior in this repository.
The design should not hide requirements or rely on private data. Provide the contract and test setup to everyone, make permitted tools and access alternatives clear, and avoid grading every intermediate file merely because the task has stages.
What the redesigned task can and cannot do
The added constraints make the technical choice visible and give the student a concrete behavior to test. They do not make the answer inaccessible to AI, guarantee that the student made the decision unaided, or prove general competence. The task is useful when those choices are relevant to the learning outcome—not because it is difficult for a model.
Keep the constraint educationally relevant
A task can become unfair or merely confusing if its “authentic” context depends on a particular paid model, unstated domain knowledge or access to real customer data. State the system behavior and constraints explicitly, provide a workable tool alternative where needed, and check that the decision being elicited is actually part of the course outcome.
Not every task needs this treatment. A short exercise may appropriately assess a basic concept under controlled conditions. Resilience is a design choice for the learning being assessed, not a requirement to make every assignment open-ended.