Throughput is up. Everything still sucks.

An engineering leader friend of mine summed up the reality of modern AI tooling last week: "we improved throughput but everything still sucks".

We're optimising the thing that wasn't broken

Almost every AI conversation right now is about making developers type faster. Completion, agents, generation. All pointed at one stage: producing code. And it works. People are shipping more, faster.

The catch is that producing code was almost never the bottleneck. If you measure where time goes between a good idea and running in production, most of it is waiting for a decision, waiting for review, or waiting for the one person with context to explain why the last person did it that way. It's QA, alignment, and the third meeting where everyone finally agrees what "done" actually means.

Speed up the one stage that wasn't the constraint and you don't speed up the system. You just pile work in front of the stages that were.

Where do AI tools actually create the queue?

A system only moves as fast as its slowest station. Make a fast station faster and nothing changes at the output, except now there's a bigger queue in front of the slow one.

That's what AI tools are doing to engineering orgs. Code generation got fast, so review queues are exploding. Half-understood code is landing in main and QA can't keep up. Product can't decide quickly enough to feed the machine. The bottleneck didn't disappear. It moved downstream, and because everything upstream now moves so quickly, it hurts more than it used to.

We are already seeing the strain at a macro level. Look at GitHub's recent platform stability issues; the sheer volume of machine-generated commits and automated workflows is forcing massive infrastructure rearchitecting just to handle the noise.

You haven't fixed delivery. You've made your real constraint impossible to ignore.

Should you gut management to move faster?

The fashionable take is to gut management. Sometimes that's the right call, often it's cargo cult.

Some middle management was pure information relay: taking a status update from one layer and passing it to another. Tooling can compress most of that and good riddance.

But a lot of management was doing something much more important: setting context. Deciding what's worth building and what isn't. Catching the bad call before it became three weeks of work. Keeping a group of people pointed roughly in the same direction. None of that goes away when output speeds up. It gets more important, because there's more output to point in the wrong direction, faster.

Cut the relay, keep the coordination, and you build a team that can actually use the tools. Cut both and you've just removed the brakes from a car you made quicker.

Does Conway's law still apply when AI writes the code?

Conway's law holds that organisations build systems that mirror their own communication structure. If your teams can't communicate cleanly, your software won't either, and no amount of generated code fixes that. A monolith shared by too many teams doesn't become coherent because those teams can now produce code faster; it becomes a mess, faster.

The constraint in software was never developer efficiency. It was communication, coordination, and the overhead of complexity. AI doesn't touch any of that by default. It adds to the pile, because now you've got more code, written more quickly, by people who understand it less deeply.

What should you optimise for instead?

Stop optimising for labour and start optimising for judgement.

The scarce resource has shifted from "who can build this" to "who can decide what's worth building, and verify that what got built is actually right." That changes the shape of a team.

You end up with fewer people, more senior on average, with broader scope each. Verification and taste become explicit jobs rather than things that happen invisibly. When a machine can produce a plausible-looking answer to almost anything, telling good from plausible matters more than it ever has. That's a skill, it's rare, and it's expensive.

The manager's job changes too: it's less "here's your ticket" and more "here's why this matters and here's what's in your way". It makes the relay parts obsolete and the actual leadership parts more valuable.

The gotchas

More surface, more debt. More code means more attack surface, more to maintain, more to secure. The sheer volume of generated code will bury teams who haven't treated architectural integrity as a first-class concern from the start.

Ownership erosion. When code is generated rather than written, fewer people deeply understand it. The first 2am incident in a system nobody actually read will sort out priorities pretty quickly.

The broken apprenticeship. If AI does all the junior work, how does anyone become senior? The judgement needed to supervise AI is the same judgement that used to come from doing the work AI now does in seconds. Nobody has a clean answer to this yet.

Velocity theatre. Shipping faster feels like progress. It isn't, if you're shipping the wrong thing faster, with nobody clear on who owns the outcome. The most dangerous org right now is the one mistaking motion for direction.

Where does this leave engineering teams?

The winners of the next few years won't be the ones that adopted AI first. Plenty of those are already drowning in fast-moving mess. The winners will be the ones that restructured around the new constraint: smaller, more senior, flatter, organised around judgement and feedback rather than labour and relay.

AI didn't break your org. It exposed it. The companies that already had clean decision-making and tight feedback got a turbocharger. The ones that didn't got handed a megaphone for their dysfunction.

Fixing this isn't about buying another AI tool; it's about looking honestly at how your teams communicate and where the work actually stops. This is exactly what we help companies sort out at Buildlight.

If you've added the tools, watched your output climb, and somehow everything still feels harder, let's talk. Book a 2-hour Delivery Baseline with Buildlight Labs. We'll find where your real constraint sits and map out how to clear it.