Writing Got Faster. Reading Didn't.

AI didn't remove the hard part of software. It moved it somewhere quieter, where it's much easier to skip.

I use AI to write code every day. This isn't one of those posts.

But something has been bothering me for a few months, and the 2026 research has caught up with it enough that I want to put it down properly.

We got much faster at producing code. We did not get any faster at reading it. And almost nobody planned for what happens in the gap.

The number that stopped me

A study across a set of large enterprises found that developers using AI assistants were committing three to four times faster than before — which is roughly what everyone expected and hoped for.

The same study found they were introducing security findings at about ten times the previous rate.

Not three to four times. Ten.

That ratio is the whole story. If the extra bugs scaled in line with the extra output, this would be a non-event — more code, proportionally more issues, same as hiring more people. But it doesn't scale in line. Something else is happening.

Three things going on at once

The code itself has a different quality profile. Veracode's testing found that around 45% of AI-generated code introduced a vulnerability from the OWASP Top 10. LinearB's data showed AI-assisted pull requests carrying roughly 1.7 times the issues of human-written ones. These aren't exotic failures — they're the ordinary ones. Input validation. Injection. Auth handled slightly wrong.

The review didn't scale with the output. Your team is the same size. The number of PRs went up several times over. Something has to give, and what gives is the depth of the read. A 900-line AI-generated diff does not get the same attention as a 40-line human one, no matter what anybody intends on a Tuesday morning.

Nobody's applying the same standard. This is the one I find hardest to argue with. Cloud Security Alliance found only around 12% of organisations hold AI-generated code to the same security bar as code their own people wrote. Not 12% who have a special process — 12% who apply the normal one.

The one that actually unsettled me

There's a failure mode here that didn't exist before, and I don't think enough people have heard about it.

Roughly one in five AI-generated code samples references a package that has never existed. The model produces a plausible-sounding name — something like requests_helper — and it looks entirely reasonable in an import block.

Attackers worked out that these hallucinations are predictable. Ask the same kind of question and you get the same invented names back. So they register those names on the public registries, with real code inside.

Now a developer accepts a suggestion, runs the installer, and pulls something into their build that an attacker wrote specifically to be found this way. The name looked fine. It always looks fine.

This got called slopsquatting, which is a silly word for a genuinely serious supply chain problem.

"The next model will fix it"

This is the reply I expect, and I don't think it holds up.

Veracode's finding was that the security pass rate has sat around 55% and stayed roughly flat since 2025, while coding benchmarks kept climbing over the same period. Bigger models didn't produce more secure code. They produced more code.

Which makes sense when you think about what these models learned from. Public repositories are full of working code. Working and secure are not the same thing, and there's far more of the former.

So this isn't something to wait out. It's a process problem, and process problems only get fixed by changing the process.

What actually changed about the job

Here's the reframe I've landed on.

Before, the bottleneck was writing. That's where the time went, that's what we optimised, that's what we hired for.

Now the bottleneck is verifying. And verification is quieter work — nobody demos it, nobody's impressed by it, and it's very easy to convince yourself you've done it when you've skimmed.

There's a developer survey from this year where people were asked which skill matters most now. The top answer wasn't prompting. It was reviewing and validating AI-generated code.

That's a real shift, and most teams haven't reorganised around it at all.

What I actually do

Nothing here is clever. It's just applied consistently, which is the only part that's hard.

Check every import exists before installing anything. Ten seconds. Catches the supply chain problem above completely.

Never merge AI code I can't explain out loud. If I can't say what a block does and why it's there, it doesn't go in. This one rule catches most of the rest.

Same review bar as human code. No exceptions, no "it's just boilerplate." Boilerplate is where auth bugs live.

Scanner in CI, not in a browser tab. If it's a thing someone has to remember to run, it doesn't get run.

Write the tests myself, or at least not with the same tool in the same session. A model that misunderstood the requirement will write a test that confirms the misunderstanding.

Keep diffs small. This is the highest-leverage one and the least followed. A large AI-generated diff is functionally unreviewed no matter who approves it.

The part that stings

AI didn't remove the hard part of building software.

It moved it downstream, where it's harder to see and considerably more expensive to fix. Technical debt that used to accumulate over years now accumulates over sprints, and it accumulates in code nobody has fully read.

None of which is a reason to stop. The productivity gain is real and I'm not giving it up. But shipping four times faster while reviewing at the same rate as before isn't going faster. It's going faster downhill.

Ship quickly. Just know what you're shipping.

If you're running an AI-assisted team — are you reviewing that code the same way you'd review a colleague's PR? I'd be interested in honest answers, because I suspect the number is closer to that 12% than any of us would like.