AI is certainly able to increase coding speed, especially for experienced engineers who can design the analytical parts themselves (data structures, interfaces, invariants, and process), but in large projects and/or organizations, queuing theory (especially as understood by lean development practitioners like Don Reinertsen) is going to be nasty.

Lean development theory teaches us that in a multi-workstream, multi-stage development process, developers should be kept at roughly 65-75% utilization. Otherwise, contra-intuitively, work queue lengths increase exponentially the closer utilization gets to 100%. The reason is that slack in the system absorbs and smooths perturbations and variability, which are inevitable.

Furthermore, underutilization is also highly comparable to stock market options: their value increases as variability increases. Slack enables quick pivots with less advance notice. It builds continuous responsiveness into the system. And as the Agile Manifesto tells us, excellent software development is more characterized by the ability to respond to change than the mere ability to follow a plan. Customers appreciate responsiveness from software vendors; it builds trust, which is increasing in value all the more with the rise of AI.

But AI-driven development threatens to increase, not decrease individual engineer utilization. More is expected, more is possible, and frankly, once you learn how to guardrail the AI and give it no trust to design well analytically, the speed a senior engineer can achieve while writing great code with AI assistance often feels intoxicating.

I think we're going to go through a whole new spat of hard, counterintuitive lessons similar to those many 1960s and 70s developers like Fred Brooks and his IBM team learned the hard way.