The uncomfortable part of the AI coding boom is that the numbers are starting to push back. A widely discussed write-up on thoughts.hmmz.org argues that, in a METR study, experienced developers using an AI coding assistant were 19% slower overall.
That is a brutal result for a category sold almost entirely on speed. The promise was simple: type less, ship faster, feel smarter. Instead, the headline implication is almost comic in its bluntness: maybe the solution is cancelling my AI subscription.
<> The real story here is not that AI is useless. It is that “helpful” can still be expensive when the help arrives in the wrong part of the workflow./>
This matters because the discussion is not about toy benchmarks or cherry-picked demos. The framing points to a developer productivity experiment grounded in real coding work, which makes the result far more interesting — and far more irritating — than another abstract AI performance chart.
My read: this is less a verdict against AI than a verdict against uncritical AI adoption. Developers love tools that eliminate friction, but coding assistants often replace one kind of work with another: prompting, checking, rewriting, and untangling suggestions that are plausible enough to trust but wrong enough to waste time.
- Prompting overhead can eat the time you thought you saved.
- Verification burden shifts effort from writing code to auditing code.
- Context switching breaks concentration, especially on deep debugging or design work.
- Boilerplate gains may not offset losses in complex tasks.
That is why the “19% slower” claim, if it holds up, should not be dismissed as anti-AI noise. It is a reminder that productivity tools are not universal accelerators. A tool can be impressive, useful, and still net negative in a real workflow.
The Hacker News reaction suggests exactly that tension: the linked discussion drew 334 points and 224 comments, which usually means a mix of curiosity, defensiveness, and hard-earned skepticism. That is healthy. The hype cycle around AI coding has been so loud that even a modest study can feel like heresy.
The broader business implication is obvious: if developers conclude that AI assistants slow them down, subscription churn will follow. Vendors have sold speed as the core value proposition, so any evidence that the tool impairs real output threatens both pricing power and product positioning.
But the more important takeaway for teams is simpler: measure AI by task, not by ideology. AI may help with repetitive scaffolding, but it may hurt in architecture, debugging, and any work where correctness matters more than autocomplete velocity.
<> The winner here is not the developer who uses the most AI./>
<> The winner is the developer who knows when to turn it off./>
That is the part the industry keeps dodging. The question is no longer whether AI can write code. It is whether it can write your code, in your workflow, fast enough to justify the subscription.
