Devesh Korde
March 16, 2026
I merged a pull request last week that was almost entirely AI-generated. The code was clean. The tests passed. The types were correct. The function names were reasonable.
It also had a subtle race condition that wouldn't show up until production load hit it, and an error handling path that silently swallowed failures instead of surfacing them. I caught both during review. It took me forty minutes. Writing the same code from scratch would have taken me maybe an hour.
That math save twenty minutes writing, spend forty minutes verifying is the story of AI-assisted development in 2026, and almost nobody is talking about it honestly.
Here's where we are. According to Sonar's State of Code Developer Survey, developers now estimate that 42% of the code they commit includes significant AI assistance. That number was 6% in 2023. They expect it to hit 65% by 2027.
At the same time, 96% of those same developers say they don't fully trust that AI-generated code is functionally correct.
Read those two numbers together. Almost half the code being shipped was written by a tool that almost nobody trusts. That's not a productivity revolution. That's a verification crisis wearing a productivity costume.
And it gets worse. Despite that 96% distrust figure, only 48% of developers say they always check AI-assisted code before committing. The other half is merging code they don't trust from a tool they know makes mistakes. Not because they're lazy because the pressure to ship is real and the review cost is high.
AWS CTO Werner Vogels put a name on this at re:Invent 2025, and it's the most useful framing I've heard: verification debt.
When you write code yourself, comprehension comes with the act of creation. You understand it because you built it. When the machine writes it, you have to reconstruct that comprehension during review. That reconstruction costs time, and when you skip it which half of developers admit to doing you're accumulating a debt that compounds silently.
Here's the part that really matters: 38% of developers say reviewing AI-generated code takes more effort than reviewing code written by their colleagues. Not less. More.
Think about that. The tool that's supposed to save you time produces output that is harder to verify than what a human would have written. Not because the code is bad it often looks excellent. That's exactly the problem. It looks correct. It reads well. The variable names make sense. And then it has a subtle flaw that a human reviewer has to catch without the context of having written it.
61% of developers agree that AI-generated code "looks correct but isn't reliable." That sentence should be on a poster in every engineering team's standup room.
The surveys say developers feel 20-30% more productive with AI tools. Controlled studies tell a different story. When researchers actually measure total task completion time including review, debugging, and correction experienced developers are sometimes slower with AI than without it.
The disconnect is real and it's psychological. AI tools reduce the feeling of effort. Writing code feels effortless when Copilot is suggesting full functions. That feeling of flow creates a genuine sense of productivity. But feeling fast and being fast are different things, and the gap between them is filled with bugs you haven't found yet.
The Sonar survey found that developers still spend about 23-25% of their time on toil regardless of how much they use AI tools. The toil doesn't decrease. It changes shape. Less time writing boilerplate, more time validating suggestions. Less time drafting documentation, more time correcting generated docs. The total burden stays roughly the same it just moves from creation to verification.
AI doesn't eliminate friction. It redistributes it. And the new friction is harder, because it requires you to evaluate someone else's thinking without having access to their reasoning.
Let me be fair. I use AI coding tools every day. They are genuinely useful. For boilerplate, scaffolding, test generation, regex writing, and turning well-specified small tasks into working code, they save real time. I would not go back.
But there's a clear boundary, and it maps almost exactly onto context window limitations. AI is excellent at solving isolated problems. Write a function that does X. Convert this data structure. Generate tests for this interface. Anything that fits in a focused prompt with clear constraints, AI handles well.
The moment a task requires understanding how code interacts across a large codebase how modules depend on each other, what the failure modes are at integration points, why a particular architectural decision was made three months ago the tools struggle. They get nearsighted. They solve the immediate problem and break something three files away. They forget the twelfth instruction when you give them twelve.
One open-source developer I read about described spending months learning which problems trip the tools up and which they handle well. After that ramp-up, 90% of his code was AI-generated. But that ramp-up the deep investment in understanding the tool's failure modes is itself a skill that takes months to develop. The productivity gain is real, but it's not free, and it's not instant.
Here's the shift I think most developers haven't internalized yet: the bottleneck in software development is no longer writing code. It's evaluating code.
Writing was already getting faster before AI. Better languages, better frameworks, better tooling. AI accelerated that trend dramatically. But evaluation the ability to look at code and determine whether it's correct, maintainable, secure, and appropriate for the specific context it lives in that skill has not been automated. It can't be, because it requires understanding the system the code lives in, and no tool has that full picture yet.
This means the developers who will be most valuable in 2026 and beyond are not the ones who can prompt AI most effectively. They're the ones who can read code they didn't write and catch what's wrong with it. That requires:
Deep understanding of the language and runtime. You can't catch a subtle type coercion bug in TypeScript if you don't understand how TypeScript's type system actually works at the edges. You can't spot a concurrency issue if you don't understand the event loop. AI makes surface-level knowledge more dangerous, not less, because the code it produces looks competent even when it's not.
Architectural awareness. Knowing whether a function is correct in isolation is table stakes. Knowing whether it's correct in the context of this system requires understanding the system. Why does this service handle errors this way? What happens downstream when this response shape changes? AI doesn't know these things. You have to.
A healthy distrust of clean-looking code. This is the weird new skill. In the pre-AI world, clean code was a signal of quality. Now, clean code is the default output of every AI tool. Cleanliness no longer correlates with correctness the way it used to. You need to develop an instinct for probing beneath the surface of code that looks fine.
Concretely, here's what I do differently now compared to a year ago:
I review AI-generated code more slowly than human-written code, not faster. The instinct is to speed through it because it looks clean. I fight that instinct deliberately. I read it like I'm looking for a hidden mistake, because statistically, there probably is one.
I always ask: what is the AI not seeing? The model doesn't know about the production environment. It doesn't know about the edge case that took down the service last quarter. It doesn't know about the unwritten convention the team follows. Every review, I explicitly ask what context the AI was missing when it wrote this.
I write the tests myself when the AI writes the implementation. This is the single most effective pattern I've found. If AI writes both the code and the tests, the tests often validate what the code does rather than what the code should do. Writing tests by hand forces me to think about intent independently from implementation.
I invest more time in fundamentals, not less. This is counterintuitive but critical. The better I understand HTTP, data modeling, failure modes, and system design, the faster I can evaluate AI output. Fundamentals aren't less important because AI writes code. They're more important, because they're the lens through which you judge whether the code is actually good.
Here's my prediction: sometime in the next year, there will be a high-profile production incident caused directly by AI-generated code that was merged without adequate review. Not because the AI was malicious. Not because it was a bad tool. Because the verification wasn't there, and the code looked fine, and someone shipped it under deadline pressure.
When that happens, the conversation will shift from "AI makes developers faster" to "how do we actually govern AI-generated code." Companies will start requiring AI-specific review processes. Code quality tooling will evolve to flag AI-generated patterns. The "vibe, then verify" approach that some teams are already adopting will become standard.
The developers who are already building their verification skills now will be ahead of that curve. The ones who are treating AI as a shortcut to skip understanding will be the ones debugging the incidents.
AI writes code faster than you can. That's true and it's not going to change.
But faster code isn't better code. Better code comes from understanding what you're shipping, why it works, and how it fails. That understanding doesn't come from a prompt. It comes from the same place it always came from knowing your craft deeply enough to tell when something is wrong, even when everything looks right.
The bottleneck moved. Move with it.
