The bottleneck has moved. AI is rewriting the Software Development Lifecycle

If you've read our previous piece on the 8 stages of AI engineering maturity, you know where your team sits. Turns out adopting AI is the easy part; adapting to its consequences is where most organizations struggle.

For more than a decade, software organizations optimized around a single assumption: implementation capacity was scarce. Developer productivity tools, platform engineering, and automation all emerged from the same underlying logic — writing software was the primary constraint on delivery, and everything else was built around solving for that. As AI has begun to reduce that constraint, the bottleneck hasn't disappeared. It has simply moved, and it keeps moving.

Over the past several months, Fabien Potencier, Upsun's CTPO, and I — and a small but curious team — threw ourselves into conversations with Product and Engineering leaders about how AI is reshaping their organizations. We talked to a lot of people, asked a lot of questions, and came away with a lot to think about. This blog is our attempt to share what we learned. 

What came back surprised us — not in a single dramatic revelation, but in the consistency of a few signals that kept appearing across companies of all sizes. 

Greg Gambatto, founder of Ctrl+G,  put it plainly: "Our product and engineering organization now spends more on tokens than on salaries." Not cloud hosting, not payroll taxes. Tokens: an operational cost that nobody anticipated would grow as fast, and no financial system was built to track, let alone govern.

The engineers got faster. The organization didn't.

Adoption began where most technology shifts begin: with individual contributors. Engineers experimented, productivity improved, and the most advanced users moved from using AI as an assistant to orchestrating multiple agents simultaneously — generating code, writing tests, reviewing architecture risks, and deploying to the cloud. The gains were real and visible. What didn't change was everything around them.

Review processes, approval chains, and deployment controls were still designed for a world in which humans authored every line. As output increased, review queues grew alongside it, and senior engineers found themselves spending less time building and more time validating work they hadn't written. As one CTO put it: "We can generate a week's worth of code in an afternoon. But our review process is the bottleneck. It takes forever and still assumes humans authored everything." 

The constraint hadn't disappeared; it had migrated from creation to validation, and that migration exposed a challenge most teams hadn't anticipated, which overwhelmed the most senior members of the team.

The trust problem nobody planned for

Reviewers are no longer evaluating logic and style. They're hunting for hallucinations, architectural inconsistencies, and security issues buried inside otherwise convincing implementations — output that appears correct on first inspection but requires more scrutiny, not less. 

Some teams responded by automating the review layer itself, using layered agents that generate, critique, and score output before anything reaches a human. It works, but it isn't an upgrade to the existing process. It's a new one, built from different assumptions, and rebuilding it takes time and resources most teams hadn't budgeted for. 

While engineering worked through that, a different kind of pressure was building on the other side of the process.

Product became the next constraint

Several organizations started reporting something that would have sounded unusual just a few years ago: engineering was ready to ship features that product hadn't finished defining. 

Historically, implementation was always the limiting factor. That relationship has quietly inverted. AI systems don't handle ambiguity the way experienced engineers do; human developers fill gaps through discussion and judgment, while AI systems execute what is written, propagating vagueness directly into the output. 

Specification quality has become a first-class engineering concern, and org charts are beginning to reflect it — product managers prototyping directly, designers pushing commits, and engineers spending more time defining systems than writing every line themselves. When implementation becomes easier, clarity becomes the scarce resource.

The cost caught up

For most teams in the early stages, the economics feel manageable; subscriptions, predictable costs, productivity gains that justify the spend. That picture changes the moment orchestration enters. Token consumption doesn't scale with headcount the way software licenses do. It scales with usage, autonomy, and ambition, growing with every retry, every failed run, and every agent that explored further than it should have. 

Some organizations are already reporting AI engineering costs rising from hundreds to thousands of dollars per engineer per month. Uber's CTO told The Information the company burned through its entire 2026 AI budget by mid-April. On the All-In podcast, Salesforce CEO Marc Benioff said the company expects to spend $300M on Anthropic tokens in 2026, almost entirely on coding. Tokens have quietly become strategic enough to compete with payroll, and most finance teams don't see it coming.

A new SDLC is emerging

What is changing is not the existence of review, governance, or product definition — it's their relative weight. For years, implementation speed was the primary constraint, and the entire industry organized itself around solving for that. AI has dramatically reduced that constraint and, in doing so, has exposed everything quietly sitting behind it.

The organizations adapting fastest are not the ones with the best models. They are the ones willing to rethink the assumptions embedded in how software gets built; their processes, their team structures, their economics,  and to treat that rethinking as seriously as any technical decision.

The bottleneck didn't disappear. It moved into review processes, product specifications, and token budgets that nobody planned for. The teams pulling ahead aren't distinguished by the tools they use. They're distinguished by how quickly they noticed where the constraint had moved.