AI Made My Code Better. It Also Made Me Slower.

The “AI makes you 10x faster” pitch is starting to crack. Scroll through Hacker News or r/ExperiencedDevs lately and you’ll find a strange confession piling up: since adopting Copilot, Cursor, or Claude Code, the code is measurably better — and the work is measurably slower. Not by a little. Enough that people are writing essays about it.

“AI Coding Works. That’s the Problem.”

That’s the title of a SimonDev video posted April 27 that crossed 100,000 views in a month, with over 5,000 likes. The framing is deliberate. The complaint isn’t that AI coding tools fail. It’s that they succeed just well enough to short-circuit something important.

The argument: AI output looks too plausible. When you wrote code yourself, you went through a quiet internal dialogue — why does this function need to exist, is this variable named right, what happens if the input is empty. When a model hands you a finished block in two seconds, that dialogue never happens. You skip straight to “looks good” without ever building the mental model.

Why the code genuinely gets better

The quality improvement isn’t imaginary. Three things show up consistently in the reports:

Edge cases get caught. A human writing under deadline ships the happy path and moves on. The model reflexively adds null checks, type guards, and try/catch blocks because that’s what its training corpus rewards.

Naming and structure stay consistent. The classic code-review nit — “this variable name doesn’t tell me anything” — shows up less in AI-assisted PRs. The model has read more style guides than any of us.

Test coverage rises. Unit tests that no one wanted to write at 5pm now take 30 seconds to scaffold. Even half-hearted “write tests for this file” prompts produce something usable.

So where does the time go

This is the interesting part. The slowdown isn’t one big thing — it’s three smaller ones compounding.

Verification. AI-written code looks right at a glance, but you can’t trust it at a glance. You have to actually read it line by line to confirm it does what you meant. Code you wrote yourself is already in your head; AI code is foreign code you need to parse from scratch. That parsing isn’t free.

Prompt authoring. “Write me this function” doesn’t get a useful answer. “Write me a function that takes X, returns Y, handles these three edge cases, and matches our existing error-handling pattern” does — but composing that prompt eats 5 to 10 minutes. Sometimes it’s genuinely faster to just type the code.

Context switching. Ask in the chat, read the answer, paste into the editor, find the bug, ask again, re-paste. Each hop is small. Stacked across a day, they bleed hours.

Code review is shifting too

A May 23 video from K4 Coding Academy, “AI-Assisted Code Review: Semantic Intelligence vs. Static Analysis,” points at a parallel pattern. AI reviewers are catching semantic bugs — logic errors, mismatched assumptions — that traditional linters never could.

Great in theory. In practice, the human reviewer now has to triage every AI comment: is this a real bug, or is the model pattern-matching on something that looks suspicious but isn’t? That triage is its own cognitive load. Quality of merged code goes up. Time per review goes up too.

What people are actually doing about it

Notably, none of the developers writing these “I got slower” posts are saying they’ve stopped using AI. They’re saying they’ve gotten more deliberate about where to point it.

The emerging heuristic: lean heavily on AI for the work that doesn’t require deep thought — boilerplate, scaffolding, tests, documentation, regex, SQL one-offs. Write the core business logic and the performance-sensitive paths by hand, where the act of typing is the act of thinking.

Productivity was never really “lines per hour.” If the real metric is code that still makes sense in six months and code that runs in production without paging anyone at 3am, then the time AI seems to cost you up front might just be time you would’ve spent later anyway — pulled forward, paid in advance. So the honest question for your own workflow isn’t “am I faster?” It’s “am I shipping better code more slowly, and is that the trade I actually want?”