For three years, I’ve watched the AI coding revolution unfold with a mix of fascination and frustration. As someone who’s built and led AI engineering and product teams at Google, SwiftKey, Yahoo, and beyond, I’m calling it: we’re collectively falling for a productivity mirage.
We’re celebrating typing speed while ignoring the actual bottlenecks that cripple software development and most annoy dev teams.
Developers only spend a couple of hours daily writing code, and they hate this. They spend most of their time “not making their beer taste better”, and doing soul-sucking boring work. Scaffolding projects, managing tickets, refining stories, fixing bugs, handling tech debt, writing tests, fixing build issues… you only need to look at the Stack Overflow blog to hear the outcry. Yet, as a society, we’re pouring millions into making those 1-2 hours marginally faster – those hours where devs actually have the most fun.
The problem with dopamine
We are witnessing what I call “the 80% problem” across the industry – a dopamine hit that hides the real pain. What do I mean by this? I used to joke that, with bad management, “the first 80% takes 20% of the time, and the remaining 20% takes… 80% of the time”. Well, we’re managing AI badly. Current AI tools get you 80% of the way quickly, creating a dopamine hit of productivity. It is the last 20% that wastes all your time savings. It’s like sprinting the first 19 miles of a marathon and feeling great, but then having absolutely no legs to finish off the remaining 7 miles you have left.
It’s that 20% that contains most of the subtle bugs because AI has made a litany of minute errors that have piled up, without oversight. It’s this final 20% that represents the actual design challenge requiring human expertise – and honestly, that should have been done in collaboration with the AI, not after the AI. The result is a psychological mirage where developers feel productive initially, but team velocity remains stubbornly unchanged. Even worse, you’re building up technical debt in the form of poor quality that, over time, means your product and technology starts to slowly crumble under the AI code-slop.
This tunnel vision is baffling if you’re a competent manager. To draw on another analogy – imagine Toyota revolutionizing manufacturing by only optimizing how quickly workers insert screws, while ignoring the entire production line. We’d laugh at such limited thinking. Yet this is precisely what’s happening with AI coding tools.
A recent Wired survey of 730 developers captured this perfectly, with many seeing AI as “useful, but clueless”—essentially a hyperefficient intern that still can’t handle context, edge cases, or real problem-solving. This matches exactly what I’ve observed in enterprise environments.
Speaking with CTOs across the industry, I’ve yet to find one who can demonstrate consistent, measurable improvement in delivery metrics from their AI investments. Where are the SEC filings showing reliable 20+% speedups? They don’t exist, because we’re optimizing the wrong things.
Instead, we’re transforming developers into glorified secretaries for AI – manually ferrying context between systems, copy-pasting specifications, and cleaning up hallucinated code. The bitter irony is that tools meant to eliminate tedious work have created a new form of drudgery, removed the fun, and even created new messes. You’re not using the AI—you’re serving it. It’s easy to feel productive initially, but it’s not sustainable unless you bring complete context to the AI… at which point you’re essentially working for the AI, not the other way around.
Suffering from buyer’s remorse?
Given the frenzy of spending over the past few years, I can’t just complain, so here’s some remedial advice to those CTOs who didn’t keep the receipt on those AI coding tools:
First, demand measurement beyond vanity metrics. Focus exclusively on time from a well-written ticket to deployment – that’s the only throughput that matters. Don’t ask devs whether they “feel more productive” because they have outsourced thinking to AIs.
Second, prioritize quality alongside speed. You can’t accept that writing subtle defects into your code faster is a good trade-off. Context is everything in engineering, and tools that can’t access and understand your full development context will always deliver subpar results. Tools should discover the context for you; why are you chasing down context for the AI? Are the tools looking at tests and architecture docs automatically? Are they running what they write against your tests automatically and fixing the issues? Are they running your linters or following your most basic coding requirements?
Third, widen your scope of optimization, don’t narrow it. This feels counterintuitive – we’re taught to ship in thin slices. But the greatest system improvements come from global optimizations, not local ones. It’s like my experience building IoT devices: rather than squeezing 15% better performance by optimizing a power-hungry GPS chip, we solved the local problem by solving it globally: we added a 2-cent motion sensor and a 5-cent low-power processor that triggered the GPS only when needed, transforming battery life entirely.
The truly transformative opportunity lies in removing entire steps from your process, not optimizing individual ones. Why are we paying senior engineers £150k to manually create branches and scaffold boilerplate code? Why do we care at all about typing speed now?
Consider Stripe and Netflix – their competitive advantage comes not from typing code faster but from ruthlessly eliminating handoffs and bottlenecks between teams. Stripe invested heavily in streamlining code reviews, testing automation, and deployments between engineering, product, QA, and operations teams. Netflix focused on automated delivery pipelines and chaos engineering practices that minimized bottlenecks between dev, ops, and deployment teams, enabling rapid global deployments.
This isn’t just about efficiency – it’s a strategic advantage. While others celebrate marginal coding gains, companies addressing the full development lifecycle are entering markets faster and responding to customer needs before competitors even understand the requirements. It’s the difference between market leadership and irrelevance. And you have a bit of time before your competitors wake up and move on this before you do – but time is quickly running out.
The path forward is clear: treat AI as a system that completes entire tasks, not as a glorified autocomplete. Measure success through meaningful DORA metrics, not lines of code generated. And demand that AI adapts to your team’s established processes, not vice versa.
The question isn’t whether AI will transform software development. It absolutely will. The question is whether we’ll optimize what actually matters. And whether you’re leading or following.
The post The emperors of AI coding tools have no clothes – and it’s creating a productivity delusion appeared first on SD Times.
Source: Read MoreÂ
