How to learn CS in the AI era

Most CS students in 2026 are running a study plan written for a world that no longer exists. The plan was built around scarce information: a few good textbooks, a slow professor, problem sets you graded yourself by suffering. In that world, the bottleneck was access. The student who read CLRS cover-to-cover and ground 500 LeetCode problems pulled ahead, because almost nobody else did.

That bottleneck is gone. Information is not scarce anymore. Tutoring is not scarce. Working code examples are not scarce. What is scarce is taste, the habit of building, and the discipline to know what to learn deeply versus what to delegate. This curriculum is built around that shift. Before you start any of the technical modules, you need the frame.

The frame is simple. The student who wins is no longer the one who memorized the most. It is the one who can take a fuzzy question, read narrowly into the relevant material, build a small thing that proves they understood it, ship it somewhere public, and repeat — faster than the competition. AI is not the curriculum. AI is the multiplier on that loop.

The old playbook, audited

Here is what your professors, your seniors, and most of the YouTube CS-roadmap content are telling you to do. Some of it still works. Some of it is actively wasting your years.

The old advice	Verdict in 2026	What to do instead
Memorize syntax for one language	Half-true. You need fluency, not memorization.	Build one thing in it. Reread your own code three times.
Grind every chapter of CLRS	Wrong. You will forget 90% and never use the proofs.	Read CLRS narrowly — the chapter for the problem you have.
Watch a 10-hour tutorial before building	Wrong. Tutorials feel productive and aren’t.	Build first, watch the tutorial when you get stuck on a real bug.
Solve 500 LeetCode problems	Half-true. ~80 patterns matter. The other 420 are noise.	Solve the patterns, drilled to mastery. Not the count.
Avoid AI, “you won’t learn anything”	Wrong. You won’t learn the old way. You will learn faster the new way.	Use AI as a tutor, not an answer machine. (See 00.3.)
Read every paper in the field	Wrong. There are 200 papers a week.	Read the foundational ten, then read papers you have a use for.
”Just build projects”	Half-true. Projects without depth become toy clones.	Build projects that force you to learn the next concept up.

Read that table twice. The pattern is: the old advice was right when the bottleneck was access. The new advice is right when the bottleneck is attention.

What still works (and probably always will)

A handful of habits are timeless. They were true in 1985 and they are true now. Anyone who tells you AI made them obsolete is selling you something.

• Reasoning from first principles. When the abstraction breaks, the person who can drop down a layer wins. AI does not change that — if anything, it raises the premium on it, because everyone else is one layer of abstraction shallower than they used to be.
• Debugging. The act of forming a hypothesis, designing a test, observing reality, and updating your model of the system. This is the single most underrated skill in the whole field, and it does not get easier when you let a model auto-fix everything.
• Taste. Knowing why one design is better than another in a specific context. Taste comes from reading a lot of code and shipping a lot of code. Models do not have your taste.
• Building. The actual completion of an actual thing that an actual user can run. Nothing replaces it.

If a study habit doesn’t sharpen one of those four, be suspicious of it.

What’s new (and where most students are failing)

Three skills barely existed in the old playbook. They are now table stakes.

1. AI-as-tutor

Not AI-as-answer-machine. AI-as-tutor means: you state what you think you understand, the model corrects you, you try the problem yourself, you come back with a wrong attempt, the model tells you what’s specifically wrong, you try again. The full version of this is module 00.3 — but the meta-point is that most students are using AI to skip the learning, instead of to compress the time-to-learn. Those are opposite outcomes from the same tool.

2. AI-as-co-builder

Pair-programming with a model in your terminal or editor. You drive, it types. You review, it iterates. Cursor, Claude Code, Copilot, Aider — pick one and use it on real projects, not toy examples. The students who get good at this in 2026 will outpace the ones who don’t by roughly the same margin that students who got good at Google search outpaced students who didn’t in 2008.

3. Eval as a skill

This is the one almost nobody is teaching at the undergraduate level yet. Building with AI is half the job. The other half is measuring whether what you built works. Writing eval sets, computing accuracy on them, regressing on them when you change a prompt or a model — this is the new “writing tests.” Module 04.5 builds it directly. The instinct to ask “how would I measure this?” before “how would I build this?” is the new senior-engineer move.

The compounding loop

The single highest-leverage habit in this whole curriculum is this loop. Most students do one of the four steps. The ones who pull ahead do all four, on a tight cycle.

1. Read narrowly.    (One source. One topic. 30–60 min.)
2. Build small.      (One thing. One file. Run it.)
3. Publish narrow.   (One blog post / GitHub README / tweet thread.)
4. Iterate.          (Next loop, slightly harder.)

The compounding comes from three places. Reading narrowly forces you to actually finish the source instead of bouncing. Building small forces you to translate words into a thing that has to actually work. Publishing narrow forces you to be honest about whether you understood it — you cannot fake an explanation in public. Iterating means each loop is one rung up from the last, so a year of loops moves you a serious distance.

The wrong loop, which is what most students run, looks like: read broadly, build never, publish never, repeat. Broad reading without building is entertainment.

The opinionated take

You should be skeptical of any CS curriculum, mentor, or roadmap (including this one) that does not have a clear answer for: what do you do today, with the next 90 minutes? Frameworks and roadmaps without that next-step answer are vibes. The frame in this module is built around forcing the next 90 minutes to be productive every time.

If you have to pick one principle to take with you: build the smallest version, ship it somewhere narrow, then make it slightly better. That is the entire engine. AI just speeds up each turn of it.

Read these first

Four sources, in this order, then stop.

1. Karpathy — Software is changing (again). video · 30 min · the cleanest articulation of why the playbook changed.
2. Patrick McKenzie — Don’t Call Yourself A Programmer. post · 25 min · old, still right; the part about output and visibility is the part you need.
3. Julia Evans — How to be a better programmer by reading other people’s code. post · 15 min · the single best modern writer on the learning loop of being a working dev.
4. Andy Matuschak — Why books don’t work. post · 20 min · sharpest argument for why “just read more” is the wrong default.

You can find ten more recommendations on Twitter every week. Don’t. Read these four, then move on to module 00.2.

Today’s small assignment

Spend the next 90 minutes doing exactly this. Do not modify the steps.

1. Open your notebook. Write down the three things you currently believe make a “good CS student.” (Your honest answer, not the LinkedIn one.)
2. Read the table in The old playbook, audited again. For each row, write a one-line note: which habit am I actually doing? Which am I just performing?
3. Pick one tiny topic you want to understand by tomorrow. (Examples: how a Python dict resizes; what exactly a Git commit is; how await actually returns control.)
4. Run one full loop: read narrowly (one source, max 30 min), build small (one file, max 30 min), publish narrow (one tweet, one short README, or one paragraph in a notes repo).
5. Write three sentences in your notebook on what you learned. Not what you read — what you can now do or explain that you couldn’t 90 minutes ago.

If those three sentences are concrete, you have just run one loop. The whole curriculum is doing this loop, on bigger and bigger topics, over and over. Everything else is decoration.

Going deeper

When you have specific questions, in this order:

1. Cal Newport — Deep Work. book · the canonical case for attention as the scarce resource.
2. Hamming — You and Your Research. transcript · 45 min read · why working on the right problems matters more than working hard.
3. Teach Yourself Programming in Ten Years — Peter Norvig. post · 10 min · the antidote to “learn X in 30 days” content.
4. Simon Willison’s blog. link · the single best ongoing record of what’s actually possible with current tools.

Skip “AI will replace programmers” think pieces. They are the lowest-yield content on the internet right now.

Checkpoints

If any one wobbles, the corresponding section above is what to reread.

1. Name three pieces of old CS-student advice that are now wrong, and explain why for each.
2. What are the four timeless habits that the AI shift did not break?
3. Walk through the four steps of the compounding loop from memory.
4. What’s the difference between AI-as-tutor and AI-as-answer-machine? Which one are most students doing?
5. State the one principle you would take with you if you forgot every other detail of this module.

If you can answer all five from memory, you’ve earned 00.1. Next: 00.2 — Your dev environment, properly set up. You’re going to need a working environment before you do anything else, and most students get this wrong in ways that cost them weeks across a year.