On AI usage in CS classes

I can't argue against existing policies and regulations concerning AI usage in CS classes. But if I am to design the curriculum of any CS class (data structures, for example, since I'm so extensively involved in this class), I would make the use of AI a front and central topic of the entire class. The more introductory a class is, the more AI should be encouraged and promoted.

Background

I am primarily focusing on the following types of AI usage:

• LLM-based code generation. You type in prompts in natural language and the AI generates entire snippets of code. Common tools include ChatGPT and Gemini.
• AI-based code completion. You type in code and the AI suggests continuations. Common tools include TabNine and GitHub Copilot (specifically its completion aspect).
• AI agent editors. AI automatically performs complex tasks beyond generating code, such as refactoring, debugging, and testing. Common tools include Cursor.

Based on extensive conversations, personal experience, and observations, I think students typically use AI for the following purposes:

• Translating problem statements into starter code; getting unstuck when they do not know how to begin.
• Filling in boilerplate and repetitive structures.
• Debugging compiler errors and runtime exceptions.
• Generating test cases.
• Refactoring for clarity or style.
• Understanding unfamiliar syntax or APIs.

They reveal what students find cognitively expensive, where instruction is unclear, and where they find their time least meaningfully spent.

What AI brings

As much as I'm reluctant to admit, the purpose of CS education is, largely, to prepare students for software development careers, so what we teach should be aligned with the skills that they need. I like comparing rejecting AI to people who rejected IDEs, code completion, and syntax highlighting 20 years ago, but I also think it's a completely different paradigm shift. The former is fundamentally shifting the way we interact with code. It's time to train our students to be proficient in this new paradigm, rather than teaching the new dog old tricks. As I've said:

If students need to be "forced" into learning something by taking existing tools away from them, it's time to reconsider if said thing is worth learning at all.

Most people—myself included—are terrible at beginning some task. I used to have this terrible habit, where I (as team lead) would ask someone to write a piece of code or writing, read it, and then write my own version without even copying theirs over. Building this mental scaffolding (or physical even, doesn't matter) significantly reduces this activation barrier and helps students see the full picture at a distance.

It transforms a "code-writing" task into a "code-reading" task. In my (unpopular) opinion, reading code is a more fundamental skill than writing code. (At least, people say that "code is read more than it is written".) It is also more transferable across languages and paradigms. By seeing the code that AI generates, students can learn new syntax and idioms that they might not have encountered before.

Let's take the scenario to its extreme and say the student blindly accepts the AI-generated code without even looking at it. How often this happens aside, I don't think it's a problem. Coding in 2025 is increasingly shifting towards "prompting" rather than "coding". If the student can then make all tests pass, fix style issues, and refactor for clarity, they have learned much more practical skills than if they had written the code from scratch (probably without a good understanding of what "good code" should look like in the first place).

What we have done wrong

The data structures class I'm involved in has strict policies against AI usage installed and enforced. Students accused of AI usage are penalized the same way plagiarism is. I think this is problematic for a multitude of reasons.

• We are policing tools instead of measuring understanding. We assume that writing every line manually is the only path to comprehension. That assumption is unexamined. Conceptual understanding and algorithmic thinking can be developed independently of the mechanics of writing code, just like literature seminars do not require students to write their own novels by hand.
• We have assumed the wrong set of skills to begin with. In real life, the difficulty of programming does not come from remembering specific syntax or structuring the algorithm; it comes from understanding the business problem, choosing the right solution, and adapting to changing requirements. None of these skills is necessarily hindered by using AI to generate code.
• Enforcement is brittle and adversarial. Students' morale is tanked by the fear of being accused of AI usage. It creates an environment of mistrust and anxiety, which is not conducive to learning. I had received numerous messages from worried students asking if their code is "suspicious" of AI; I think that completely shifts the attention to the wrong place.

I don't know how much of the policy is driven by FUD and how much is driven by genuine pedagogical concerns. But I think it's clear that the current approach is not working and is doing more harm than good. I have discussed this with many people in the same trench, and while I don't have a solid proposal of what it should look like, I at least have a few directions in mind:

• Focus on design and concepts: instead of hand-implementing each data structure and algorithm, learn how to select the right one for a given problem, understand their trade-offs, and design your own solutions when necessary. This is more in line with the actual challenges developers face in the industry. For example, we can give students intractably big projects and ask them to design the architecture and high-level components, and then use AI to fill in the details. For this reason, when I host my lab sections, I highly emphasize the engineering pros and cons of each data structure, which is rarely covered in lectures.
• Focus on analysis instead of synthesis: with the latter becoming the job of AI, we should focus on teaching students how to read, understand, and critique code. After all, code review is a part of every developer's job, and when your real job also involves talking to an agent, this skill directly translates to real-life scenarios.
• Focus on testing, debugging, and refactoring: yes, the coding can be done by AI, but the responsibility of ensuring that the code works correctly, is efficient, and is maintainable still falls on the human. Currently, the tests are part of the assessment and are seen as a goal rather than a process. We should migrate to TDD and make the goal to write good, comprehensive tests and use them to drive the development process.
• Focus on in-person skills: when the banal parts of coding are handled by AI, what remains to be done by humans are the interpersonal and collaborative aspects of software development. Learn how to work in teams, review each other's work and provide feedback, listen to users' evolving needs, turn business language into technical requirements, and communicate your design decisions effectively. These are touched upon in the current curriculum, but they should be far more underscored.

Of course, a lot of these directions would completely upend the current curriculum and require a lot of work to implement because they place a lot of responsibility on the instructors to design meaningful projects and assessment criteria. But I think it's worth it in the long run. When the dark cloud of AI replacing human programmers is looming, humans shouldn't try to compete with AI on its own turf; instead, transform ourselves to be the kind that complements AI. This starts with education.