84% of Developers Use AI Tools. So Why Isn't the Code Better?

A few months back we hit a 900-line pull request that was "knocked out in an afternoon." Tests green, CI passing, author pleased. It took us three days to realize the same validation logic had been copy-pasted into four places, each slightly different, and none of them actually covered the edge case the ticket was opened for in the first place. That wasn't a bad developer. That was a good developer with Copilot generating mediocre code very, very fast.

Per the 2025 and 2026 surveys (Stack Overflow, JetBrains, and others), roughly 84% of developers now use AI tools in some form. Great number. Now the uncomfortable part: in those same surveys, only about 29% of developers trust the output of those tools. Translation: most of us are using something we don't trust. That's not technology adoption — that's a habit we rationalize after the fact.

The feeling of speed ≠ speed

The best-known finding here is the METR study. Its early-2026 revision estimates experienced developers work about 18% faster with AI tools — but the same methodology a year earlier found them working 19% slower, even though those same developers were subjectively convinced they were faster. Set aside which number is correct. The point is the gap between perception and measurement. AI is remarkably good at making you feel like you're making progress. Code streams onto the screen, autocomplete lands, dopamine fires. Is the problem solved? That's a separate question.

McKinsey's study across thousands of developers paints a healthier picture: roughly 46% time savings on routine tasks, but under 10% on complex work. Which is actually intuitive. AI shines at boilerplate, CRUD, test skeletons, the regex you never remember. On the stuff where you weren't spending brainpower anyway. Where you do spend it — architecture, edge cases, "why does this service even exist" — it helps far less, and sometimes actively hurts, because it produces a confident, syntactically perfect, conceptually wrong suggestion.

The bill nobody is tracking

Here's where "productivity theater" gets expensive. GitClear's data shows code churn has doubled — from around 3.3% to 7.1% — meaning we increasingly write code only to delete or rework it soon after. They also record a spike in copied code (copy-paste instead of refactoring into a shared abstraction). Sonar's survey is even blunter: 88% of developers report a negative impact on technical debt.

Add it up. You're writing more code, faster, that you change faster, with more duplication, piling up debt in the process. Output metrics (PRs, lines, tickets closed) look great on the dashboard. Outcome metrics (maintainability, incident count, time-to-next-change) quietly move the wrong way. Security is its own chapter: some measurements show AI-generated code carries up to ~2.7x more vulnerabilities than a team would otherwise ship. None of it shows up in the retro, because it doesn't show up in the same week.

So AI is a scam? No.

It isn't, and we'd be dishonest to claim otherwise. The gain is real — it's just narrower and more specific than the marketing claims. AI is an excellent multiplier for:

• Boilerplate and scaffolding — you reach a first working state faster.
• Exploring the unknown — explain someone else's code, a library, a stack trace.
• Small, well-fenced changes where context is tiny and verification is cheap.
• Killing the "blank page" — editing a bad suggestion beats starting from nothing.

What AI does not do is think for you. It doesn't define the problem, choose where the abstraction boundary goes, or decide which edge case is allowed to fail. That's still senior work — and AI makes it easier to skip, because a mediocre decision now arrives dressed up as finished, tidy code.

What actually makes the difference

Teams where AI delivers a real gain aren't doing anything exotic. They do this: treat AI output like a junior's PR — it goes to review, not to main. They measure outcomes, not lines. They keep tests and types strict, because that's the only defense that scales at generation speed. And they have someone allowed to say "this is too much code for a problem this size" before the merge, not three sprints later.

AI is not a substitute for engineering judgment. It's an amplifier. It amplifies a good process and it amplifies a bad one. If your team's output jumped but quality didn't, the problem is almost never the tool — it's that the feeling of productivity started getting measured instead of productivity itself.

---

Related:

• Vibe Coding Is Great — Until It Hits Production
• AI in Web Development 2025: Where It Actually Helps and Where It's Just Hype

At Tempus Media we build software with AI where it makes sense, and without it where it costs more than it returns. If you're not sure whether your team is using AI as a tool or as an excuse — contact us. We're happy to look at your codebase before the next incident does.