You’ve heard the hype: AI coding tools are making developers 10x faster. But look around. Where are the apps? Where’s the explosion of innovation? If you’re an engineer, you’ve felt the eye-roll every time someone says, “Just generate more code.” The bottleneck isn’t writing code. It’s everything else.
I spent a decade building software at scale. Last year, I watched a team crank out 10,000 lines of AI-assisted code in a week. The next week, they spent 90% of their time debugging, integrating, and untangling dependency hell. The project shipped two months late.
Measuring lines of code is like measuring a chef by how fast they chop onions. The meal still takes the same time to cook. This is the productivity mirage. AI compresses the time to write code, but engineering delivery is governed by system-level friction—requirements ambiguity, integration complexity, testing, deployment, and maintenance. Local speedups don’t translate to organizational velocity.
Think about it. The real question from the top comment on a recent analysis nails it: “If AI enables all these no-coders to create applications, where are those? Aside from a few that got hacked the instant they were put into production, I haven’t heard about them.” That’s the twist. Code generation was never the missing ingredient. Product-market fit, operational rigor, and maintenance were.
So why is everyone measuring keystrokes? Because it’s easy. But when you optimize for the wrong metric, you get the wrong behavior. AI is silently accumulating technical debt. Every generated function needs to be understood, secured, and maintained. The volume of code explodes, and coordination costs skyrocket.
If you measure keystrokes instead of outcomes, AI will optimize exactly the wrong thing—and widen the gap between perceived and real engineering throughput. This is dangerous. It’s making engineers worse at their jobs by rewarding speed over thought.
I’ve seen this firsthand. A startup CEO bragged about their AI-driven productivity. Their codebase was a jungle. Every new feature broke three old ones. The team was burning out. The CEO was measuring lines; the engineers were measuring pain.
What’s the fix? Stop treating coding as the bottleneck. It’s not. The bottleneck is clarity, integration, and maintenance. Invest in those. Use AI to reduce cognitive load, not to flood the system with half-baked code. And for the love of engineering, stop celebrating keystrokes.
The best engineers I know don’t write more code. They write less. They think more. They ask better questions. AI should make them better thinkers, not faster typists.
Here’s the truth: engineering velocity is about reducing friction, not increasing output. Until we measure the right things, the hype will keep promising speed, while delivering slower, more fragile systems. The apps aren’t coming because code was never the missing piece. The missing piece was discipline.
FAQ
Q: Aren't AI coding tools still improving rapidly? Won't they eventually solve the friction problem?
A: Maybe, but not yet. The friction isn't in code generation—it's in understanding requirements, integrating systems, and maintaining complex codebases. AI can't fix unclear product specs or legacy spaghetti. Tools that only generate code faster actually amplify the maintenance burden.
Q: So should engineering leaders stop using AI coding tools altogether?
A: No. Use them, but measure what matters. Instead of lines of code or tasks completed, track cycle time, deployment frequency, and incident rate. Use AI to automate rote tasks, not to generate speculative code. The goal is to reduce cognitive load, not to inflate output.
Q: Isn't this just a luddite take? Innovation always comes with friction.
A: It's the opposite of luddite. I'm all for AI—but I want it to actually work. The contrarian truth is that the biggest productivity gains come from reducing the need for code, not increasing its production. The teams that win will be the ones that use AI to write less, not more.