Chasing chokepoints

If you're puzzled why spending a fortune on agentic coding tools isn't helping you ship your software products any faster, there are two books you need to read to understand why.

One's a surprisingly-readable textbook called "Thinking In Systems", and the other is (of all things) a novel called "The Goal". They're required reading for production and operations engineers, and if I ruled the world, they'd be mandatory for developers too.

Building something, whether it's creating something virtual like software or physical like a product, can only run at the speed of its slowest process. You can't build walls until the concrete of your foundations has set. If the throughput of your machines are mismatched, you end up with piles of unfinished work in progress, or machines standing idle for want of parts.

It's blindingly obvious when you see it, but we're terrible at seeing it because software doesn't pile up in warehouses. But software was never any different, and we're learning this the hard way in the industry.

The bottleneck isn't typing the code. That's the part we've automated with agents, but all this has done is expose the constraints in the other parts. You can't start building because the specs and designs aren't there; or you can't deploy the results because they're piling up in pull requests.

Speeding up throughput in one part of a system and ignoring the effects on the others just shifts the problems around, and we're going to be burning tokens pointlessly until we figure this out.