Press enter or click to view image in full size
A Stanford study estimates that private companies have spent over a quarter of a trillion dollars in investment related to AI. A colleague recently asked me:
“With all this AI investment, why aren’t we moving faster?”
The question is simple, but the answer is nuanced and complicated. Largely, the problem is that the current implementation of AI in software development shifts bottlenecks downstream increasing pressure rather than eliminating them.
Right now, AI accelerates tasks, not delivery systems.
The current suite of generally available AI tools accelerates a lot of tasks associated with delivering software but not all of them. The biggest impact of AI on software is the ability to author code. We’ve all seen this first hand in the capability of tools like Cursor, Claude Code, Github Copilot, etc. AI accelerates research. We can synthesize high volumes of documents into coherent summaries. We can understand complex code bases. We can do incredible AI-powered software archaeology. We can prototype solutions almost instantly. These are huge wins. But applied to the broader system of enterprise software delivery, they’re actually quite modest improvements.
Enterprise engineering orgs are bound by many constraints.
A large enterprise, especially a publicly traded company, faces a long list of hard constraints. There are compliance requirements tied to security, financial reporting, privacy, change management, and corporate controls that dictate the circumstances under which software can be released, who must approve it, what evidence must be retained, and how risk must be assessed along the way. The organizations, workflows, and systems built around these requirements are often arcane, deeply interdependent, and rarely at the frontier of AI enabled acceleration. They were usually designed to reduce operational and regulatory risk, not to maximize delivery speed. That means the limiting factor is often not how quickly a developer can produce a code change, but how quickly the surrounding enterprise machinery can review it, validate it, test it, document it, approve it, and move it safely into production. No matter how fast you make a code change, progress still has to pass through reporting obligations, security reviews, auditability requirements, release windows, and operational readiness checks. In that environment, AI can compress parts of the software creation process, but it does not automatically remove the institutional friction that governs how software actually gets shipped.
AI increases output, which often increases work in progress.
Work in progress or WIP is a well understood drag on overall system throughput. Toyota was a pioneer in understanding manufacturing pipelines. The company developed many practices and concepts that modern corporations use today including, treating excess WIP as waste because unfinished inventory hides problems and slows delivery. In the Toyota Production System, Taiichi Ohno introduced kanban pull systems that strictly limited WIP between production steps. Downstream stations requested only small amounts of work from upstream stations, preventing queues from forming. This exposed bottlenecks immediately and improved flow, lead time, and quality.
In software development, large amounts of authored but unreviewed or undeployed code create the same WIP problem. Code sitting in pull requests or long-lived branches functions like inventory on a factory floor. It waits in queues for review, integration, and testing. This delays feedback, increases merge conflicts, and allows defects or design issues to accumulate unnoticed.
AI as a powerful multiplier for code authoring exacerbates this problem. Code authoring tools that increase change volume can increase WIP at an alarming rate if the rest of the software development lifecycle is not correspondingly scaled to accommodate it.
Coding was never the bottleneck. Software is constrained by coordination.
In large organizations, software projects can touch a lot of areas. Take an e-commerce checkout system for example. At a minimum alignment has to be reached between inventory systems, payment processing systems, site development teams, app development teams, security, financial compliance and legal. Each of these areas may have product teams, engineering teams, QA. The dependency graph can reach into the hundreds.
Decision complexity increases as more people participate because communication paths grow rapidly. As Fred Brooks observed in The Mythical Man-Month, the number of communication channels grows as n(n−1)/2, meaning coordination overhead increases nonlinearly as teams expand. For example: 3 people → 3 communication paths, 10 people → 45, and 100 people → 4,950. Each added participant dramatically increases alignment effort and slows decisions.
Weighed against this complexity, writing code is relatively simple. The problem is and has always been aligning stakeholders on what the code should actually do.
Quality expectations rise along with capability.
As delivery capability increases, quality expectations tend to rise with it. When teams can produce code faster, the organization often reinvests that capacity into higher standards for reliability, security, resilience, observability, accessibility, test coverage, and user experience. Features that might once have been considered acceptable with rough edges are now expected to be polished, instrumented, recoverable, and safe under a wide range of conditions. In practice, that means faster code generation can expand the scope of what “done” requires. More scenarios are tested, more edge cases are addressed, more controls are added, and more stakeholders expect production-ready outcomes rather than minimum viable products. The result is that even as capability improves, software development lead times do not necessarily fall in proportion, because the definition of acceptable software keeps getting more demanding at the same time.
AI adoption has a temporary productivity dip.
AI adoption often comes with a temporary productivity dip before it produces durable gains. Teams have to learn new tools, revise workflows, establish guardrails, sort out where the technology is genuinely useful, and unlearn habits built for an earlier mode of software delivery. Early use can be very uneven to the point of being counterproductive. Some people overtrust the tools, while others underutilize them. Most folks spend a period of time experimenting, correcting mistakes, and figuring out how to integrate AI output into existing engineering standards. At the same time, managers and platform teams are putting new policies, review patterns, security controls, and evaluation methods in place. All of this adds friction before it removes it. The result is that during the adoption phase, organizations often experience confusion, rework, and inconsistent output quality that can make throughput look worse. Only after the tools, practices, and expectations mature does the underlying productivity benefit start to show up consistently.
So what can we do?
If AI shifts bottlenecks downstream, we have to go downstream to address them. That starts with identifying where work actually waits after code is written. Review queues, test environments, security signoff, dependency alignment, release governance, or production readiness. We have to bring the same leverage to bear in these areas that we have on coding. Instead of doubling down on coding velocity, let’s switch focus to autonomous code review and deployment. We need to invest in AI powered approval chains, evidence collection for compliance, and streamline common classes of changes so teams do not repeatedly solve the same governance problem from scratch. For many of the teams that own these compliance systems this is going to require a culture shift to align with an AI accelerated delivery model. The nature of these changes is going to vary widely depending on the team and system we’re talking about, but largely the approach is to terraform systems for AI agents to safely operate on them. If your governance flows have many manual steps or are beholden to proprietary software with limited APIs, it’s going to be very difficult for agents to operate in those spaces. The key is going to be making these flows navigable by agents, including the validation and clearly defined human in the loop steps as necessary.
We can also focus AI use on the places where it reduces coordination cost. Let’s have agents negotiate requirements clarification and write automatic documentation. Incident root cause analysis should be largely hands off, relying on automated observability platforms and bringing humans into the loop only later when subjective analysis and prioritization is required. Later, the findings can exist as structured data to be consumed by agents upstream in the software development lifecycle. Rather than relying on architects to peruse arcane RCA docs and hopefully intervene before problematic patterns are repeated, we create systems that learn from their own failures. This allows us to increase the rate at which high-confidence changes can move all the way through the system.
If all this starts to sound familiar, it’s because it is. These are largely the same problems we’ve been facing in software engineering for decades. Heightened investment and expectation bring new scrutiny to age old issues. AI doesn’t change the nature of the problem, but it may finally give us the tools and leverage to solve it.