Should You Still Learn to Code If AI Can Do It?

Every beginner is quietly asking the same thing in 2026: why learn to code when the AI model can write it? The fear is fair, the entry path really is narrower than it was. But the part of coding that got cheap was the typing, and the part that's left, knowing what to ask for and telling right from almost right, is worth more than it ever was.

The question shows up under almost every AI-and-jobs post now, usually near the bottom of the thread and usually phrased carefully, as if the person asking already suspects the answer and is a bit embarrassed to be asking anyway: is it still worth learning to code when the model can write it?

I want to take that seriously because most of the answers I've seen don't. Half of them say "of course, coding is about problem solving" and move on. The other half say "no, learn to be a plumber". Both skip the part the beginner actually wants to know: what to do on Monday.

So here's the honest version of the answer. Yes, it's worth it. But the thing being learned has changed and the way in is harder than it was three years ago. Both of those are true at the same time.

The fear is reasonable, so start there

Nobody should be told the entry path is fine. It isn't. The Stanford Digital Economy Lab has been tracking payroll data from ADP reaching back to late 2022 and in its August 2026 update employment of 22 to 25 year olds in the most AI-exposed occupations sits 19% below where it would be if it had kept pace with their less-exposed peers, while experienced workers in the same occupations show no comparable gap at all. SignalFire's 2025 talent report puts a face on it from the hiring side: new graduates were 7% of Big Tech hires, down 25% from 2023 and more than half from 2019, and at startups they were under 6%.

Those are the numbers behind the panic and they're not wrong. The bottom rung really did get thinner. And even I find myself wondering "is climbing still worth it and what does climbing even mean now?".

What got cheap was the typing

Here's the reframe that I think matters most. For a long time "learning to code" meant learning to produce code: syntax, library APIs, the exact shape of a for loop in three languages, the muscle memory to turn an idea in your head into a file that runs, and courses were built around that and so were interviews and it all made sense, because producing code was the bottleneck and the person who could do it was the scarce one.

That part is cheap now, and it got cheap fast. A model produces syntax faster than any human ever will, in any language, from a description in plain English. If learning to code means learning to type code then honestly yes, the fear is correct: that skill lost most of its market value in about three years.

But that was never the part that made a programmer good. It was the part that made a programmer possible. The valuable part was always the layer underneath: knowing what to ask for and knowing what a correct answer looks like before it shows up and knowing what to do when the thing that runs isn't the thing that was wanted. Typing was the tax paid to get to that layer. The tax got waived, the layer is still there.

Almost right is the whole problem

In the 2025 Stack Overflow developer survey 84% of respondents use or plan to use AI tools. Only about 33% trust the accuracy of what those tools produce and 46% actively distrust it, and the single most-cited frustration, at 66%, was "AI solutions that are almost right, but not quite". The second, at 45%, was "debugging AI-generated code is more time-consuming". And when asked what they do when they don't trust an AI answer, 75% said they ask a person.

Read those together and the shape of the job in 2026 falls out. The output is plausible by construction. A model is trained to produce text that looks like correct code and most of the time it's correct, and that's exactly what makes the remaining cases dangerous. A wrong answer that looks wrong costs nothing. A wrong answer that looks right costs a production incident, and the only defense against it is a person who can tell the difference.

The "METR study from July 2025" is the sharpest version of this I know. Sixteen experienced open-source developers worked through 246 real issues from their own repositories, each issue randomly assigned to be done with or without AI tools, and these were people who knew those codebases well, exactly the kind of developer the tools should have helped most. With AI they took 19% longer. Before the study they'd predicted a 24% speedup, and after living through the slowdown they still believed they'd been about 20% faster. (METR is careful to say this is one snapshot of one kind of developer on one kind of codebase and I'd take that caveat seriously, it's not a verdict on AI tools in general.)

But the perception gap is the part that matters for a beginner. Even people with years of judgment couldn't feel, from the inside, whether the tool was helping. Someone with no judgment at all has no chance of feeling it either.

So the skill that's left isn't producing code. It's the ability to look at code you didn't write, code that looks fine, and know whether it is.

The floor went up, and so did the ceiling

The usual framing is that AI "lowers the bar". I think that's half of it and the less interesting half.

It's true that the floor rose. Anyone can now get something running: a working page, a script that parses the CSV, a small app that does the thing. That used to take months of learning and now takes an afternoon of asking, and from the outside this looks like the skill being devalued, and for the floor-level version of the skill it is.

But the ceiling rose too, and by more. The person who understands the system can read the generated code and see that it holds the database connection open across the await or that it retries a call that wasn't safe to retry or that it's correct today and will be wrong the first time two users hit it at once, and that person can now direct far more output than they ever produced by hand, because their judgment got a lever attached to it. The SignalFire report is blunt about the result: the fallout hit new grads hardest and demand for experienced engineers is still rising. Same tools, opposite effect. The only difference between the two groups is understanding.

Which means the gap a beginner has to cross didn't disappear. It moved. It used to be the gap between "can't write code" and "can write code". Now it's the gap between "it works" and "I know why it works", and the market has stopped paying for the first half.

Vending machine or tutor

That leaves the practical question: how does someone cross that gap when the tool that helps them produce is the same tool that can stop them from learning?

Anthropic ran a small controlled trial on exactly this, published in January 2026. Fifty-two developers, mostly junior, with at least a year of Python. Two tasks using Trio, an async library none of them knew. Half could use an AI assistant and half couldn't, and afterwards everyone took a 14-question quiz on the concepts they'd just used with no AI allowed for anyone. The AI group averaged 50%. The hand-coding group averaged 67%. The widest gap was on the debugging questions. And the AI group finished only about two minutes faster, which didn't even reach statistical significance. Two minutes.

The part I'd underline isn't the average, it's who beat it. The people in the AI group who scored well used the assistant in one of three ways: they generated code and then asked follow-up questions until they understood it, or they asked for code and an explanation in the same prompt, or they only asked conceptual questions and fixed the errors themselves. The people who scored badly used it as a vending machine. Put the task in, take the code out, move on.

Microsoft Research found the same thing from a different angle in a 2025 survey of 319 knowledge workers: the more confidence someone had in the AI the less critical thinking they applied to its output, and the more confidence they had in their own skills the more they applied. Confidence in the tool and confidence in yourself pull in opposite directions and only one of them builds anything.

So the tutor-versus-vending-machine distinction isn't a slogan. It's the measured difference between people who came out of the same hour understanding the library and people who didn't. The model was the same and so was the task. What differed was whether the person made it explain itself.

If I had one piece of advice for someone starting now it's this: never accept code you can't explain. Not "never use the model" (the model is the best tutor most beginners will ever have access to and it's patient and it's available at 2am and it'll explain the same thing five different ways without sighing). But make it explain. Ask why it chose that structure. Ask what breaks if a line is removed, then remove the line and see.

The struggle isn't a cost paid to get the code, it's the thing that writes the lesson into your head, and skipping it means you got the code and nothing else.

"Okay, but the models keep getting better"

The obvious objection: if the model gets good enough, won't understanding stop mattering too? Why learn to judge output that's going to be right anyway?

Two things. First, "right anyway" isn't where the risk lives. As output quality goes up the wrong answers don't get easier to see, they get harder, because they're surrounded by more correct ones and they look the same. The 66% "almost right" number from the survey is a description of a good tool, not a bad one. A bad tool would be wrong in ways anyone could see and nobody would ship its output unread.

Second, and this is the part I keep coming back to, ownership doesn't transfer. When the generated code takes the payments service down at 3am nobody pages the model. Someone approved that diff and someone's name is on the commit and someone has to sit in the incident review and explain what the code was supposed to do, and none of those someones is the model, because the model isn't going to be on the call to say what it meant. That someone has to understand it. And every improvement in the model makes that understanding more valuable, not less, because it's now spread over more code.

That's the case for learning to code in 2026 and I don't think it needs dressing up. The entry path is narrower and it's going to stay narrower for a while. The way through isn't to produce faster than the model, nobody can. It's to go deeper than the people around you who are only producing. The model can write the code. Someone still has to own it, and that someone has to actually understand what they own.

Thanks for reading! English isn't my first language, so I use AI to polish the grammar. Everything else here - the ideas, the code, the opinions - is mine.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋