Here's a number that should make you uncomfortable: experienced developers using AI coding tools were 19% slower than without them. But here's the kicker — they thought they were 20% faster.
Read that again. The difference between what people think and the truth is almost 40 percent.
This is not just a random comment from Twitter. It's from a study that measured actual task completion times against self-reported speed estimates. And it paints a picture that most of us don't want to look at.
The Confidence Trap
We've all felt it. You fire up your AI assistant, watch it spit out 40 lines of code in seconds, and think wow, I'm flying. The dopamine hit of seeing instant output is real.
But output isn't progress. Speed of generation isn't speed of completion.
The research revealed that skilled developers invested significant time in debugging and re factoring the AI-generated code which the AI provided fast but then they spent more time than writing it from scratch, fixing it, understanding it, and fitting it into a functioning program.
The cruel and bitter irony here? The junior developers did not experience this as severely, as this was already part of what they thought they would be doing, i.e. spending time to understand code that they had not written themselves. The seniors assumed that the AI “understood” it since, well, the output seemed correct. 🎯
Why Experience Works Against You Here
If you've been coding for 10+ years, your pattern recognition shows you a quick preview of the code and your brain responds with "yes, that seems right".
That instinct, which usually makes you fast, becomes a disadvantage with AI code. You are pattern-matching against the surface-level structure and not actually verifying logic. It looks like something you would write. So you trust it.
Then 20 minutes later you're hunting down a subtle bug in logic you didn't actually write or fully read. Sound familiar?
→ AI output looks competent, which disarms your review instincts
→ The time "saved" on writing gets eaten by debugging you wouldn't have needed
→ Self-reported speed is based on generation time, not completion time
The Perception Gap Is the Real Problem
It's not good to be slow. But being slower while believing you're faster is dangerous.
It means you won't adapt. You won't doubt the technique. You'll keep reaching for it in situations where your own expertise would have been faster, because your gut tells you a story that the stopwatch contradicts.
Such bias compounds. If a whole team believes they're 20% faster, they'll plan sprints accordingly. Commits to more work. Then they'll miss deadlines and blame something else. 😅
So Should We Stop Using AI Tools?
I see what you mean.
The takeaway is that AI tools require a different kind of discipline from experienced developers. You can't just accept the output. You have to treat AI-generated code with the same skepticism you'd give a junior developer's pull request — maybe more, because a junior dev at least understood their own intent.
→ Read every line the AI generates like you're reviewing someone else's code
→ Track your actual completion time, not just how fast the first draft appeared
→ Be honest about when writing it yourself would be faster
The developers who will benefit the most from using these tools are those that distinguish between output velocity and delivery speed. They are not the same thing.
The Uncomfortable Question
I think most of us — myself included — have been riding the vibes on this. It feels faster, so we assume it is. This study is a cold splash of water. 🧊
The engineers who are best at adapting, in my view, are already doing it. They adopt AI strategically. They validate rigorously. They don't let the tool's confidence infect their own judgment.
Here's what I want to know: have you ever actually timed yourself with and without AI on a real task? Not a toy example — a real feature, a real bug fix. I don't mean in a contrived coding "race" or something, but on an actual project, feature or bug. I'd guess most of us haven't.
Top comments (0)