Back to Blog
developer-educationai-toolscareer-developmentcode-quality

What AI-Generated Code Is Quietly Costing Developers Who Can't Evaluate It

March 31, 20268 min readBy Bruce Canedy

You're probably already using AI to write code. If you're not, most of the developers around you are.

GitHub reports that AI now contributes roughly 46% of the code written by active Copilot users. Over 15 million developers use the tool. 90% of Fortune 100 companies have deployed it. The adoption numbers aren't a future projection — they're the current state of the industry.

Here's the part nobody's talking about loudly enough: there's a growing gap between developers who can generate code with AI and developers who actually understand what that code does. And that gap isn't just an academic problem. It has a real cost. A career cost. An incident cost. A professional credibility cost.

Scenario 1: The 2am Incident

It's a Tuesday night. Your microservice starts throwing errors. On-call gets paged. You pull up the logs.

The service was built three months ago, mostly with Copilot. It went through code review — the logic looked reasonable, the tests passed. You shipped it and moved on.

Now it's failing, and nobody on the team can tell you why. The error is in a retry loop that wasn't in the original spec. You don't know why the retry loop is there. You don't know what it's retrying against, or what the intended failure behavior was, or whether removing it will make things worse. The AI wrote it, it passed review, and now you're staring at it at 2am trying to reverse-engineer the intent from the implementation.

This is not a hypothetical. It is the operational reality of AI-assisted development at scale.

GitClear analyzed 211 million changed lines of code between 2020 and 2024 and found that code churn — new code that gets revised within two weeks of being committed — nearly doubled, rising from 3.1% to 5.7% over four years. Code clones grew eightfold compared to historical baselines. These are the signatures of code being written faster than it's being understood: premature commits, duplicated logic, churn on code that wasn't well understood when it shipped.

Debugging code you wrote yourself is hard enough. Debugging code you prompted into existence and rubber-stamped is qualitatively different, because you cannot reason backward from the implementation to the intent. You can only stare at it and guess.

The 2am incident is where that gap becomes expensive. Not in theory. In minutes spent, in services down, in engineers who don't know which part of the system to trust.

Scenario 2: The Security Review You Can't Defend

Your team is three weeks out from a launch. Security does a code review.

They find a vulnerability in the authentication flow. It was generated by AI, accepted in PR, and it's been sitting in your codebase for six weeks. The reviewer wants to know why the input wasn't sanitized. You don't have a good answer, because you didn't write that line — and more importantly, you didn't understand it well enough to catch the problem when you reviewed it.

This is also not a hypothetical.

Veracode's 2025 GenAI Code Security Report found that AI-generated code contains 2.74x more security vulnerabilities than human-written code. A separate analysis from Apiiro tracked a 10x spike in new security findings per month in repositories that heavily adopted AI coding assistants — that's not 10% more, that is an order of magnitude more. Cross-site scripting vulnerabilities appear in AI-generated web code at alarming rates; in some studies, models fail to generate secure code for this class of vulnerability over 85% of the time.

The vulnerability itself is fixable. What's harder to fix is the credibility problem in the room when you can't explain why it happened. When a security reviewer asks you to walk through the implementation decision and you can't, because you didn't make an implementation decision — you prompted one — that is a professional exposure that compounds over time.

There's a version of this that ends with "we patched it, no big deal." There's another version that ends with the incident becoming part of your track record. The difference, often, is whether the person who shipped the code could explain it well enough to own the failure and fix it convincingly.

The developers who can evaluate AI-generated code will have the first conversation. The developers who can't will have the second.

Scenario 3: The Senior Review That Doesn't Go Your Way

You're six months into a role. Your tech lead does a PR review.

The code works. The tests pass. But the senior engineer on the team starts asking questions. Why did you use this approach for the retry logic? What happens to in-flight requests if this service restarts mid-operation? How does this interact with the rate limiter downstream?

You don't have answers. The AI chose the approach, and you didn't dig into it deeply enough to know why. You figured if it worked and the tests passed, it was probably fine.

The review doesn't go badly — the code ships. But the questions stay with your lead. Over the next month, there are more of these reviews. More questions you can't fully answer. A pattern forms.

Research published in Science in 2025 found something worth sitting with: AI assistance was associated with measurable productivity gains for senior developers, but early-career developers showed no statistically significant benefit — and in some dimensions, the gap between junior and senior developers widened with AI adoption. The senior developer who can evaluate AI output becomes more productive. The junior developer who can't evaluate it doesn't improve — they just ship more code they don't understand.

That dynamic plays out in performance reviews. It plays out in who gets promoted and who doesn't. It plays out in which developers a tech lead trusts with the gnarly work.

The ability to explain your code — not just produce it — is still the unit of professional credibility. "The AI wrote it" is not a substitute for understanding it.

What This Means for Your Career

Here's the uncomfortable version of where this leads.

The METR study on AI and experienced open-source developer productivity found something counterintuitive: developers who used AI tools took 19% longer to complete issues than those who didn't — despite expecting AI to speed them up by 24%. Even after completing the work and experiencing the slowdown firsthand, they still believed AI had made them faster.

That gap between perceived and actual performance is worth taking seriously. If you believe AI is making you more productive when it isn't — when it's actually creating code you don't fully understand and incidents you can't fully diagnose — you're building confidence on a foundation that hasn't been tested.

The developers who are genuinely more effective with AI are the ones who already understood systems before AI arrived. They can evaluate what the AI produces. They can catch the retry loop that doesn't make sense. They can spot the input handling that looks fine until someone tries to exploit it. They have the mental model that lets them say "this is wrong" rather than "this passed tests."

If you're earlier in your career, or if you've been leaning on AI long enough that you haven't been building that mental model alongside it, the gap is real. It doesn't show up on Tuesday when you're generating a working microservice. It shows up on that Wednesday at 2am, or in that security review, or in that PR conversation with someone who wants to know why you made the choices you made.

Career costs are often invisible until they're not. A developer who spends two years shipping AI-generated code they can't fully explain is not in the same position as a developer who spent two years actually understanding the systems they were building on. Both have the same output metric. Only one has the underlying capability.

The Gap Is Getting Wider, Not Narrower

The honest thing to say here is that this problem is not going away. It is accelerating.

More AI-generated code is being shipped than ever before. The velocity is real and it's not reversible. The question isn't whether to use AI tools — it is whether you are building the capability to evaluate what those tools produce, or whether you are accumulating a deficit that will surface at the worst possible moment.

The developers who will be in the best position a year from now are the ones who are building mental models now — not memorizing syntax, not doing flashcard drills, but actively working with the systems they build on, understanding how they fail, understanding the tradeoffs, and developing the kind of judgment that makes AI-generated code something they can evaluate rather than something they have to trust on faith.

That is a different kind of learning than most technical content is designed to deliver. Documentation tells you what exists. Tutorials walk you through the happy path. Neither one puts you inside a failing system and makes you reason through it.

There is a way forward. That's the next post.

If you want to start building that kind of understanding now — the kind that makes you an effective reviewer of AI-generated code, not just a fast generator of it — the DevRecess sessions are designed around exactly that. You are dropped into a system under stress and made to reason through it. Not a tutorial. Not a flashcard. A scenario that builds the mental model through the only mechanism that actually works: doing.

Browse the sessions at github.com/canedy/devrecess-sessions — free, open source, covering Kubernetes, Docker, Bun, Mastra, and more.

Or start at devrecess.com.

Sources

Back to all posts