AI Can Write Your CS Assignment. But Can You?

Signup Write New Story AI Can Write Your CS Assignment. But Can You? by David Faster by David Faster | @ davidfaster Student at Delta State University. Writes about coding, debugging and study habits.

Student at Delta State University. Writes about coding, debugging and study habits.

There's a moment most CS students have had by now. You paste an assignment prompt into an AI tool and get back forty lines of clean, commented code. It runs, and the output looks right.

Then you try to explain line 23 to yourself and realize you can't.

That gap between "the code runs" and "I understand what this code does" is what this piece is about. In professional work it matters less than people admit. If a function passes review and the tests, nobody asks whether you could have written it from memory.

Coursework is different. The code isn't the product. Your understanding is, and the code is the evidence your marker uses to judge it. A working program you can't reason about is weak evidence, and it falls apart the moment someone asks a follow-up question in a lab, a viva, or an exam hall where the tool isn't available.

I've used AI tools through most of my degree and I'd still use them tomorrow. I've also watched them quietly cost people marks, including me.

When an assignment starts going badly, most people don't go straight to an AI tool. They research their options first, and that research usually happens in public. This thread on r/study is a decent snapshot of that phase. Students weigh tools, services, tutors and shortcuts before a single line of code gets written.

The questions in threads like that are revealing. They're mostly about speed and price, and almost never about what the student will understand at the end.

Wherever that research leads, the coursework still comes down to one thing. Do you understand what you're submitting? Every option, including AI, has to be judged against that question rather than against how quickly it produces something that compiles.

The tools are good at a lot, and it's worth being fair about that.

They're excellent at boilerplate: a class skeleton, argument parsing, the twentieth getter method you couldn't be bothered to type. They're a faster syntax reference than searching documentation, especially for things you half-remember, like a sort with a custom key or opening a file with a context manager. And they're good at scaffolding. Asking for the usual pieces of a linked list implementation can unblock you when you're staring at an empty file.

They're also fine as a rubber duck that talks back. Describing your problem in plain language often shows you where your thinking is fuzzy, even when the tool's answer is mediocre.

Where AI is clearly the right tool is after you've already solved something yourself. Asking it for an alternative approach, or to explain an unfamiliar library you're reading about, builds on understanding you already have instead of replacing it.

The catch is that each of these strengths is about producing text, not building understanding. A recent HackerNoon piece, Your AI Tutor May Be Helping You Learn Less, makes that case well, and it matches my experience. The feeling of progress and the fact of progress separate faster than you'd expect.

The first problem is that AI rarely tells you why it chose one approach over another. It might hand you a recursive solution without mentioning that an iterative one avoids stack depth issues. It might use a dictionary without explaining why a list would make lookups slower. In most CS modules, that reasoning is what's being graded.

I learned this the hard way in a second-year data structures assignment. My hash table worked perfectly. Then the written section asked me to justify my resize threshold. The honest answer was that the tool picked it and I'd never questioned it. The code got full marks. The justification didn't, and it was worth more.

The second problem shows up when something goes wrong. With your own code, you at least know what each line was meant to do. With code you didn't write, you have to work out the intent before you can find the bug. Pasting the error back into the tool often patches the symptom and leaves the logic wrong.

The third problem costs the most marks. Assignments are designed around edge cases. Marking tests check empty inputs, single elements, duplicates, negatives and boundary values. AI-generated code often passes the test you run by hand and fails the hidden ones. It was written to look correct, not to be correct.

The last problem is the long-term one, and there's now hard evidence for it. In 2025, PNAS published a randomized trial by Bastani and colleagues, Generative AI Without Guardrails Can Harm Learning: Evidence from High School Mathematics. Nearly a thousand students took part. Those given GPT-4 during practice sessions saw their practice grades rise sharply. When access was removed, they scored 17% lower on the exam than students who never had it. A version of the tool built to give hints instead of answers mostly avoided that drop.

The lesson for coursework is simple. The exam is the moment the tool leaves the room.

University policies reflect this. CS50's academic honesty policy at Harvard permits only the course's own AI tutor and treats third-party tools that suggest or complete code as unreasonable. Your own module's rules may be looser or stricter, but the reasoning is usually the same.

Here's a real pattern, simplified. An assignment asks for a recursive binary search in Python. It should return the index of a target in a sorted list, or -1 if the target isn't there. An AI tool produced this:

# Broken: high starts as exclusive, but the rest of the code treats it as inclusive def binary_search(arr, target, low=0, high=None): if high is None: high = len(arr) # bug: one past the last valid index if low > high: return -1 mid = (low + high) // 2 if arr[mid] == target: return mid elif arr[mid] < target: return binary_search(arr, target, mid + 1, high) else: return binary_search(arr, target, low, mid - 1) binary_search([1, 3, 5, 7], 5) returns 2, which is correct. Searching for 1 or 7 works too. Most people stop testing here.

Now try binary_search([1, 3, 5], 9). The first call has low at 0 and high at 3, so mid is 1. Since 3 is less than 9, it recurses with low at 2. Mid becomes 2, and 5 is less than 9, so it recurses again with low at 3 and high still at 3. The base case low > high is false, so it reads arr, which doesn't exist. You get an IndexError. An empty list crashes on the first comparison for the same reason.

The bug is a mismatch between two conventions. high = len(arr) treats the upper bound as exclusive. The base case and the mid - 1 step treat it as inclusive. Each line looks reasonable on its own. The error only appears when you hold both conventions in your head at once, which is exactly what tracing forces you to do.

# Fixed: high is inclusive everywhere def binary_search(arr, target, low=0, high=None): if high is None: high = len(arr) - 1 # fix: last valid index if low > high: return -1 mid = (low + high) // 2 if arr[mid] == target: return mid elif arr[mid] < target: return binary_search(arr, target, mid + 1, high) else: return binary_search(arr, target, low, mid - 1) The invariant is that if the target exists, it's somewhere in arr[low] through arr[high], both ends included. Every line now respects that rule.

The fix takes a few characters. Finding it requires understanding the invariant, and that's the part a marker is testing.

Python's standard library already has a tested implementation in the bisect module, and comparing your version against it is a useful exercise. Another HackerNoon piece, What Computer Science Students Actually Need When They're Stuck, makes a related point. What helps isn't more code. It's a way to see why the code you already have is wrong.

Understanding generated code means you can say, for every line, what it does and why it's there. A line you can't justify is a gap, even if the program works.

It means tracing execution by hand at least once with a small input and writing down the variable values at each step. Python Tutor will visualize the call stack for you, which helps most with recursion, where the confusion usually lives.

It means testing edge cases yourself instead of trusting that the tool thought of them: empty input, one element, the target at either end, a missing target, duplicates. Writing these as tests with Python's unittest framework takes ten minutes and catches exactly what marking scripts are built to find.

Most of all, it means explaining every decision with the tool closed. If your answer to "why recursion?" is "because that's what it gave me", you don't understand it yet.

This is the routine I've settled into, and it has saved me more than once.

First, I trace the code manually with a small, awkward input rather than a friendly one. Second, I check the input assumptions. Does the function expect a sorted list, a positive number, a non-empty string, and what happens if it doesn't get one? Third, I test the boundary conditions as written tests rather than a quick print statement. They catch more than I expect almost every time.

The fourth step is the one people skip. I pick at least one function and rewrite it from scratch with the AI version hidden. If I can't, I don't understand it well enough to submit it, and I'd rather find that out before the deadline than in the feedback. When my rewrite comes out different, comparing the two versions usually teaches me more than either did alone.

AI tools are a reasonable starting point for CS coursework. They're quick at the parts of programming that aren't being assessed. But the assessment is built to test understanding: the reasoning behind choices, the handling of edge cases, the ability to debug and explain. No tool can hand that over. Generated code is a draft you still have to earn, and the students who do well with these tools treat the output as something to interrogate, not something to submit.

It depends on your university and module. Some courses allow AI for specific tasks with disclosure, while others ban third-party tools outright for assessed work. Check your module handbook, and if it's unclear, ask the module lead before you use it.

Close the tool and explain each line out loud, including why it's there. Then trace the code by hand with an edge-case input and predict the output before running it. If you can rewrite one of the functions from scratch and get something that works, your understanding is probably solid.

Use them for syntax lookups, boilerplate and talking through a problem, not for the core logic you're being assessed on. Test edge cases yourself, keep track of what the tool contributed, and disclose that use if your course requires it.

Many do, in different ways. Some use similarity and detection tools. Others rely on vivas, live coding tasks or exam questions about your own submission. Being asked to explain your code in person is the hardest check to pass if you don't understand it.

Your AI Tutor May Be Helping You Learn Less