A question I can't shake
As we all wait to find out just how far the AI bubble inflates before it settles, a question has been rattling around in my head: five years from now, will anyone coming out of a CS program actually know how to code? Will the next generation of self-taught developers understand prompts, but not the output those prompts generate?
The more I sit with it, the more I keep landing on the same answer. We are heading toward a world where the ability to read code and genuinely understand it is going to be more valuable than it has ever been. Not less.
I know that sounds backwards. The marketing says the opposite: the machines write the code now, so why would anyone pay a premium for a human who can? Stick with me. This is an opinion piece, and the opinion comes from two places where I personally got burned.
The question r/leetcode keeps asking
I browse Reddit more than I should, and one of the popular hangouts for new grads is r/leetcode. As students grind data structures and algorithms to prep for tech interviews, a certain post shows up like clockwork. At least once a month, some variation of:
"Why does any of this even matter when we have AI?"
And honestly? It's a fair question. These programmatic puzzles have never been a great reflection of what engineers actually do all day. Nobody is inverting binary trees between standups.
I got my first engineering job through a take-home project. A small console application that was itself sort of LeetCode-ish. It calculated age gaps between dates, with edge cases like leap years to trip you up. A trivial task, but it proved something real: that I could hold a small problem in my head, reason about its corners, and produce working code on my own. That was the signal the interviewer was buying.
Here's the problem: in 2026, any frontier model one-shots that take-home in about four seconds. The artifact can be faked, which means the artifact no longer proves anything. So can a take-home be trusted at all anymore?
I don't think it can, and I'm not just speculating. Platforms that screen technical candidates report that the share showing signs of AI assistance during assessments jumped from roughly 15% in mid-2025 to over 35% by early 2026. Notice how companies are responding. Not with better proctoring, but by rebuilding the interview itself: take-homes followed by live sessions where you defend every decision, conversational rounds, reading code out loud. Meta has even piloted interviews where AI is allowed on purpose, and candidates are graded on how well they direct it rather than whether they can code without it.
Every one of those formats is converging on the same thing, and it's exactly where the "why bother" crowd has it backwards. When producing the code stops being the signal, understanding the code becomes the signal. You can't prompt your way through a live conversation about why your own code works. The hard skills aren't becoming obsolete. They're becoming the only thing left that's verifiable.
Two times I overused AI
Let me be clear about where I'm standing: I use AI extensively in my professional career, every day, and I'm not giving it up. It is genuinely, sometimes shockingly, good at writing code. But it's not perfect, it has bitten me before, and there are two incidents I keep coming back to, two times I now believe I overused it.
1. The personal project I vibe-coded into a stranger's codebase
I was building a small personal project, and I went full vibe-code mode. I described the architecture, the services, the features, and then I mostly got out of the way. A lot of tokens later, I had a working app. Great!
Except when I actually looked at the codebase, I could hardly tell what any piece of it did.
The velocity had felt incredible while it lasted. But the moment problems showed up, the bill came due. I burned enormous amounts of time on questions like "wait, why is this even an issue?" and "is this actually the right fix, or just a fix?" Every bug became archaeology in a codebase I supposedly owned but had never really visited. And here's the part that surprised me: it made me worse at prompting. Because I had handed over all the context, I didn't have the understanding I needed to steer the AI toward the output I actually wanted. The tool got less useful precisely because I had leaned on it too hard.
When I added it all up, the time I spent reading the output after the fact, reverse-engineering my own project, was barely less than what it would have cost to just build more of it myself, more slowly, with my brain switched on.
It turns out I wasn't alone in mismeasuring myself. In mid-2025, METR ran a randomized controlled trial with experienced open-source developers working on real tasks in codebases they knew well. With AI tools, they finished 19% slower. And even after living through the slowdown, they still believed the AI had made them about 20% faster. (METR has since noted that tools have improved and the specific number shouldn't be read as current, but the perception gap is the durable finding. The feeling of speed and the fact of speed are separate measurements, and it's our internal instrument that's broken.)
Since this was a personal project, there were no repercussions. No users were affected. But it was an eye-opening moment, and the thought that arrived with it was not flattering: oh no, this is how the slop gets made. Not by AI writing bad code. The AI wrote pretty good code. The slop comes from a developer surrendering ownership. I handed the wheel over completely, and I ended up with an inferior project, not because my tools failed me, but because nobody was actually driving.
And the industry-wide data suggests plenty of us are making the same trade. GitClear analyzed over 200 million lines of changed code and found that duplicated code blocks grew roughly eightfold during 2024, while refactoring (the work of understanding existing code well enough to reshape it) collapsed from about 25% of changed lines in 2021 to under 10%. Their 2026 follow-up names the result a "maintainability gap." From the inside, I can tell you what it feels like: a codebase growing faster than anyone's understanding of it.
2. The performance win that quietly torched our SEO
At work, we were looking for ways to squeeze more performance out of our React app. We let an AI agent scan broadly across the site hunting for inefficiencies, and it came back with a solid list. One finding involved a component wrapping an iframe from a third-party vendor script. The agent flagged it for re-render issues and proposed a perfectly reasonable-sounding fix: lazy load it, since it usually sits below the fold.
What the agent missed was that this component did double duty. It also injected JSON-LD structured data, the schema markup that feeds our SEO.
The agent returned a large bundle of changes, and (here's the honest part) we'd been having great success with AI in exactly this area, so our review had gotten comfortable. We shipped it. The next day, our SEO team reported the schema had vanished, and we scrambled to revert before it did real damage to our rankings.
Notice what actually happened there, because it's subtle: the AI did exactly what we asked. We said "find performance improvements," and it found one. A real one! What it couldn't do was weigh a cost that lived entirely outside the question we posed. It had no idea that schema markup mattered to a team it had never heard of, serving a goal nobody put in the prompt. That cross-cutting context, the stuff that connects a component to the business reasons it exists, is precisely the thing a human reviewer is for. We had let the AI take ownership of the problem, and ownership is the one thing it cannot actually hold.
If my schema story sounds like a one-off, security researchers have measured the same failure shape at scale. Veracode ran more than 100 LLMs through curated coding tasks and found they introduced a security vulnerability in about 45% of them. Code that worked, but was also wrong in a dimension nobody put in the prompt. That's not really a security statistic. It's a context statistic.
The comprehension gap
Neither of these stories is a "we deleted the production database" disaster, and that's exactly why I think they're worth telling. The scary failure mode of AI-assisted development isn't the dramatic explosion. It's the slow leak: teams shipping more and more code that fewer and fewer people genuinely understand.
The people closest to the work can already feel this. In Stack Overflow's 2025 developer survey, 84% of developers said they use or plan to use AI tools. In the very same survey, more developers actively distrusted the accuracy of those tools (46%) than trusted it (33%). The single most-cited frustration, at 66%? AI solutions that are almost right, but not quite. Nearly half said debugging AI-generated code takes more time than it saves. And it's not just individual grumbling: Google's 2025 DORA report found that AI adoption now correlates with higher delivery throughput and with lower delivery stability, with the time saved generating code quietly being re-spent verifying it. Sit with that combination for a second. Near-universal adoption of a tool most of its users don't trust. There's only one way to square those numbers: someone, somewhere, has to be able to check the output.
Here's the economic argument underneath my whole opinion: writing code was never actually the hard part of this job. The hard parts were always deciding what to write and knowing whether what got written is right. AI has collapsed the cost of the first thing to nearly zero, and in doing so it has put a massive premium on the second. When generation is free, verification is the bottleneck. And you cannot verify what you cannot read.
Calculators didn't make numeracy worthless. They made the person who blindly trusts whatever the display says genuinely dangerous. Same shape here: the developer who can only prompt, and can't read the output, isn't 10x. They're a liability with great throughput.
Reading code has always been the undervalued half of the craft. We celebrate writing it, we tolerate reviewing it. I think that ratio is about to invert. In a world where most code is generated, reading it critically is the job.
So what should you do, if you're just starting out?
If you're getting into this field right now: absolutely use AI in your learning process. It's the most patient tutor that has ever existed. Ask it why, not just what. Make it explain the code it gives you, line by line, until you could have written it yourself. Have it quiz you. Use it the way you'd use a great senior engineer who never gets tired of your questions.
But sometimes, deliberately, on purpose, do things the hard way. Write the function yourself first, badly, before you ask for the good version. Sit with the bug for twenty minutes before you paste it into a chat window. The struggle isn't an inefficiency to be optimized away; the struggle is where the skill actually forms. There is no shortcut to the version of you who can look at a diff and feel that something is off.
Who are they going to call?
I'll end where the draft of this piece started in my head. As AI gets very, very good at producing code, I genuinely fear a future where fewer engineers know what's happening inside their own codebases. But follow that fear one step further and it turns into something like optimism: scarcity creates value. If understanding code becomes rare, understanding code becomes precious.
So to my fellow tech workers: I don't believe your job is in danger, no matter what the marketing decks say. I think you're about to become more valuable than ever, if you keep the reading muscle strong. The industry is busy generating an ocean of code at unprecedented speed, and some meaningful fraction of it is wrong in ways no prompt will ever surface. Developers already know it, too: when Stack Overflow asked what would still send them to a human being in an AI-saturated future, the number-one answer, from 75% of them, was "when I don't trust AI's answers."
When that output breaks, and nobody left in the building understands it, who are they going to call?
Make sure the answer is you.