AI did not eliminate the engineering bottleneck. It moved it — and most organizations had no plan to catch where it went.

I spent most of my career managing teams responsible for IT cost — first as head of Technical Operations when compute lived in the data center, then leading Platform Engineering and DevOps teams when compute moved to the cloud. In those roles, we tracked hardware, software, and managed services constantly. We also tracked and allocated headcount with the same rigor.

FinOps does not stop at hardware and software. It must include the impact of people on the business — and people are the largest spend most engineering organizations carry. The two big reports released this year — DORA's ROI of AI-Assisted Software Development and Faros's Acceleration Whiplash — are, fundamentally, about what AI is doing to that line item: what each engineer now produces, what their output is worth, and where the cost is now hiding.

Forget the seat license. The story in both reports is simpler. AI projects are not failing because the tools are bad. They are failing because organizations adopted AI without a plan, and the actual cost has simply moved.

DORA Wrote the Framework

DORA's report is most often read as an ROI calculator, but the calculator is not the point. The framework is. DORA names the four things that need to be modeled before an AI rollout: baseline cost, cost driver, scaling assumption, and the nonlinearities that are most likely to bite — the learning curve, the verification tax, the pipeline adaptation. The J-Curve is the “planning tool”. Done correctly, it tells you when to expect productivity to dip, how deep, and when it should recover.

Most organizations never wrote that plan. They signed the procurement contract, activated the seats, and chased the leadership demand for "AI value." Planning would have slowed visible action. So no one planned. The seat license is the line item the bill shows. The plan is the line item nobody wrote.

Faros Measured Where the Bottleneck Went

At the same time of the DORA report, Faros published a report with two years of telemetry from 22,000 developers across 4,000 teams. The throughput numbers are real: tasks completed up 34%, epics up 66%, code-related tasks up 210%. AI is doing what it was designed to do, which is to accelerate the act of writing code.

But the bottleneck did not vanish. It moved. Lead time from commit to production is up 480%. Time in PR review is up 199%. Incidents per PR are up 242%. Code churn, the ratio of lines deleted to lines added, is up 861%. Bugs per developer are up 54%. PRs merged with no review at all are up 31%.

The system was built around human-paced authoring. AI has since flooded it. The friction did not disappear; it was pushed downstream, into review, into incident response, into the senior engineers who now spend their most expensive hours working through AI output.

The Real Story

Without a plan, you cannot tell whether the rollout is working. You see throughput rise, the metric AI tools are designed to move, and the dashboard reports a win (yeah for “Visibility Theater”). The actual cost has shifted somewhere your dashboards do not look. Review queues. Incident response. Senior-engineer attention.

That is why AI projects are not landing the ROI everyone expected. The numerator looks good. The denominator quietly grew somewhere no one was measuring.

Who Owns This

For a FinOps leader, AI is the largest new cost domain to land on the platform since cloud, and it lands without the visibility cloud taught you to expect. The bill shows licenses and tokens. The cost lives in engineering systems FinOps does not typically see. Your job is to help write the plan retroactively, extend visibility past the seat license into where the bottleneck actually moved, and defend the variance against the model. AI is the next cloud, same J-Curve, same hidden multipliers, same demand for unit economics, and FinOps already lived this once.

For an engineering leader, the rollout is your decision whether you authored it or not. When finance asks for ROI variance of before and after, the actuals come from your pipeline telemetry. If you are not instrumenting review time, incidents per PR, lead time, and the percentage of PRs merged without review, you do not have a defense. You have throughput, and throughput is the metric that hides the bottleneck.

The plan is the artifact where the expectations and ROI meet.

The Closing Read

Treat the variance as data, not failure. A J-Curve that takes nine months to bottom out instead of three is not a project that failed; it is a plan that needed a longer tuition assumption. The plan gets sharper because the actuals point to where it was wrong.

Without a plan, AI does not eliminate the bottleneck. It moves it where you are not looking.

Write the plan. Then defend it.

Structural Trend Quick Takeaway

The lead article above argued that AI did not eliminate the engineering bottleneck. It moved it. The practical question for FinOps and Engineering leaders is how to determine whether that shift has already happened inside their own systems, before the impact shows up as unexpected cost or operational drag.

Lead Time Variance is the metric to watch.

Lead Time Variance is the percentage change in commit-to-production lead time before and after AI adoption. Most engineering organizations already track lead time as one of the four DORA metrics. The insight here is not the absolute number. It is how that number has changed as AI-assisted development has been introduced.

On its own, the metric is incomplete. It needs to be paired with throughput to be meaningful. If throughput is increasing while lead time remains stable or improves, then AI is genuinely accelerating delivery. If throughput is increasing while lead time is also increasing, the system is producing more code than it can absorb. In that scenario, the bottleneck has not been removed. It has shifted downstream into review, testing, deployment, or operations.

Before AI, lead time was treated primarily as a delivery metric. It reflected how quickly code moved through the system. In the current environment, it also functions as a cost signal. Any stage after code is written that requires human time and judgment, including code review, QA, incident response, and rework, becomes a potential sink for increased cost when the system falls out of balance.

AI is positioned as a productivity multiplier against engineering labor, which remains the largest cost center for most organizations. The expectation is not necessarily that payroll decreases, but that each dollar of payroll produces more shipped, stable, customer-facing work. When throughput increases but lead time expands significantly, the cost per unit of delivered work can rise even as raw output appears to improve.

License costs and token usage will show up clearly in spend. Lead Time Variance shows whether those costs are translating into effective delivery, or whether they are simply enabling more work to enter a system that cannot process it efficiently. In many cases, organizations are seeing signs that the latter is happening, where gains at the point of code generation are offset by friction further downstream.

This is the central question. AI does not need to reduce total engineering cost to justify its investment. It needs to increase the amount of valuable, production-ready output generated per dollar of that cost. Lead Time Variance is an early indicator of whether that outcome is materializing.

Lead Time Variance can tell you whether the bottleneck has moved. It does not explain why the shift occurred or quantify the exact cost impact. However, those questions cannot be answered if the initial signal is not understood. Without a clear view of how lead time has changed since AI adoption, it is difficult to know whether the constraint still exists where teams are focused, or whether it has already migrated to another part of the system.

If you are not measuring Lead Time Variance today, you are operating without visibility into one of the most important structural shifts introduced by AI-assisted development. Establish the baseline, track the change, and evaluate the relationship between throughput and lead time. From there, adjustments can be made with a clearer understanding of where the system is actually constrained.

Signal: Throughput shows what AI accelerates. Lead time shows where the system breaks.

News or Market Updates for Engineering, IT, or FinOps leaders.

Summary: Hyperscalers shipped real FinOps tooling, while the macro picture sharpened. AI investment keeps climbing, headcount keeps falling, and over half of companies that cut staff for AI now regret it. Why? Embedding AI does not eliminate the work. It moves the bottleneck from code production to review, incident response, and the senior engineers absorbing the downstream load.

If you would like your company included in the Spotlight, contact the CloudXray AI Team

Company: Beakpoint

Category: Cost Intelligence & Visibility

What They Do: The platform uses activity-based costing to connect every dollar of cloud spend to customers, features, and activities, transforming cloud bills into actionable business intelligence.

Why It Matters: Businesses want customer-level margin data

Practical guide for leaders and practitioners

AI did not remove the bottleneck in your system. It moved it. The goal of this playbook is to help you identify where it moved, quantify the impact, and create a repeatable way to manage it. This is not a one-time analysis. It is an operating loop that connects engineering activity to margin.

Step 1: Align Ownership Across Engineering, FinOps, and FP&A

Start by getting engineering leadership, FinOps, and FP&A into the same working session. Each group owns a different part of the system, and without alignment the effort will stall.

The outcome of this step is simple and explicit. Document who owns the data, who owns the cost model, and who owns the financial interpretation. Agree that this is a shared initiative tied to margin, not a reporting exercise. If this alignment does not happen upfront, the work will remain siloed and will not influence decisions.

Step 2: Define What Actually Matters

Before collecting or analyzing data, define what level of change is meaningful enough to act on. Not every shift in a metric should trigger a response.

Work with FP&A to set a threshold for materiality based on your business. A starting point might be a small percentage of gross margin or engineering cost, but it needs to reflect your company’s financial reality. Once defined, treat this threshold as a filter. Anything above it requires explanation and action. Anything below it is tracked but not escalated.

This step prevents the team from reacting to noise and keeps focus on changes that impact the business.

Step 3: Select a Small Set of Metrics That Reflect the Bottleneck

You do not need a large dashboard. You need a focused set of signals that capture where time is being spent after code is written.

A practical starting set includes review time per pull request, incidents per change, code churn, lead time, and the percentage of changes merged without review. If your systems cannot support all of these, choose the closest equivalents. The goal is to measure the parts of the workflow where human effort is still required.

Lock this set for the initial cycle. Changing metrics midstream will make it difficult to compare results.

Step 4: Translate Those Metrics into Dollars

This is where the playbook becomes useful to the business. For each metric, estimate the engineering time involved and multiply it by a fully loaded cost per engineer.

Where possible, separate senior and junior engineering time since the cost difference is meaningful. Review this math with FP&A and get agreement that it reflects how the company thinks about cost. Once aligned, this becomes the shared framework for evaluating impact.

At this point, you are no longer looking at abstract delivery metrics. You are looking at the cost of how work flows through your system.

Step 5: Pull the Data from Systems You Already Use

Most of the data you need already exists in your engineering tools. The work is not building new instrumentation. It is consolidating what you already have into a single view.

Create a shared dashboard that shows both the operational metric and its dollar translation. During the initial rollout, update it weekly to build confidence in the numbers. Over time, you can move to a monthly cadence.

Consistency matters more than precision at this stage. Everyone should be working from the same definitions and the same data.

Step 6: Compare Cost Against Productivity Gains

AI is intended to increase output, so cost increases need to be evaluated in that context.

Measure throughput or completed work and translate it into value using the same financial assumptions. Then compare that value against the cost calculated from your bottleneck metrics. The result is a single view of unit economics.

If the value exceeds the cost, the system is working and the focus shifts to optimization. If the cost outweighs the value, the bottleneck is creating drag and requires intervention.

This step is the core of the playbook. It determines whether AI is improving or degrading margin.

Step 7: Establish a Operating Loop

After the first cycle, turn this into a regular process. On a regular basis (bi-weekly, monthly, quartlery), bring the same group back together to review the data.

Focus on metrics that exceed the materiality threshold. For each one, identify what changed, what action will address it, and which upstream decision contributed to the issue. The goal is to push improvements earlier in the system, not just react at the end.

Over time, this creates a feedback loop where engineering decisions, cost structure, and financial outcomes stay aligned.