The Bottleneck Moved: Today’s Enterprise AI Value Problem

BY Richard Newcomb, Senior Director, Forward Deployed Engineer

We spent decades getting faster at writing code. AI made that the cheap part, then showed us where the real constraint was hiding the whole time.

Here’s a number that’s been rattling around in my head for a few weeks.

In my recent work with clients (I’ve come to find this is generally true across all of them), one day of development can easily turn into a month before production. Five days of harder work can turn into a quarter or more. Not because the building is slow. The building is the fastest it has ever been. The code is done, tested, and sitting there ready. And then it waits.

I want to talk about why it waits, because I think it’s the most important thing happening in software right now – and almost nobody is naming it directly.

The whole software development lifecycle was designed around the assumption that writing code is expensive, slow, and risky. We built every process, every methodology, every standup and sprint to manage that one constraint.

Thanks to AI, that assumption no longer holds. 

A capable engineer with good AI tooling can stand up a working system in a day that used to take a quarter. The cost of building collapses. But removing a bottleneck doesn’t give you instant delivery. It gives you a new bottleneck. 

That’s because AI didn’t remove the SLAs, change advisory boards, database provisioning queues, or firewall ticket queues required for new software to go live. 

The work does not wait because nobody can write the code. It waits because nobody has redesigned the operating model around the fact that code is no longer the slowest part.

AI turns software delivery from a code-shipping problem into an architectural one. Time to value is the most important metric, but it’s lagging due to slow processes. One day of work still requires five weeks to push live on a database. Two weeks to complete a firewall request. Three weeks for a vendor review. 

A few patterns show up again and again.

The use case gets approved before the decision rights do. Everyone agrees the work matters until it has to touch a real workflow. Then the room expands. Product, security, legal, finance, and operations all crowd the decision-making table. They pile it high with their own isolated processes and priorities. Progress moves at the speed of yesteryear’s coding. Weighing and optimizing for each of their needs takes even longer. The build is ready, but the organization is stuck figuring out who can say yes.

The pilot worked because it avoided the hardest part. A demo can run on a manicured path of curated data, with a human quietly cleaning up the edges. Production cannot. It needs exception handling, monitoring, escalation paths, auditability, rollback plans, and a clear answer when the model is confidently wrong. The prototype proved the model could do the task. Not that the company could operate it.

The data exists, but the workflow cannot actually use it yet. Having the data somewhere in the enterprise is not the same thing as having it in the right format, behind the right permissions, attached to the right definition, owned by the right team, refreshed at the right time, and available to the system that now needs it. The model can be ready long before the access path.

The old gates do not prove the new behavior. The green checkmarks can tell you the code ran. They cannot tell you whether the system retrieved the right context, followed policy, cited the right source, degraded safely, or knew when to stop. Until those questions have their own gates, teams either ship with false confidence or pause because nobody trusts the system enough to let it move.

None of that is a coding problem. All of it is a coordination problem.

The code and build were ready. The company was not.

That is the part AI has exposed. We got exactly what we asked for: faster development. Then we discovered that development speed was not the only thing holding delivery back. It was just the thing hiding everything else.

And this is only today’s list. The specific blockers will churn – data access, model approval, security reviews, infrastructure. The durable truth is that the constraint keeps moving.

The durable advantage is not clearing today’s blocker faster. It is building an operating model that expects the next one before it has a name.

If the constraint has moved, then the leverage has moved with it. And that opens up a way of working that wasn’t worth imagining when building was the slow step.

Picture the path cleared before the work starts. Models pre-vetted, so no one re-litigates the same selection mid-project. An approval lane that’s been agreed in advance instead of discovered at go-live. Quotas treated as a known prerequisite, requested early like you’d order long-lead hardware, not as a surprise escalation three weeks before launch. Outputs match your unique business, not that of a generic payer. This is the discovery sprint that answers the question of what to build.

Now add a context layer underneath all of it. An ontology that connects your organization’s data sources to its business definitions in one place. That eliminates the need for every project to rediscover what a “member” or “provider” is, which call-reason codes to match to which member services workflows, or how to interpret prior-authorization criteria during claims processing. It inherits all of that. The vetted knowledge compounds. The approval you won once, you don’t fight again.

And token budgets stop being a wall you slam into. They become a design parameter. You plan a workflow’s token cost the way you plan any other budget: up front, deliberately, as part of the architecture rather than a constraint you trip over halfway through.

That’s the shift. When code was scarce, you optimized for writing less of it. When code is abundant, you optimize for clearing its path. The organizations that internalize this will win because they removed the reasons good work sits in a queue.

In that world, ROAI (Return on AI Investment) stops being only a model-performance question. It becomes a wait-time question.

Time to value has to become core to the software development lifecycle at every stage – and without losing a quarter to the org chart. 

But value claims are politically and operationally messy. You need a clear way of measuring value before you build – and telemetry to help you prove it after release. Without that – and without a clear path to value realization – you don’t have an AI project. You have AI hope. 

At Optura, we’ve learned to redefine the gates to value entirely: 

1. Discovery is not a meeting. It’s a control surface for your data boundaries.
2. Onboarding is not admin. It’s Sprint Zero for your system architecture.
3. Evals are not QA. They are the new operational release gate.
4. Deployment is not the end. It’s simply where the system begins to learn.
5. Pause is not failure. It means a workflow constraint has been exposed – and is ready to be re-engineered.

ROAI lives in how little your build has to wait to start realizing value. The teams that figure that out are going to look like they’re operating on a different clock than everyone else.

The code used to be the hard part. AI made it cheap enough for us to finally see the faults in the rest of the system. Now we know how to fix them.

Request a demo to learn how Optura’s AI helps enterprise leaders accelerate time to ROAI.