Last fall, I assigned a programming project I had used for years. Several students turned in working code far faster than I expected, and the output was correct. So I asked one of them a question I have asked a hundred times: “Why does this algorithm work?”
The room went quiet. What happens if the input changes? What is the time complexity? Students looked back at their screens. The solutions were strong. The understanding was harder to find.
Generative AI did not create the gap between a correct program and a student who can account for it. That gap has always existed. But AI has widened it and, more importantly, made it easy to cross without anyone noticing. A student can now produce a clean, correct, well-commented solution to a typical assignment in seconds. The finished program tells me less than it used to.
For those of us who teach computer science, this is not a reason to panic, and it is certainly not a reason to abandon rigor. It is a reason to move the thing we grade. The question is no longer mainly “Did the student produce working code?” It is “Can the student verify, explain, adapt, and defend it?”
The Problem with Grading Finished Programs
CS assessment has always leaned on a convenient proxy: working code is evidence of understanding. If the program compiles, passes the tests, and returns the right answer, we assume the student knows what they built. That proxy held up for a long time, because producing working code used to require understanding it.
That link has loosened. A polished product can now be generated without the cognitive work it used to require, which means a correct program is a weaker signal of learning than it once was. In a 2024 blind study at the University of Reading, researchers fed entirely AI-generated answers into a live university examination system; 94% went undetected, and on average they scored higher than real students’ work.
The instinct is to respond by detecting AI use. I understand the appeal, but it is a detour. The detectors are unreliable—OpenAI withdrew its own text classifier in 2023, citing a low rate of accuracy—and research has also shown that AI detectors can disproportionately misclassify writing by non-native English writers as AI-generated. More to the point, even a perfect detector would answer the wrong question. Knowing whether a student used AI tells me nothing about whether they learned. Detection sorts students by tool use. Assessment should sort them by understanding.
Verification-based Assessment
So, I stopped trying to keep AI out of the room and started building an assessment around what I actually want to know. When I say verification, I do not mean policing. I mean demonstrated understanding: students may use AI while they learn, but they must be able to explain, adapt, and defend what they submit independently.
This is not a foreign standard imported to cope with AI. It is what professional engineering already looks like. Practicing developers spend far more time reading, testing, reviewing, and debugging code than writing it from scratch. They work constantly with code they did not author—from libraries, teammates, and now models—and the job is to determine whether it is correct, where it will break, and whether it is the right design. Verification is not an AI workaround. It is the discipline at the center of computing.
What This Looks Like in My Classroom
I tell students plainly that AI is in the room. They may use it to brainstorm approaches, debug, or revise. The expectation I set up front is simple: use the tools openly, but own your thinking. The assessment then targets the thinking, not the artifact. A few moves do most of the work.
Explain the code line by line. I ask students to walk through a solution and narrate what each part does and why. With AI-generated code, this is revealing. Students who engaged with the tool can explain the logic and the tradeoffs. Students who pasted an answer stall on the first nontrivial line.
Write tests for code you did not fully write. Handing a student a working function and asking them to test it flips the task from production to scrutiny. Good tests require understanding the contract: what the function promises, where the edge cases live, what an empty input or a boundary value should do. You cannot write a meaningful test for behavior you do not understand.
Find what the AI got wrong. I sometimes give students a plausible but flawed solution—one with an off-by-one error, an unhandled empty case, or an O(n²) approach where O(n log n) is available—and ask them to find and justify the problem. This rewards exactly the critical reading that fluent AI output discourages.
Compare two implementations. When students choose between two approaches and defend the choice on grounds of readability, time and space complexity, or maintainability, they reason about design rather than just output.
Submit an AI-use note plus verification notes. Students keep a brief record of what they asked a tool, what they kept, what they rejected, and why—paired with how they checked that the result was correct. This makes the process visible and builds metacognition.
Defend the design out loud. A five-minute conversation at a whiteboard, or a timed “modify and explain” task—predict the output for a new input, adjust the algorithm for a new constraint, narrate a debugging process—surfaces understanding quickly. The point is not to trap students. It is to make reasoning visible.
The pattern I see is consistent. Students who used AI as a learning partner can explain their work and adapt it under a new constraint. Students who outsourced the thinking struggle quickly, even when their submitted code looks flawless.
The same logic extends past the intro course. In machine learning, a model that reports high accuracy is the beginning of the question, not the end: I ask students whether the result would hold on data the model has not seen, and whether the strong number is real or an artifact of leakage. In robotics, code that runs in simulation routinely fails on hardware, and explaining that gap is itself the assessment.
If You Are Starting Small
None of this requires rebuilding a course over a weekend. If you are starting small, keep the assignment you already have and add a single verification task. Students submit the program, then answer three short questions:
- How does it work?
- Where might it fail?
- How did you test it?
Those questions take a few minutes on both sides, and they tell you more about who understands the work than the program itself does. Once that feels routine, you can grow it into a fuller framework: allow AI as a tool, with purpose, rather than driving it underground; require transparency through a short AI-use note (and teach students not to paste classmates’ personal information or other sensitive data into third-party tools); design tasks that test transfer, asking students to modify a program for a new constraint or predict its behavior on a new input rather than just submit it; and grade thinking, not just polish, with rubrics that reward explanation, testing, tradeoff analysis, and revision.
A Fair Word of Caution
Verification is not automatically fair. Live, on-the-spot explanations can disadvantage students who need processing time and multilingual learners—the same groups unreliable detectors tend to harm. So build in options: let students explain in writing or out loud, share question stems in advance, and give low-stakes practice before anything is graded. The goal is to make thinking visible, not to put students on the spot.
Verification is the Skill, Not the Workaround
It is tempting to treat all of this as damage control—a set of tactics for the awkward years until we figure out what to do about AI. I think that gets it backward. Reading code critically, testing it, reasoning about its limits, and defending a design were always the marks of a strong computer scientist. We could lean on the finished program as a proxy for those skills because, until recently, you could not produce the program without them. That shortcut is gone.
AI has not made computer science assessment obsolete. It has made verification essential—and, in doing so, it has pushed us toward assessing the thing we cared about all along.
About the author
Shreyas Rane teaches computer science and machine learning at St. Paul’s School in Concord, New Hampshire. His courses span programming, AP Computer Science, machine learning, and robotics. He is interested in how AI is reshaping assessment, and in designing classroom work that keeps student thinking—not just the finished product—at the center.