Teach the Fundamentals By Hand, Then Teach Them to Delegate

The framing goes up next, and for software, the framing gets cut in a classroom years before anyone calls it "engineering."

Right now, in most Bachelor's-level computer science programs, there is an unofficial second curriculum running alongside the official one. The official one says: no AI tools on assignments, no AI on projects, submit your own work. The unofficial one, running in nearly every student room and every library carrel, is a small arms race against Turnitin and its cousins — figuring out which paraphrasing pass fools the detector, which prompt produces something that doesn't trip the pattern-matcher, how much you have to manually rewrite before the percentage drops below the line someone drew in a faculty meeting. Ask any professor holding office hours honestly and they'll tell you: the students aren't avoiding AI. They're avoiding getting caught.

That's not a scandal. It's a market failure with a very obvious fix, and universities are just slow to apply it.

The ban makes sense exactly once

There is one place in the curriculum where "no AI, build it yourself" is not just defensible but correct: the introductory sequence. Principles of Programming 101, data structures, the course where you write your own linked list before you're allowed to import someone else's. That's where the actual wiring gets installed — the mental model of what a loop does, why a null pointer crashes a program, what recursion feels like from the inside. You cannot orchestrate what you don't understand, and you cannot understand it by watching an agent do it for you. Every professor who insists on this is right, and no post about AI in education should talk them out of it.

But that instinct, applied correctly to first-year students, is currently being applied — by policy, if not by name — to every year after it. By the third and fourth year, when students are building real systems and heading into a job market that has already moved on, the same "do it from scratch, unassisted" standard stops teaching the skill that actually matters next.

Prompting is a skill, not a shortcut

Writing a genuinely good prompt — one specific enough to get a useful answer, structured enough to be checked, and followed by a real challenge back to the model when the first answer is wrong — is closer to a technical skill than students, or their professors, currently treat it as. It is also, per the market this series keeps circling back to, exactly the skill that gets rewarded once "typing the code" stops being the bottleneck. A software engineer who can specify a problem precisely enough for an AI agent to execute it, then catch the two things it got subtly wrong, is doing the same job a good teaching assistant does when a confused student describes their bug badly and the TA has to figure out what they actually meant.

If the market needs orchestrators, someone has to teach orchestration. That someone is currently graded on how well they catch plagiarism.

Educators as orchestrators of learning

Here's the reframe worth trying: instead of policing whether AI was used, grade what the student did with it. That's a role change for the educator too — from gatekeeper of originality to something closer to an orchestrator of learning, the same shift the industry is asking of engineers.

Concretely, that could look like a Responsible AI use requirement running alongside the assignment: an AI journal, kept honestly, logging what was asked, what came back, what was wrong, and what the student changed and why. Grade the journal's judgment, not its existence. For upper-level project courses, assign some projects explicitly as vibe-coded — built with heavy AI assistance on purpose — and grade them the way a senior engineer's pull request gets reviewed: does it pass the test suite, does the student understand every line well enough to explain it in front of the class, did they catch what the model got wrong. That's a harder rubric to write than "run it through a detector," but it's the one that actually measures the skill the job market is buying.

And then there's the thesis

The Final Year Project sits awkwardly in all of this, because it was designed as proof of a specific thing — that a student can take a problem from open question to working system, alone, over months. If a large share of that build can now be delegated to an agent, the honest question isn't "did they cheat," it's "what is this artifact supposed to prove anymore." Maybe it's time the thesis measured the same things the industry is starting to reward: the quality of the problem framing, the design decisions, the orchestration of the build, the defense of choices under questioning — rather than treating "wrote every line unaided" as the whole point.

One carve-out matters here, and it's important enough to say plainly: none of this applies to genuine research theses and research-track projects — the ones aimed at pushing the field itself forward, including, not incidentally, the next generation of AI tools and models. That work still needs the slow, from-scratch, nobody-can-shortcut-this rigor it has always needed, even though — and there's something almost funny about this — a growing share of that research work is itself getting done with AI assistance. Research doesn't get a pass from this conversation. It's just a different conversation.

The framing's up. Somewhere in the next few posts: why companies keep hiring one AI-fluent senior instead of training three juniors, what's worth putting in front of a curious teenager long before any of this is a formal course, and a number a lot of finance departments would rather not say out loud — what a company spends on tokens and subscriptions next to what it used to spend on payroll.