Computer Science & Data: How AI can best tutor this subject

What you'll be able to do: Use the one subject where AI can write the answer, without letting that remove the thing you came to learn.

The subject with the hardest version of the problem

Every subject has a version of "the tool can do the work for you". In computing it's acute, because the tool can do the work well, instantly, and the output is checkable: so there's no immediate signal that anything went wrong.

A student can complete an entire course with working submissions and no ability to write code. The submissions were fine. That's what makes this subject different: in history, generated work is detectable and often wrong; here it runs.

So the question isn't whether AI can help, it obviously can. It's how to use it such that you end up able to do the thing.

The asymmetry that should govern everything

Verification is free here and nowhere else. You can run it. That's the subject's unique advantage and it should shape every use.

It also creates the subject's characteristic blind spot: because checking is cheap, students do the cheapest check (does it run) and stop. That catches syntax errors and crashes, which are the errors that don't matter, because they announce themselves.

The errors that matter are the ones that run.

And a warning that belongs to the whole corpus: if your intuitions about trusting AI were formed while programming, they do not transfer. "It's fine, I check it" is true here and much less true in medicine, law, or history.

What it is genuinely good at here

Being the thing you predict against. Predict the output, then run. Free, instant, unlimited, and it catches wrong models of state, which is the actual difficulty behind most beginner confusion and is invisible in source code.

Code review. The feedback courses never give: is this comprehensible, will it survive being changed, does it fail safely, will you understand it in six months? Ask for comments marked must-fix / should-fix / preference, because novices can't tell those apart and otherwise apply style rules as though they were correctness rules.

Edge-case generation. "What inputs would break this, empty, null, huge, negative, unicode, concurrent, malformed?" Listing them without fixing them is the useful form.

Explaining unfamiliar code you've already read. After you've predicted what it does and been wrong, aimed at the gap.

Completion problems. Give me this with the beginning removed, the structure and the return, and I write the middle. That's the missing rung between reading solutions and facing a blank file.

Being a difficult student. Teach it something and let it ask the questions a beginner asks.

What it is bad at here, specifically

Your codebase. It doesn't know why module four is strange, what the team decided in March, or which abstraction you're migrating away from. Generic advice applied to a specific system is how over-engineering enters student projects.

Version and library currency. Confidently correct for a version you're not running. Frequent, and not always loud.

Security. Plausible code with string-concatenated SQL, unvalidated input, a secret in the source. It runs perfectly.

Knowing when the answer is "don't use a computer for this". It will always produce a technical solution.

Debugging as a skill. It can find your bug. That's the problem, debugging is a procedure built by running it, and every bug it fixes for you is a bug you didn't learn from. Worse, debugging is where you discover how the system actually works as opposed to how you assumed it worked. A fix updates the code; finding it yourself updates your model.

The shape of a good session

1. Never press run without predicting the output and why.
2. When stuck, climb the ladder rather than pasting the trace. The rung to live on is "what should I print, and what would each result tell me?", it teaches the real skill while giving away nothing about your bug.
3. When it works, review it with the context stated and comments graded.
4. Weekly, log bugs by concept: not by symptom, plus how you found each one. That second field is the only systematic feedback on your own debugging procedure you'll ever get.
5. Regularly, build from a blank file with nothing open, and afterwards ask what you routed around. You avoid what you can't do, the code still works, and the gaps are silent.

The instruction to set

For this session you are tutoring me in programming. Rules, never give me corrected code and never tell me where a bug is; ask what I expected, what happened, what the smallest failing case is, and what changed, before helping; when I'm stuck, give me the smallest hint that lets me narrow it myself; before I run anything, ask me to predict the output. If I ask for a fix, remind me of these rules.

The failure that looks like success

Tutorial hell. Every step made sense, the code worked, you understood each line, and you finish feeling competent. Then you open an empty file and cannot begin.

The mechanism: following someone else's decisions requires none of the work of making your own. The tutorial made every hard choice, what to build, how to structure it, what to name things, what to do first, and gave you the consequences to type.

Comprehension of a solution and production of one are close to unrelated. More tutorials widen the feeling of competence and leave the gap where it was, and AI is a tutorial generator of unlimited patience.

The tell: you've completed many courses and have never built anything nobody told you to build.

What it cannot replace

Sitting with not knowing. Which in this subject means: the hour where the thing doesn't work and you don't know why, and you narrow it down.

That hour is where programmers are made. It's also the hour AI can end in nine seconds, on request, invisibly.

Where to go next

01 Predict-then-verify is the highest value-per-second habit in the subject. 04 Contingent hinting for debugging and 06 Output pushing and the blank file are the two that protect what you came for.