Designing programming assignments with AI allowed means deciding what students should learn, what assistance they may use, and how they will show their own understanding.
The most useful change is often to assess the decisions behind a program as well as the code it produces.
Start with learning outcomes, not AI restrictions
Begin by identifying the skills the assignment is meant to develop.
These might include decomposing a problem, choosing data structures, tracing program behavior, testing edge cases, reading unfamiliar code, or explaining a design trade-off.
State the outcomes in observable terms so students understand what successful work demonstrates.
Then decide where AI assistance fits.
If the main goal is learning syntax, unrestricted code generation may obscure whether students can write basic constructs themselves.
If the goal is evaluating a solution, students might be allowed to use an AI assistant while being asked to test, critique, and adapt its suggestions.
The policy should follow the learning objective rather than assume that every AI use helps or harms learning in the same way.
Write a specific, usable AI policy
“AI is allowed” leaves important questions unanswered.
Students need to know whether they may use tools for brainstorming, explaining concepts, generating tests, debugging, or producing code.
Explain what they must do when they use a tool, such as verifying outputs, documenting substantial assistance, or being ready to explain submitted work.
Make the policy assignment-specific and consistent with the course’s broader rules.
Institutional and instructor policies vary, so do not imply that one disclosure standard applies everywhere.
A short section in the assignment brief can clarify:
- Which kinds of AI assistance are permitted for this task.
- Which actions are outside the assignment’s rules, if any.
- What students should document, and where that documentation belongs.
- How students can ask questions when an AI response or policy boundary is unclear.
Focus on transparent expectations instead of asking students to prove a negative.
A policy that students can follow is more useful than a vague warning about detection.
Build in constraints that reveal reasoning
Broad prompts often invite generic solutions.
Add constraints that require students to interpret the problem and make defensible choices: a specified input format, memory limit, required interface, unfamiliar data set, or a set of edge cases.
Constraints should serve the learning outcome, not create arbitrary obstacles or reward guessing an instructor’s hidden preference.
Ask students to explain one or two consequential design decisions.
For example, they might justify a data structure, describe how they handle malformed input, or compare two approaches using complexity or maintainability.
A concise explanation tied to the submitted program helps connect implementation to understanding without turning every coding task into a long essay.
Where appropriate, use staged work.
Students can submit a short plan, an initial implementation, test results, and a revised version.
Checkpoints make the development process visible and give students feedback while changes are still manageable.
They also make it easier to assess whether the final code addresses the stated requirements.
Assess process and product together
A strong rubric separates what the program does from how well the student can reason about it.
Depending on the course, criteria might include correctness, testing, code clarity, design choices, and explanation.
Share the criteria in advance, and avoid scoring AI disclosure as a substitute for technical quality or comprehension.
Process evidence should be proportionate.
Useful evidence may include a test plan, a brief change log, a small number of representative prompts and outputs, or notes describing how suggestions were checked.
Avoid demanding extensive chat transcripts when a focused account of consequential assistance would answer the instructional question.
For higher-stakes work, consider a short follow-up conversation or a small modification to the submitted program.
Ask the student to trace a function, explain a failure, or adapt the solution to a changed requirement.
These activities provide direct evidence of understanding, but should be accessible, relevant to the assignment, and applied consistently.
Make testing and verification part of the task
AI-generated code can look plausible while containing logic errors, incorrect assumptions, or fragile handling of inputs.
Treat verification as a learning objective.
Ask students to design tests that cover normal cases, boundary conditions, and likely failures, then explain what the results show.
Provide a clear specification and, when appropriate, sample inputs and expected outputs.
Students can compare their program’s behavior against these examples, but should also create tests that go beyond them.
Instructors can use hidden tests for robustness, while ensuring the public requirements give students enough information to understand the intended behavior.
Ask students to identify one limitation in their implementation or one AI suggestion they rejected or changed, when that fits the learning goal.
This encourages evaluation rather than uncritical acceptance.
It also gives students a practical reason to inspect generated code carefully.
Use authentic tasks while protecting fairness
Assignments tied to a specific context can prompt more thoughtful work than a stock exercise, especially when students must explain how the requirements shape their solution.
A local data set, a scenario discussed in class, or a choice among project extensions can make reasoning easier to evaluate.
Keep the task achievable with the resources students are permitted to use.
Consider access and accommodation.
Students may not have the same devices, accounts, connectivity, or familiarity with AI tools.
If using a particular service is required, explain how students can access it and offer an equivalent path when feasible.
Do not make paid features or disclosure of unnecessary personal information a hidden prerequisite for completing the assignment.
Keep academic integrity expectations separate from automated detection claims.
AI authorship classification attempts to infer whether text or code was generated by AI; code similarity tools compare code for overlap or copying.
These are different tasks.
Detection scores alone do not prove who wrote code or establish misconduct.
Turnitin states that its AI writing model does not reliably detect code, so its writing report should not be treated as a source-code similarity check.
If a source-code detector such as Codespy is considered, describe its role narrowly and do not present an automated result as a verdict.
Review the assignment after students complete it
After the first run, examine where students struggled and whether the evidence you requested actually showed the intended skills.
Look for unclear policy language, unnecessary documentation burden, tests that reward memorizing a pattern, or rubric criteria that cannot be applied consistently.
Student questions and common implementation errors can reveal where the brief needs revision.
Keep the next version focused: clarify one ambiguous requirement, improve an example, or adjust a checkpoint.
A well-designed AI-permitted programming assignment does not need to anticipate every possible tool interaction.
It needs clear learning goals, realistic expectations, and a fair way to see how students think about the programs they submit.