Assessing programming assignments in the age of AI means evaluating what students understand and can do, not trying to guess an author from code alone.

A balanced approach combines a well-designed assignment, transparent AI rules, evidence of the development process, and a consistent rubric.

Why programming assessment needs a broader approach

Generative AI tools can produce code, explain errors, suggest tests, and help revise solutions.

That changes how students may complete an assignment, but it does not make every AI-assisted submission dishonest.

The relevant question is whether the student met the learning objectives under the rules communicated for that task.

Code can also look polished without demonstrating understanding.

Conversely, a student may submit code with familiar patterns because they learned from the same examples, libraries, or course materials as their classmates.

Style, formatting, and apparent sophistication are weak evidence of who wrote a program.

Assessment should therefore separate several questions: Does the program meet the requirements?

Does the student understand the key decisions?

Did the work follow the course’s stated rules?

Are there specific, verifiable concerns that warrant a follow-up?

Keeping these questions distinct helps avoid treating suspicion as proof.

Start with learning objectives and clear AI rules

Before assigning work, identify the skills the assignment is meant to measure.

An exercise intended to teach algorithm design may need different AI-use limits from a project focused on using APIs or testing a larger system.

State whether students may use AI for brainstorming, debugging, code generation, documentation, or other tasks.

Make expectations concrete.

If AI assistance is allowed, explain whether students should disclose it and what information to include, such as the tool’s role and which parts they reviewed or changed.

If certain uses are prohibited, say so before students begin.

Avoid relying on unwritten expectations that students may interpret differently.

Policies vary across schools and courses, so instructors should follow the applicable institutional process.

A disclosure statement can provide useful context, but it should not replace assessment of the submitted work or establish misconduct by itself.

Design assignments that reveal reasoning

Tasks are more informative when they require students to make and explain choices.

Instead of assessing only whether a program produces the expected output, include elements that connect implementation to course concepts.

  • Ask for a short design note: Have students describe their approach, a trade-off they considered, and one limitation.
  • Require tests with a purpose: Ask students to explain why selected cases matter, including boundary or failure cases.
  • Use staged submissions: A proposal, early version, test plan, or brief change log can show how the solution developed.
  • Include a targeted modification: Ask students to adapt their solution to a small new constraint or requirement.
  • Connect tasks to course material: Require use or comparison of concepts students have practiced, rather than adding complexity for its own sake.

These elements are not foolproof.

Students can receive help at different stages, and a process artifact can also be incomplete or mistaken.

Their value is that they create more opportunities to assess learning directly.

Use a rubric that rewards demonstrated understanding

A rubric makes grading more consistent and helps students understand what quality means.

Match each criterion to the learning objectives, and distinguish functional correctness from other dimensions of programming work.

  • Correctness: Does the program satisfy the stated requirements and handle relevant edge cases?
  • Reasoning: Can the student explain the algorithm, data structures, or design decisions?
  • Testing: Are tests relevant, and can the student explain what they do and do not cover?
  • Code quality: Is the code readable, organized, and appropriately documented for the task?
  • Revision and reflection: Can the student identify a limitation or explain a change made during development?

Do not let surface features stand in for authorship.

A sudden change in style may suggest a question to explore, but it is not a finding on its own.

Prior submissions can offer context, yet students’ skills and coding habits naturally change over time.

Check understanding through a focused follow-up

When a submission raises a specific concern, a brief, neutral conversation can clarify what the student understands.

Ask about identifiable parts of the work: why a function uses a particular approach, what a test verifies, or how the program would change if a requirement shifted.

Keep the questions tied to the assignment and give the student a fair chance to explain.

A student’s difficulty answering one question is not automatic proof of misconduct; stress, communication differences, or an unfamiliar phrasing can affect performance.

Record the evidence and follow the institution’s normal review process if concerns remain.

Understand what detection tools can and cannot show

AI writing classifiers attempt to estimate whether text resembles machine-generated output, but their results do not establish who created a submission or whether a student violated a policy.

A score should not be treated as proof of authorship or misconduct, and any result needs to be interpreted alongside direct evidence and the course rules.

Code similarity tools address a different question: whether submitted source code shares structure or text with other known code.

Similarity can arise from collaboration, shared starter files, common solutions, libraries, or copied work.

A match calls for interpretation; it does not by itself prove intent or identify AI use.

Product categories matter.

Turnitin says its AI writing model does not reliably detect code, so an AI writing report should not be confused with source-code similarity analysis.

Codespy is an external source-code detector.

If considering a tool such as Codespy, review its documented scope and use its output only as one limited signal; do not imply that a result verifies authorship or misconduct.

Make decisions with evidence and consistency

A defensible assessment draws on the assignment requirements, the rubric, student explanations, process materials where required, and any specific similarity findings.

Apply the same standards to comparable submissions, protect student information, and give students a clear way to respond to concerns.

Most importantly, keep the decision focused on demonstrated learning and the rules that applied to the assignment.

A well-designed assessment gives students a fair opportunity to show their skills while giving instructors better evidence than a detector score or writing style alone.