What Should We Teach Engineers When AI Does the Code Writing?

I once spent an entire afternoon looking for a missing semicolon.

The code wouldn't run. The error message pointed at a line that was fine. I read the same forty lines over and over, and then I started reading Stack Overflow, which for years was how most of us learned anything: a public forum where programmers post problems and strangers answer them, sometimes correctly. I read a dozen threads from people with a similar error and a completely different cause. Then I found it. One character, one line above where I'd been looking the whole time.

Nobody has that afternoon anymore. The AI catches the semicolon before you ever see the error.

I wrote last time about engineering-backed vibe coding, and about the fact that catching a bad result takes having been burned before by the exact category of mistake the AI just made. Which leaves an obvious problem sitting there. That whole argument rests on fifteen years of me being wrong about things. Someone starting today has none of that, and the tools have removed most of the ways they would have gotten it.

So the question I keep coming back to is what a person starting now should actually learn, when the part that used to take four years to get good at can be done by a tool in an afternoon.

Nobody starts at the end

My answer is probably the least fashionable one available: they should still learn to write code by hand.

A surgeon who operates robotically didn't start on the robot. They learned every part of the body, and they cut, and they closed, and they did it with their hands for years before they ever sat at a console. Writers study how a sentence is built before they break one on purpose. In every field I can think of, you learn what's happening underneath before you're allowed to work only through the interface.

I don't think software gets an exception. If you've never written the thing yourself, you have no way to evaluate what comes back. You'll accept output because it looks plausible, and plausible is precisely what these tools are best at producing.

What changes isn't whether you learn the fundamentals. It's what you learn on top of them.

Because there's now a second discipline sitting alongside the first. How to structure a prompt so the result is worth reviewing. Where these tools consistently fall short. How to set up an environment, plan and spec a build before generating anything, and then test and QA what comes out. Those are the new teachables.

The thing experience actually gave me

If I had to name one of the most valuable things my experience handed me, it isn't syntax and it isn't any framework I learned.

It's a reflex for edge cases.

I look at a feature and I assume the happy path works. Then some part of my brain immediately starts playing devil's advocate, trying to break it. What if the file is empty. What if they hit submit twice. What if this runs at the same time as that. What if the service we depend on is down for eleven seconds. That reflex runs before I write anything, and it comes from having been on the wrong side of every one of those questions at some point.

You can ask an AI to generate a list of likely edge cases, and you should. It's a good list. But I have lost count of the times I've raised something it never considered, or watched a bug show up in a category it had no reason to think about, because it doesn't know what this system is for, who uses it, or what happened last time.

That reflex is the thing I don't know how to teach quickly. It came from breaking things and paying for it.

Yes, I would hire a junior today

People keep asking whether entry-level engineering is finished. I'd hire a junior developer right now, and I'd hire them because of the system, not in spite of it.

I've built an end to end process for how development and testing happen here. A new engineer doesn't need fifteen years of scar tissue on day one, they can benefit from mine. Instead they need to work inside a structure where the failures are visible and survivable: guardrails that confirm the process is being followed, alerts and dashboards that surface a failing test or a dead service before it becomes a real problem.

That's my actual answer to the question underneath all of this. If a junior can't build a pattern library the way I built mine, through hours of searching for a semicolon, then the environment has to do some of that work. Make the mistakes visible fast. Let them happen where they're cheap. The learning still comes from being wrong, so the job is to make being wrong survivable and obvious, over and over, until the reflex forms.

That is a training model. We used to call it the first two years of the job, and it happened by accident. Now it has to be designed.

Do we need computer science less or more

More. Different, but more.

If the production of code is increasingly automated, four years spent primarily producing code is a poor trade. What doesn't get cheaper is everything the code sits inside: systems, architecture, debugging, security, statistics, evaluation, information theory, how humans actually use the thing you built, and how to reason about something too large to hold in your head all at once.

Those were always the interesting parts. They were just gated behind years of learning to type correctly first.

And I'd add the thing my generation never had to be taught, because it didn't exist: how to work with a system that produces confident, well-formed, occasionally wrong work, and how to tell the difference at speed. That's a skill. It should be examined like one.

What I want them to keep

I don't want anyone to lose an afternoon to a semicolon. It was a terrible use of a day, and I'd hand that time back if I could.

But I don't want them to skip what the afternoon was actually for. I came out of it knowing the machine wasn't lying to me. I'd just been reading it wrong.

The tools are much better now, and much more willing to sound certain about something they've gotten wrong. Which means the next generation needs that same suspicion, arrived at a different way.

They should still have the afternoon. It just won't be about a semicolon.

Part of a series about what AI changes beyond productivity.