A friend of mine building an app this year told me something that stuck with me: he'd finished in a weekend what would've taken him a full semester two years ago. Then he added, almost sheepishly, that he wasn't sure he could explain half of what the code actually did. That's really the question hiding underneath “should I learn to code” — not whether AI can write it, but whether you'll understand what it wrote.
The data doesn't match the hype
Here's the thing nobody selling AI coding tools wants to dwell on: the tools mess up constantly, and they mess up in ways that look fine until they aren't. Stack Overflow's most recent developer survey put a number on the frustration — 66% of developers said AI regularly hands them something “almost right, but not quite,” and 45% said fixing AI-written code eats up more time than just writing it themselves would have. Google's 2025 DORA report found something even more uncomfortable for the “AI makes everyone faster” crowd: teams leaning harder on AI actually saw their code get less stable, not more.
Then there's the METR study, and this is the one that made a lot of experienced developers go quiet. Researchers timed how long open-source developers took to finish real coding tasks, with AI help and without. The developers were convinced the AI was speeding them up. It wasn't. They were actually slower — they just felt faster, which if you think about it is worse, because it means people are trusting a productivity gain that doesn't exist.
To be clear, none of this is an argument against using AI to code. It's an argument for knowing enough to catch it when it's wrong — because right now, it's wrong a lot, and most of us don't notice until it's already broken something.
What Indian recruiters are quietly checking for
This isn't just a developer-forum debate anymore — it's already showing up in how companies hire in India. TCS's HR chief said at a summit in March that 60% of the company's fresher hires this year had AI-related skills, up from barely 10-15% three years back. That sounds like validation for “just learn to prompt an AI,” except it isn't, because the same recruiters are also adding AI-readiness checks on top of the usual coding and aptitude rounds, not instead of them. Nobody's hiring people who can only operate a chatbot. They're hiring people who can still clear a data structures round and also know how to use AI without getting fooled by it.
That distinction matters more than it sounds like it should. A student who can prompt well but can't tell when the output is wrong is, from a hiring manager's point of view, basically a liability wearing a productivity badge. The freshers actually getting picked are the ones who can do both — use the tools, and catch them when they slip.
The part of programming that never got automated
Talk to anyone actually shipping software right now and a pattern comes up again and again: they write less code from scratch and spend way more time reading someone else's — except “someone else” is now an AI, and it doesn't explain itself, doesn't flag its own uncertainty, and definitely doesn't feel embarrassed when it's confidently wrong. Reviewing that well is a completely different skill from typing fast, and honestly, you can't really learn it unless you've written broken code yourself at some point and had to sit there figuring out why it broke.
That's the case for still learning to code the slow way, at least once. Not because AI can't write a for-loop — it can, easily — but because you need the scar tissue from writing your own buggy for-loop to recognize a subtle bug in someone else's. Or something's.
If I had to give an honest answer, it's that “learn to code” was never really about memorizing syntax, even before AI showed up — it was always about learning to think in steps and catch your own mistakes. AI hasn't killed that skill. It's just made it a lot easier to skip past without noticing, right up until the moment your code breaks in production and you're the one who has to explain why.