If you thought the code writing speed was your problem; you have bigger problems

It's Tuesday morning. Your VP of Engineering is standing in front of a slide deck, vibrating with the kind of excitement usually reserved for people who just discovered cryptocurrency in 2017. They've just come back from a conference. Or maybe a vendor dinner. Three glasses of pinot noir and a demo, and now they have news.

"We're rolling out AI coding assistants across every team. Early numbers show a 40% increase in code output. This is going to transform our velocity."

The room does that thing where half the people nod along and the other half develop a sudden interest in their laptops. Your staff engineer is doing that face. You know the face - it's the one where they're calculating whether to say something or just update their LinkedIn later.

Nobody asks the question that matters, which is: velocity toward what, exactly?

Because here's what just happened. Your VP looked at your entire software delivery organisation, identified the one thing that was already pretty fast, and decided to make it faster. They found a station on the assembly line that was not the bottleneck, and threw money at it.

If you know anything about how systems work, you know this doesn't just fail to help. It makes everything actively worse.

Goldratt would like a word

In 1984, Eli Goldratt wrote The Goal, a novel about manufacturing that has no business being as relevant to software as it is. It's also the most useful business book you'll ever read that's technically fiction, which is almost the exact opposite of most KPI frameworks.

The core idea is the Theory of Constraints, and it goes like this:

Every system has exactly one constraint. One bottleneck. The throughput of your entire system is determined by the throughput of that bottleneck. Nothing else matters until you fix the bottleneck.

That's the part most people get. Here's the part they don't, and it's the part that should scare you:

When you optimise a step that is not the bottleneck, you don't get a faster system. You get a more broken one.

Think about it mechanically. If station A produces widgets faster but station B (the bottleneck) can still only process them at the same rate, all you've done is create a pile of unfinished widgets between A and B. Inventory goes up. Lead time goes up. The people at station B are now drowning. The pile creates confusion about what to work on next. Quality tanks because everyone's triaging instead of thinking.

You didn't speed anything up. You created a traffic jam and called it productivity.

The horror show, or: what actually happens when you "3x code output"

I bet some of you are already living this. I've lived it. It sucked.

Your developers are producing PRs faster than ever. Great. Wonderful. Gold star. Someone get the confetti cannon. Now those PRs hit the review queue, and your reviewers haven't tripled. Nobody tripled the reviewers. Nobody even thought about the reviewers, because the reviewers weren't in the vendor's slide deck.

So PRs sit. A day. Two days. A week. The author has context-switched to their next AI-assisted feature and can barely remember what the first one did by the time review comments land. "Can you explain what this function does?" they ask, staring at code they wrote eight days ago, which in developer memory is roughly the Jurassic period.

Reviews start getting rubber-stamped because there are simply too damn many of them to review properly. Someone approves a PR they didn't really read. We've all done it (don't look at me like that). It merges. CI takes 45 minutes, fails on a flaky test, gets re-run, passes on the second attempt. The deploy pipeline requires a manual approval from someone who's in a meeting about meetings. The feature sits in staging for three days because nobody owns the "get it to production" step with any urgency.

Meanwhile, the developer has already shipped two more PRs. The queue grows. WIP goes through the roof. Everyone has six things in flight and nothing actually done. Cycle time (the thing that actually measures how fast you deliver value to users) gets worse.

You are producing more code and shipping less software. You have made your situation measurably, demonstrably worse, and you have a dashboard that says productivity is up 40%.

Congratulations. You've built a factory that's world-class at producing inventory that sits on the floor and rots. Someone's getting promoted for this.

So where's the actual bottleneck?

If it's not writing code (and it almost never is), then where should you be looking? Walk the value stream. Follow a feature from "someone had an idea" to "a user got value from it."

1. You don't know what to build

This is the one nobody wants to talk about because it's embarrassing. Your PM hasn't talked to a real user in two months. Your requirements arrive as a Jira ticket with three sentences and a Figma link. Your engineers are making fifty micro-decisions a day about behaviour, edge cases, and error handling that nobody specified.

And they're guessing.

When you speed up code output in this environment, you are speeding up the rate at which you build the wrong thing. You have automated the guessing. You will build the wrong feature faster, ship it, watch it fail, and then do a retro where nothing changes.

The bottleneck is understanding the problem. No amount of faster typing fixes that.

2. Everything after the code is "done"

I put "done" in quotes because in most orgs, code being written is maybe 20% of the journey. The other 80% is your code sitting in various queues, slowly ageing, like a forgotten sandwich in the office fridge.

PR review. CI. Staging. QA. Security review. Product sign-off. Deploy window. The actual pipeline of getting code from a developer's branch to a user's screen is a long series of handoffs, waits, and queues. Most of the time, your code is sitting still. Waiting for a human to look at it. Waiting for a pipeline to run.