KotlinCS 124 LogoJava

CS 124 for Educators

CS 124 is introductory computer science (CS1) at the University of Illinois, enrolling over 2,000 students per year. 80% are non-majors. Here’s what we’re doing and why.

Geoff Challen has been teaching the course since Fall 2017, and along the way we’ve learned a lot about what works when teaching intro CS at scale. A recent talk at the University of Sydney overviews many of the course innovations described below.

Teaching Conversational Programming
Teaching Conversational Programming

This is where things have gotten really interesting.

The journey. In Fall 2024, we began allowing students to use AI on the course project as an experiment. Over the summer of 2025, Geoff tested whether Claude could complete the Fall 2025 project from test suites alone—and it could, completing almost everything with minimal human intervention.

In Fall 2025, we tried a compromise: keeping the same project structure while allowing AI. But it didn’t work. Traditional programming assignments hinge on a specification that students translate to code, and AI coding agents have become too good at that translation step. The tension between precise specifications—needed for fair automated grading—and imprecise specifications—needed to prevent AI from doing all the work—proved irreconcilable.

Claude completing the Fall 2025 project at 32x speed

The key insight. If AI handles the translation from specification to code, the valuable human contribution is formulating the idea and specification itself. That realization drove the redesign.

My Project
My Project

Starting in Spring 2026, every student designs and builds something of their own, working with AI coding agents—specifically Claude Code—throughout the process. Students aren’t translating our specification into code—they’re creating their own specification and learning to communicate it effectively to an AI agent.

The preparatory pipeline. We don’t just hand students an AI tool and wish them luck. The project unfolds as a carefully scaffolded sequence of weekly discussion-section activities that carry students from “I have no idea what to build” to a shipped app:

The prototypes in weeks 4–6 are built in a browser as published claude.ai artifacts, so a classmate can open one from a link; from week 7 on, students work in their own repository with Claude Code. Each hour runs on the clock, with a projected display showing what everyone should be doing and the time left, and the activity page itself handles pairing, peer verification, and for some activities attendance. The workshops rotate among three formats: partner pairing, pair critique, and a status update followed by pairing up to share progress and decide what to do next. Students can build a web, Android, iOS, or native desktop app, and every project must be usable by another student, either through a link or by handing over a phone or a supervised laptop. Each activity builds on the previous one, so a student who missed a week has a named way back in rather than starting the next one empty-handed.

Time-on-Task Grading
Time-on-Task Grading

When every student builds a unique app, traditional autograding is impossible—there are no shared test suites to run. Manual rubric-based grading is infeasible at our scale and inevitably subjective for creative projects. Instead, we grade the project on measured effort from AI coding agent session activity.

The project repository carries Claude Code hooks that stream each session’s events to the course as they happen. Each prompt a student sends earns the time Claude spends working on it, the time it takes to read the reply and write the next prompt, and two minutes to think. Time away from the conversation does not count, and a permission dialog left open earns at most two minutes. The rule is calibrated against real sessions, and no language model is involved in the measurement.

Students earn full project credit by accumulating 24 measured hours between October 6 and December 10, a pace of about 3 hours per week, with a cap of 8 credited hours per week. Working with Claude Code during a Tuesday section counts like any other time; attendance by itself earns nothing. The weekly cap discourages cramming and encourages sustained engagement. Students see their hours update as they work, and can review every session and the minutes each turn earned. The grading criteria are completely transparent—invest the time, earn the credit.

Learning objectives for agentic development:

Integration with Classical Programming
Integration with Classical Programming

Agentic development doesn’t replace classical programming—it complements it. We weight proctored quizzes at 60% of the grade, taken without AI in a computer-based testing facility. Across 14 weekly quizzes, students complete 36 proctored programming challenges—far more proctored coding than most CS1 courses require. The project is 20% of the grade and is where students practice agentic development. This split lets us teach both classical programming and agentic development without one undermining the other. Computational thinking unites the two—whether students are writing code themselves or directing an agent, they need to decompose problems, think algorithmically, and reason about correctness.

For the full story, see Geoff’s presentation to CS 124 students at the end of the Fall 2025 semester, and a follow-up talk on using and teaching coding agents.

Lessons Taught by the Student’s Own Agent
Lessons Taught by the Student’s Own Agent

Working well with a coding agent is a skill, and by week 10 of Fall 2026 our students had told us clearly that practicing it on their own was not enough: asked in the mid-semester check-in what they most wanted, the top answer was guidance on prompting. The trouble is that the skill is about a year old and nobody knows how to teach it yet. So we tried something we have not seen elsewhere: a series of eight short lessons on working with an agent, each taught to the student by their own coding agent, inside their own project.

Where the principles came from. We asked the agent. In August, Geoff asked Claude what, from its side, makes a conversation with it go well, after using it daily for a year without ever asking. Its answer became the eight principles—discuss ideas, not implementations; correct it, out loud, early; say what you saw; never accept done without looking; and so on—and each became one lesson, taught in his voice from recorded talking points.

How a lesson runs. The lesson page carries the idea: a short definition and one before-and-after example. The practice happens in Claude Code. The student copies one sentence from the page and sends it to Claude in their project folder. Claude fetches a script written for that student—it quotes their own recent prompts, by name, and works on their own next change—and walks them through four steps. In the first lesson, the student sorts three of their own prompts into ideas and implementations, rewrites one, asks for a real change to their project at the level of ideas, and says what they noticed. Every step ends with something the student types in their own words, and the agent has a checklist for each step that it must see met before it moves on.

How we know it was done. No new instrumentation. Students already run Claude Code with course hooks that report their sessions, which is how project time is measured. The agent ends each completed step with a marker line, and the server reads those markers out of the same stream, in order, and only when the student’s own message in that turn was long enough to be an answer. A marker the student types themselves is ignored, and the script tells the agent so. Nothing depends on the agent behaving: it is told what to do, but the course verifies.

Nobody grades it by hand. When every step is recorded, a model screens the transcript against the same per-step checklists the agent used, holding the student to exactly that standard and nothing more, and credit is withheld with plain reasons when a step was not done. Because one model pass disagreeing with the agent must not cost a student a redo, a withhold needs two passes that agree, and a split is settled by a third. A student who is withheld redoes only the steps the screen said were not done; the rest are carried forward. Asking the agent to mark a step done, or to write the answer, gets refused, and the attempt is recorded for the academic integrity sweep, but a student who then does the work is credited. Each lesson counts as that day’s homework, and the time counts toward the project’s weekly hours, since it is spent in the project.

Tested on simulated students first. Before any real student saw a lesson, we ran it against a simulator: a real, headless Claude Code in a sealed container, on a clone of a real student’s repository, with a model playing the student in one of fourteen styles—diligent, terse, the one who echoes whatever the agent says, the one who begs for markers, the one who restarts mid-lesson—and a second model auditing whether the agent followed its script. That is where we learned that the agent lost a marker when it ran a tool after printing it, and that the screen was stricter than the agent, before launch. A staff tester found that the agent classified the student’s prompts before asking them to, so the student just agreed; the script was fixed and the simulator gained a student who echoes whatever the agent says, so that can never come back unnoticed. The first real day still taught us something: two students were withheld on a step they had already passed in an earlier attempt, which is why a redo now covers only the failed steps.

Why the agent, and not us. The agent already knows the student’s project and has their recent prompts in front of it, so the lesson is practiced on the real thing rather than an exercise. It is also the medium the skill is about: learning to work with an agent by working with one. And it scales to 2,000 students with no staff in the loop, which is the only way a lesson can run every week for the rest of the semester.

No Lectures
No Lectures

CS 124 doesn’t hold lectures. Instead, students work through daily interactive lessons that mix text, runnable code examples, interactive walkthroughs—more on those below—short videos, and practice problems. Students engage at their own pace, which matters a lot when you have a wide range of prior experience in the room—from students who’ve never written a line of code to those with years of experience.

An interactive lesson on Java functions

Daily engagement also achieves spaced repetition naturally. Rather than cramming before a midterm, students return to new material every day. Because students move at their own pace, they can slow down on topics they find confusing and spend more time with the material that challenges them. We’ve also built up explanations from multiple instructors, so if one explanation doesn’t click, there’s usually another that might.

Connecting Lesson Completion to Grades
Connecting Lesson Completion to Grades

A course without lectures has an obvious failure mode: students who skip the lessons. So the lessons’ interactive components are instrumented. Each video and walkthrough is divided into 8-second intervals, and an interval counts once it has actually played: rewatching adds nothing, and skipping ahead counts for nothing. Playback pauses when the player scrolls out of view, so a lesson left running in a background tab does not count either. An item counts as complete at 90%.

That allows us to give every student a report on how much of the lesson content they have reviewed, lesson by lesson, with one bar segment per video or walkthrough, colored from red (unwatched) to green (watched). Here is a sample, with made-up numbers modeled on a real student’s report:

You've reviewed only 17% of the lesson content.

Lesson completion is not graded, but it's difficult to learn without reviewing the material.

Lesson%Content Remaining
2026-09-15: Algorithms and Strings8%57:05
2026-09-14: Strings54%14:33
2026-09-11: Functions and Algorithms1%29:45
2026-09-10: Practice with Functions9%29:06
2026-09-09: More About Functions1%35:44
2026-09-08: Errors and Debugging16%37:09
2026-09-04: Functions35%31:33

We don’t grade completion. The data isn’t strong enough for that, although Craig Zilles and Matt West’s work on Bayesian grading suggests ways it could become part of a grade. But we put the report at the top of the grades page, directly below the student’s running total and above every graded section, so students scroll past it every time they check their progress.

Plenty of students still don’t do “the reading.” But a student who is struggling now has to confront the most likely reason why, and knows that we can see it too. That has simplified many of our conversations with struggling students: almost always, the problem with their approach to the course is right there in the report, and the students whose difficulties are not explained by it are the ones most deserving of our time.

Frequent Small Assessment
Frequent Small Assessment

CS 124 has no final exam, no midterm, and no high-stakes assessments. Instead, students complete a daily homework problem and take a weekly 50-minute proctored quiz in a dedicated computer-based testing facility. Each quiz is worth only about 5% of the grade. Everything is autograded with immediate feedback, and students get unlimited attempts on programming problems—until the deadline or quiz timer runs out.

We’ve found that frequent small assessment may be the single most important component of student success. Students study regularly, we catch struggles early and reach out when someone does poorly on a quiz, and the low stakes reduce anxiety. Frequent data points also enable learning-focused policies that would be impossible with high-stakes exams: dropping lowest scores, allowing quiz retakes where students return to questions from previous weeks, and catch-up grading where doing better on a later quiz raises earlier scores.

Counterintuitively, this is also more rigorous. In Fall 2017, students wrote code in a proctored setting exactly once—on a paper final exam. Now they complete multiple autograded programming challenges every week, totaling 15 hours of proctored assessment per semester versus 3–4 previously.

Since Fall 2026, each quiz also comes back with feedback. Students have asked for years to review their quizzes, and because questions are reused, they never leave the testing facility. Instead, once a quiz closes, a student’s grades page points them at the lesson sections worth another look, drawn from how their programming attempts went and which multiple-choice items they have not yet answered correctly. How that works is described under LLMs below.

For more on this approach, see Geoff’s talk on frequent assessment.

Interactive Walkthroughs
Interactive Walkthroughs

One of our more distinctive innovations is what we call interactive walkthroughs—recorded code editing sessions that students can replay and interact with. These aren’t videos. They’re actual editor replays: students see code being written character by character, can pause and edit the code themselves, and resume the walkthrough. It’s closer to watching someone code live, except you can rewind, speed up, and experiment along the way. You can see examples at learncs.online.

A student interacting with a walkthrough

An instructor recording a walkthrough

Solution-Generated Autograding
Solution-Generated Autograding

Frequent assessment creates a demand for problems. We needed a way to author them fast and accurately.

The insight behind our autograder, Questioner, is that when autograding, the solution is known. This is fundamentally different from software testing, where only the desired behavior is known. So instead of maintaining three sources of truth—a description, a solution, and tests—the author provides just a description and a reference solution, and Questioner generates and validates the testing strategy automatically using source code mutation.

A student solving a programming exercise

The old process took hours per problem with unknown accuracy. The new process produces several problems per hour with validated accuracy. We’ve authored over 700 problems since Fall 2020 across multiple question types—code writing, debugging, tracing, and conceptual questions. Questioner also evaluates code quality—not just “does it work?” but “is it good?”—giving students instant feedback on complexity, style, and efficiency.

Debugging Challenges From Real Student Code
Debugging Challenges From Real Student Code

The same mutation engine produces debugging challenges—erroneous examples, in the research literature—at a scale no instructor could write by hand. Students in CS 124 have submitted correct solutions to hundreds of problems. We collect those, clean them up, and confirm each still passes the problem’s tests. Then Questioner’s source mutation engine introduces one small bug into each: flipping a comparison, nudging a loop boundary, changing a literal, removing a statement. The result is a pool of over three million buggy programs across more than 440 problems in Java and Kotlin, each one a real student’s working code with one thing wrong.

Here is one, from a problem asking students to reverse a string:

String reverse(String input) {
char[] inputChars = input.toCharArray();
String output = "";
for (int i = inputChars.length - 1; i < 0; i--) {
output = output + inputChars[i];
}
return output;
}

The student’s original loop ran while i >= 0; the mutation flipped it, so the loop never runs.

The student’s job is to find and fix the bug without rewriting the code. They may change only as many lines as the mutation did—one line for over 90% of challenges, measured by a line-by-line edit distance—and the fix must pass the problem’s tests and lint checks. That constraint is the point: it forces students to read and understand someone else’s code, written in a style that is not their own, rather than replacing it with their own solution. It also exposes them to approaches they would not have taken.

On 20 days this semester, the daily homework includes a debugging challenge. Each challenge gives every student a different random starting point in the pool, and five fixes earn full credit for the day. Students get two skips per problem, for a program that they cannot make sense of. They also get two checks: a student who believes a challenge cannot be fixed under the constraints can ask us to re-run the original, unmutated submission against the current tests. If it no longer passes—because the tests have grown stricter since that student submitted it, for example—the instance is withdrawn for everyone and the student gets a new one without spending the check. Otherwise they are told the challenge can be solved, and keep working.

Tutoring at Scale
Tutoring at Scale

Our tutoring model is built around peer tutors—recent CS 124 graduates who took the course themselves. They remember what was hard, they know the material, and they’re motivated to help.

The core of the system is an online-first tutoring platform that provides immediate 1-on-1 support throughout the day. When a student has a question—at 9 AM or 9 PM—a tutor is usually available within minutes. No waiting for office hours, no standing in line.

Student-tutor online tutoring interaction flow

Staff are organized into tiers: volunteer assistants gaining experience, paid associate mentors, TAs, and head TAs. When a student struggles on a quiz, tutors proactively reach out to offer support. We’re not waiting for students to come to us.

LLMs Across the Platform
LLMs Across the Platform

Beyond the project, LLMs are woven throughout CS 124 to solve specific educational problems that arise when teaching 2,000+ students.

AI Teaching Assistant. Students need help outside office hours, and even with a large staff, 2,000+ students can’t all get 1-on-1 time whenever they need it. A chat assistant answers questions using course content while maintaining academic integrity guardrails—it won’t solve homework problems. It uses retrieval-augmented generation (RAG) to search transcribed lectures and walkthroughs, so answers stay grounded in what’s actually been taught rather than generic internet knowledge.

Automatic Transcription. Hundreds of hours of walkthrough recordings and videos need to be searchable and accessible. WhisperX runs locally to transcribe all audio with word-level timestamps, enabling both the search pipeline and student-facing transcripts and captions. This makes the entire content library accessible to students who prefer reading, need captions, or want to search for a specific topic across all recordings.

Semantic Search. With a large and growing content library, students and the AI assistant need to find relevant material quickly. Transcripts are chunked, embedded, and stored in a vector database for hybrid semantic and keyword search across all course content. A student asking “how do I use recursion with linked lists?” gets pointed to the right walkthrough segment, not just a keyword match. The same index is searchable directly from the site.

Course Content Over MCP. Students are already required to use a coding agent for the project, and were reaching for their own AI whether or not we pointed it at anything useful. Rather than compete with that, CS 124 publishes its content to the agent the student is already running over the Model Context Protocol. Each student connects with a single command and a personal key; their AI can then search lessons and walkthrough transcripts, read a full lesson, ask which lessons the next quiz draws on, and browse the practice problems by lesson or concept.

The design constraints are worth stating, because they are what make this defensible. An MCP tool description is advisory—a client model can ignore it—so nothing may depend on the student’s AI behaving. Every tool is read-only, exposes no grades or submissions, and is filtered by the same rules the website enforces: the student’s language, the release date of each lesson, and, for a homework problem’s solution walkthrough, its deadline or the student having solved it. No quiz questions are served at all. An agent holding the lessons writes better practice questions than the item bank would provide anyway, and questions a student has not already seen are better practice.

We think this is the more honest response to students using AI: the alternative is not that they use less of it, but that they use it against material we did not choose.

Quiz Feedback. Students have asked for years to review their quizzes, which we cannot offer because questions are reused and never leave the testing facility. Since Fall 2026, once a quiz closes, a student’s grades page shows a few concept-level pointers back into the lesson sections worth another look. Two sources feed it. For programming questions, a model receives the student’s attempts, the autograder output they saw for each, the reference solution, and a fixed menu of the lesson sections the quiz draws on, along with a short per-quiz note from the instructor about what students have covered so far. It is asked for up to four concept-level pointers, or none, each tied to a section from the menu. For multiple-choice questions, no model is involved: each item the student has not yet answered correctly maps to the section that teaches it, and the pointer clears once a retake scores the item. The map underneath both—which lesson section teaches which quiz question—is itself built by an AI pass over each lesson’s text and walkthrough transcripts, separately for Java and Kotlin, and stripped from the site at build time.

Several rules keep this defensible. A guard checks every model output before it is stored: it may name only sections from the menu, may contain no code, and may not mention the question’s name or anything from its text, and anything that fails is withheld rather than shown. Nothing is released before the quiz window has closed for everyone, nor within eight hours of the student’s own sitting ending, so nothing about a sitting can reach a student while a classmate may still be taking the quiz. Only official proctored sittings count, and staff never see feedback on their own accounts. Silence is a valid answer: in the first round, four in five sittings earned no pointer at all, and the page says so rather than inventing something to say. We read a sample of the first round’s output, with the attempts behind it, before releasing it, and every prompt and response is kept so any pointer can be traced back to what produced it.

Mid-Semester Check-In. Mid-semester feedback usually means a survey, and surveys at our scale return a few hundred short answers that are hard to act on. In Fall 2026 we replaced it with a short interview: each student has one conversation with an AI interviewer about how the course is going, and how it is going for them. The first half asks about the course: which Tuesday activity they liked most and least, whether the feedback after each quiz has helped, and what is hardest about working with a coding agent. The second half is about the student, grounded in a fact sheet computed from their own records—quiz scores, measured project hours, lesson progress, tutoring visits—rather than anything a model wrote, so the interviewer can say where they stand accurately and suggest one concrete next step. When a student’s account and their record disagree, as with a student who blames the multiple-choice questions but has watched few of the lesson videos those questions draw on, the interviewer says so once, gently, with the student’s own numbers. It does not advise on dropping the course; a student who raises it is given the deadline and pointed to the instructor. Each conversation ends with a structured summary, so answers to the course questions can be tallied across the class, and the transcripts are read only by the instructor. Completing it earns a small amount of extra credit. Over a hundred students finished it in the first day, and 461 by the time it closed four days later; the first tallies were in front of course staff by the next afternoon. Asked what is hardest about working with a coding agent, the most common answer was saying exactly what they want (31%), ahead of understanding what the agent wrote (20%) and keeping it on track (16%), and a quarter said nothing had been hard yet. What they most wanted was guidance on prompting (38%), well ahead of more practice (20%).

Pitch Practice Feedback. In Spring 2026, students preparing elevator pitches for their project ideas needed a way to practice without requiring staff time for every attempt. They recorded themselves, got an automatic transcription, and received encouraging feedback on clarity, delivery, and timing—letting them iterate before presenting to real people.

Submission Validation. Also in Spring 2026, hundreds of project plan submissions needed basic quality screening. An LLM validated that submitted plans were genuine implementation plans rather than placeholder text, providing instant feedback so students could fix issues immediately rather than waiting for manual review.

Where the Models Run. The AI endpoints used by the CS 124 courseware are provided by the University of Illinois and approved for use with student data. Transcription runs on our own servers. The coding agent students use for the project runs under their own accounts and is pointed at course content, not the other way around.

What Students Think About AI
What Students Think About AI

In week 9 of Fall 2026 we stopped building for an hour and asked students where they think computing is headed. Each student first talked with an AI interviewer about how computers and AI will have changed their life in ten years, and about what they would want from a phone that ran no apps at all, where you just say what you need. Then they talked it over with two classmates in turn, and finished with a shorter conversation with the interviewer about what came up and whether anything changed their mind. 851 students took part, and together they wrote about 400,000 words.

We read those conversations the same way we read the mid-semester interviews: a model coded each one with names removed, and every number below was counted in code from those codes. Nothing here quotes a student.

Leaning hopeful going in, leaning worried coming out. We placed each chat on a scale from very worried (−3) through evenly balanced (0) to very hopeful (+3). Most students weighed both sides, but going in they leaned hopeful: 62% were on the hopeful side of the scale and 33% on the worried side, and the class averaged +0.4. After the table conversations the class averaged −0.1: 42% ended more worried than they started, 23% more hopeful, and 28% where they began.

Worry spread more easily than hope. Because we know who sat with whom, we could ask how hope and worry moved between partners. At every distance from balanced, students who started on the hopeful side fell further than students the same distance on the worried side rose. Students whose partners leaned worried moved a little further toward worry, while hopeful partners went with no move toward hope. Partners also shared more of their worries than random pairs of students do, but hardly more of their hopes: two of the leading worries, jobs and privacy, are about everyone, while the leading hopes were about the student’s own life. The partner effects are small and suggestive, and some of the drift may come from the closing question itself, but the pattern matches a long line of research on negativity bias and how risk information spreads. Hope and Fear at the Table has the full analysis, its limits, and that research.

Practical hopes, practical worries. The most common hopes were getting more done (46%), everyday convenience (38%), and help learning (35%), often imagined as a patient tutor available at any hour. The most common worry, raised by nearly half of students (48%), was losing skills by depending on AI: that leaning on it would weaken their own problem-solving and judgment. Jobs came next (43%), especially whether entry-level work will still exist, followed by safety and misuse (34%) and privacy (33%). The same domains showed up on both sides: students wanted AI tutoring and feared it would hollow out their learning, and wanted routine work automated and feared being replaced. That students in a course built around working with a coding agent name dependence as their leading worry is worth taking seriously.

A note on measuring this. Our first pass coded sentiment with a smaller model and found the share of worried students roughly doubling after the table conversations. It didn’t hold up. In the closing chat many students (328) described a worry a classmate had raised, and the smaller model counted those as the student’s own. Recoding both chats with a larger model, told to set aside views a student only reports, cut the number ending worried from 273 to 179. Anyone using a model to summarize conversations in which students report each other’s views should check for the same thing. We also first sorted students into hopeful, mixed, and worried, which left two thirds of them “mixed” and hid which way they leaned; the scale above is the fix.

Student Outcomes
Student Outcomes

Most students who stay in CS 124 do well, and most of the grade comes from proctored work: through Fall 2025, quizzes taken without AI in the testing facility were 70% of it. These are the fall semesters since Fall 2018, when about 800 to 1,350 students took the course each fall:

FallEnrolledDroppedWA rangeA or BD or FDFW
201883812.2%1.1%80.5%92.2%4.7%5.1%
201977512.8%0.6%82.3%91.1%5.4%5.3%
20201,0727.1%4.9%79.3%92.1%4.7%9.0%
20211,3315.9%1.7%83.9%92.0%4.6%6.0%
20221,3577.2%1.8%82.7%92.5%3.9%5.3%
20231,24210.2%0.8%83.3%92.8%4.2%4.5%
20241,2668.2%1.5%81.8%91.4%4.7%5.8%
20251,0829.7%0.6%76.4%89.3%6.8%6.7%
20261,1788.2%

Enrolled counts students on the roster four weeks into the semester, after add/drop has settled and students who earned credit on the proficiency exam have moved on to the next course. Dropped is students who left before the drop deadline at the end of the eighth week, which leaves no mark on the transcript, and W is those who withdrew after it and received a W. The grade columns are shares of the students who received a letter grade, and DFW is D, F, and W grades as a share of everyone enrolled. The course was CS 125 through Fall 2020, and Fall 2020 was the first fall of the pandemic, which shows in its withdrawals. Fall 2026 is still in progress: its drops are final, since the deadline has passed, and its withdrawals and grades will follow at the end of the semester. Spring semesters of CS 124 are smaller (about 650–800 students) and run somewhat lower: 70–76% A range and 5–13% DFW.

Most CS 124 students are not CS majors. Split by major on the first day of classes, CS and CS+X students almost never drop, and almost all of them finish in the A range; nearly all of the dropping, and most of the D, F, and W grades, come from everyone else:

FallCSA rangeDFWCS+XA rangeDFWOtherDroppedA rangeDFW
202124592.6%1.2%21793.9%3.7%8698.6%78.4%7.9%
202219893.4%0.5%21193.7%3.3%94710.0%77.3%6.8%
202320294.0%3.5%20096.5%0.0%83814.7%76.7%5.8%
202416095.6%0.6%22195.0%0.5%88411.5%75.2%7.9%
202513687.3%4.4%16390.8%1.2%78013.2%70.7%8.2%

The counts are students enrolled at four weeks. CS and CS+X numbers have shrunk because more of those students now earn credit on the proficiency exam and move on before the census. CS students drop at 0.5% or less every fall, and CS+X students at 1.4% or less: CS 124 is required for their degrees.

Fall 2025 has the weakest grades in both tables, and we looked hard at why. Drops and withdrawals did not rise; the increase is in failing grades. The A range shrank in every group, CS majors included. It is not a sign that students are learning less: proctored quiz mastery is flat across all five years, at every percentile, and the median student still scores about 91%. Instead, the students failing are increasingly ones who stopped working: four in five of Fall 2025’s F grades earned essentially no project credit, and most had quiz scores that would have passed had they done the project. That is disengagement rather than AI-enabled shortcuts, which would show up the other way around, as strong project work alongside weak proctored quizzes.

Links and Resources
Links and Resources