Code Defense: How to Assess Computer Science Assignments in the Age of AI
Autograders verify that code runs, but generative AI produces functional code in seconds. Here is how computer science faculty use code defenses to verify genuine understanding at scale.
For decades, computer science education relied on automated grading pipelines. Instructors configured test suites in autograders like Gradescope or Autolab. Students submitted code, and the autograder compiled it, ran unit tests, and calculated a score. Instructors monitored collaboration with tools like Stanford University's Measure of Software Similarity (MOSS).
Generative artificial intelligence disrupted both sides of that system.
Modern foundation models solve undergraduate programming assignments on command. A student can paste a specification into an assistant and receive code that compiles, handles edge cases, and passes test suites on the first attempt. Because these tools synthesize unique variable names and control flows, similarity detectors like MOSS report clean results. The autograder awards full marks, yet the instructor cannot determine whether the student spent twenty hours building the data structure or twenty seconds running a prompt.
When software generates functional code on demand, working syntax stops serving as dependable evidence of learning. Computing departments cannot resolve this issue by returning to blue-book exams or installing surveillance software. Computing education needs an authentic assessment method that verifies student comprehension directly: the code defense.
Why Paper Exams and Surveillance Distort Computer Science Pedagogy
When generative coding tools spread, departments adopted defensive workarounds: returning to handwritten coding exams or requiring code on locked-down lab terminals.
Both approaches distort computing pedagogy.
Handwritten code measures syntax recall under artificial constraints. Professional software engineers write code with compilers, linters, documentation, and debuggers. Paper exams penalize a missing semicolon while ignoring how students diagnose runtime exceptions or reason about architecture.
Remote proctoring and locked browsers introduce severe privacy friction. Multilingual students and neurodivergent learners experience heightened anxiety, while technical students bypass screen recorders using secondary hardware. Furthermore, professional engineering never evaluates developers solely on raw syntax. In industry, engineers participate in technical interviews, explain architecture in design reviews, and defend pull requests. Asking students to explain and defend their implementation reflects authentic engineering practice, aligning with broader movements toward authentic assessment across higher education.
What Is a Code Defense?
A code defense, derived from the viva voce oral tradition, is an assessment method where a student verbally explains and justifies their submitted codebase.
The code defense treats the submitted codebase as an artifact to be examined. An autograder verifies technical correctness. The code defense verifies comprehension, moving beyond the documented limitations of AI detection versus verification of learning.
During a code defense, students explain code structure, trace execution through critical logic paths, justify algorithmic trade-offs, and account for design decisions. If a student used an external tool to generate boilerplate, they must still command the underlying logic. Students who prompted a model without understanding the code struggle when asked to trace state mutations or explain why a specific data structure was chosen.
Computing education researchers at the ACM Special Interest Group on Computer Science Education (SIGCSE) emphasize this distinction. The primary assessment challenge in computing is code comprehension and verification of understanding.
Five Probing Modes for Code Defenses
Effective code defenses avoid generic trivia questions. Asking a student to define a binary search tree tests memorization. Effective questioning anchors inquiries directly in submitted code through source-grounded questioning.
Code defenses use five structured probing modes:
1. Execution Tracing and State Mutation
Execution tracing probes ask students to simulate runtime state mentally:
"Look at lines 42 through 58 of your TaskManager.py file. Suppose the input list contains three tasks with identical priority values. Walk me through the state of your heap array after the second call to insert, and explain which condition terminates your while loop."
To answer, students must command internal implementation logic. Students who prompted an external assistant cannot track pointers, array indices, or state mutations under direct questioning.
2. Algorithmic Trade-Offs and Complexity Analysis
Trade-off probes examine why students selected a specific approach over alternatives:
"In your graph traversal module, you chose an adjacency list. Explain how that decision affects the Big-O time complexity of your neighbor-lookup function, and identify the graph density conditions where an adjacency matrix provides superior memory efficiency."
These questions connect lecture concepts directly to concrete lines of submitted code.
3. Edge-Case and Failure-State Handling
Failure probes examine boundary behavior:
"In your asynchronous worker service in queue_consumer.ts, you implemented optimistic locking on the inventory record. If two concurrent workers checkout the same item simultaneously and the database transaction times out, how does your error-handling block prevent a partial write?"
Students commanding the architecture explain failure recovery immediately, while those relying on unexamined machine output falter.
4. Justification of Design Patterns and Rejected Alternatives
Design justification probes investigate architectural deliberation:
"You implemented this parsing pipeline using an iterative state machine. What call stack considerations prompted that design choice, and how would your implementation adapt if the input file exceeded available system memory?"
Probing alternatives reveals whether students engaged in authentic engineering deliberation or accepted initial AI output.
5. Live Refactoring and Hypothetical Modification
Refactoring probes present requirement modifications and evaluate architectural adaptability:
"Suppose our client requires this REST endpoint to support cursor-based pagination. Point to the specific functions in your controller and database files that must adapt, and explain how you would adjust your indexing strategy."
Students commanding the architecture map modifications across files in seconds, confirming genuine codebase ownership.
Concrete Implementation Across Two Courses
To understand how code defenses operate in practice, consider two departmental implementations.
Data Structures (CS2)
In a sophomore data structures course, students implement an AVL self-balancing binary search tree in Java, submitting code to an autograder for functional testing.
The instructor configures an asynchronous code defense in Rocketproof. The platform ingests student .java files, parses the syntax tree, and generates targeted questions following assignment redesign for generative AI:
- "In
rebalanceon line 87, explain why a single right rotation is insufficient for a left-right imbalance, and trace how the root pointer updates." - "Your
deleteNodemethod uses an in-order successor to replace a node with two children. How would your balance factor calculations change if you selected the in-order predecessor?" - "Walk me through how
heightavoids an O(n) traversal on each node lookup."
The student records spoken explanations. The instructor reviews the recording alongside the code and transcript, confirming that the student commands tree mechanics.
Systems Programming and Operating Systems
In an upper-division operating systems course, students build a multi-threaded web server in C using POSIX threads, socket programming, and mutual exclusion locks:
- "In
server.c, look at line 64. Explain why your condition variable wait sits inside a while loop, and identify the race condition that occurs during a spurious wakeup." - "Explain how your thread pool coordinates graceful shutdown upon receiving a SIGINT signal. Where do you join worker threads, and how do you avoid dropping in-flight socket requests?"
- "If this server executes on a single-core virtual machine compared to an eight-core host, how does lock contention on your shared request queue affect throughput?"
These questions separate superficial code assembly from systems comprehension.
Solving the Faculty Workload and Scalability Barrier
European universities historically relied on viva voce examinations for computing degrees, and technical hiring centers on live technical discussions. Computing departments abandoned oral exams for regular coursework because conducting ten-minute walkthroughs for 150 students demands 25 hours of grading per assignment.
Modern educational platforms resolve this scalability barrier through asynchronous, source-grounded verification on the oral defense platform.
Using Rocketproof, instructors upload assignment specifications, rubric criteria, and source files directly, supporting Python, Java, TypeScript, C, C++, and SQL:
- Asynchronous Completion: Students complete defenses on their schedule within a testing window, speaking responses or using text chat.
- Source-Grounded Questioning: Rocketproof analyzes submitted files, linking questions directly to specific function declarations, loops, and variable scopes.
- Synthesized Evidence Layer: The platform transcribes spoken audio, pairs timestamped quotes with rubric criteria, and drafts scoring notes for AI-supported rubric evaluation.
- Faculty Grading Sovereignty: The platform never assigns final grades autonomously, preserving faculty-controlled AI assessment. Instructors review code alongside timestamped explanations, adjust rubric levels, and finalize scores in two to three minutes per student.
The instructional team completes verified grading in a fraction of the time. For more on scaling verbal assessments across large cohorts, read our guide on how oral assessment works in a class of 100 students, and explore how departments manage sustainable faculty workloads in authentic assessment.
Structuring the Grade: The 70/30 Assessment Model
When transitioning to code defenses, instructors should avoid making the defense an all-or-nothing hurdle. A reliable structure is the 70/30 assessment split:
- 70% Functional Correctness (Autograder): Awarded for unit tests, compilation, edge-case coverage, and memory leak analysis, rewarding code that meets functional specifications.
- 30% Code Defense (Verification): Awarded for the student's explanation. Rubric criteria evaluate algorithmic reasoning, execution tracing accuracy, awareness of complexity trade-offs, and communication clarity.
Under this model, students who generate code with AI without understanding it earn at most a passing mark. Earning top marks requires explaining implementation. Rocketproof provides private practice sessions where students rehearse audio and review rubric criteria before graded attempts.
Rocketproof integrates natively with campus learning management systems through LMS-integrated AI assessment via LTI 1.3, including dedicated workflows for Canvas AI assessment.
Universal Design for Learning and Accessibility in Technical Defenses
Computer science programs serve diverse student populations, including students with speech disabilities, chronic vocal fatigue, and social anxiety. Fair assessment design requires flexible demonstration modes that accommodate diverse learners without compromising cognitive standards.
Rocketproof applies Universal Design for Learning (UDL) principles across all technical evaluations:
- Multi-Modal Response Options: Students with accommodations can complete defenses through an interactive text interface. The questioning engine probes identical code lines and evaluates algorithmic understanding under identical rubric criteria.
- Structured Preparation Windows: Instructors can provide untimed review windows to inspect submitted code files before recording explanations, reducing situational anxiety.
- Low-Stakes Practice Mode: Students can complete unlimited practice defenses against sample questions, familiarizing themselves with the interface before submitting an evaluated defense.
To explore institutional accessibility standards in detail, review our guide on accessibility in oral assessment.
Frequently Asked Questions
What happens if a student experiences severe speech anxiety or has an approved accommodation?
A code defense measures programming comprehension, not public speaking fluency. Students with documented accommodations can use text chat mode, typing explanations and tracing execution paths under identical rubric standards. For details on designing equitable verbal evaluations, read our guide on accessibility in oral assessment.
Can students memorize answers to cheat the defense?
No. Questions derive dynamically from specific variable names, helper routines, and structural decisions within each student's unique codebase, making pre-written answer banks useless. Adaptive follow-up questions probe immediate statements, preventing scripted recitation.
Does code defense replace tools like Gradescope or Autolab?
No. Autograders remain useful for verifying compilation, running test suites, and calculating execution benchmarks. Code defenses complement autograders by filling the comprehension gap, ensuring that the student behind the screen understands the code that passed the tests.
How does the platform protect against prompt injection in student code?
Student source files are treated as inert text. Rocketproof enforces strict architectural isolation between untrusted code comments and system instructions. If a student embeds prompt injection strings in comments, the questioning engine treats the text as passive data that cannot alter system evaluation parameters.
Bringing Code Review Culture to the Classroom
The arrival of generative AI does not mean the end of computer science homework. It marks the end of relying solely on automated unit tests as a proxy for human understanding.
Software engineering has always centered on design decisions, system trade-offs, and peer communication. By integrating asynchronous code defenses into programming courses, universities can prepare students for professional software engineering while ensuring that academic credentials represent authentic student mastery.
To explore how Rocketproof enables scalable code defenses and authentic assessment for your computing department, explore our oral exams platform, learn about our AI simulation platform, or schedule an interactive demo.
See Rocketproof in action
Explore the interactive demo as a student and an instructor, or request a pilot for your department.