---
title: "The Next AI Budget Should Fund the Bottleneck"
url: "https://florea.xyz/ai-budget-bottleneck/"
date: "2026-11-12T09:00:00+02:00"
updated: "2026-11-12T09:00:00+02:00"
author: "Bogdan Florea"
topic: "Leadership"
---

# The Next AI Budget Should Fund the Bottleneck

Before I'd approve a bigger AI budget, I want one question answered: what's stopping a customer from getting value sooner?

Sometimes the answer is building. The team understands the problem, agrees on the fix, and needs help building it. Better coding tools can be a good investment there.

Often, though, the work is waiting. It waits for a decision, a review, a test environment that works, or permission to release. Producing code faster in that situation only makes the queue longer.

The budget should follow that distinction. Fund the bottleneck: the one step that limits how quickly useful, reliable changes reach people. Speeding up any other step won't get finished work to customers any sooner.

**TL;DR**

- Put the next AI budget where work actually waits, not where a speedup is easiest to show.
- Measure from an agreed need to a working change, and count the full cost, including review and rework.
- Treat AI usage as an adoption signal, never as a personal productivity score.
- Tie each new commitment to a named constraint, a review date and the evidence needed to continue.

## Faster tasks can coexist with slower decisions

Atlassian's [October 2026 developer experience research](https://www.atlassian.com/blog/development/developer-experience-report-2026) shows the tension well: 87% of developers say AI helps them ship work faster, while 72% say they face the same or more friction than before AI. Friction is whatever slows the work down around the code, and in that report the biggest source is still finding information. These numbers describe how developers feel, not measured output, but they point at the right place to look.

That place is the whole path from an agreed need to a useful change: deciding what matters, understanding the existing system, making the change, checking it, releasing it, and finding out whether it helped. Coding tools help with several of those steps. They can't settle a product decision nobody has made.

So you need to know where work actually waits. Otherwise the most visible improvement wins the next budget, and the expensive delay stays where it was.

## Start with a real piece of work

My test is simple. Pick a small sample of recent changes and follow each one from the moment the organization committed to solving the problem, through production, to the result for the customer or the business.

Track waiting as well as effort. One change might take an hour to build and then sit for days while someone clarifies what it should do. Another might move smoothly until someone has to check a risky interaction with an older system.

Ask the people doing the work what keeps stopping them, then check their answer against what actually happened to those changes. The goal is to find the constraint precisely enough to choose something that would remove it.

Then write down a baseline: how long those changes took, how much rework they needed, and what broke. Without it, a fast demo, a higher pull request count or an enthusiastic internal presentation becomes the evidence for the next budget increase.

## Two teams can justify different investments

Take two hypothetical teams looking at the same coding tool.

Team A has clear requirements, good automated tests, quick reviews and a simple release process. Its developers spend most of their time building changes everyone already understands. A stronger coding agent, better context about the codebase, or training on how to use it well could get more useful work shipped. I'd fund that experiment.

Team B already produces changes quickly, but its review queue keeps growing. Reviewers spend much of their time working out what a change was meant to do and checking behavior by hand that the tests don't cover.

For Team B, I'd look first at smaller changes, clearer acceptance criteria (a short, agreed description of what "done" means for a change) and better automated checks. It might also need more review capacity. Another code generation tool would have to show exactly how it reduces that review burden.

The same tool can be a good investment for one team and a weak next step for another. Its value depends on the constraint it removes.

## Use a small scorecard

What you measure should follow what the investment is for. Use five categories and pick one or two measures in each.

| Category | What to look for |
| --- | --- |
| Customer or operational result | A shorter onboarding process, less manual work, fewer support requests, or a defined reduction in risk. |
| Delivery time | Time from an agreed need to a usable change, including time spent waiting. |
| Rework | Review effort, corrections, and work reopened because the change didn't do what it was meant to do. |
| Reliability | Failures introduced, effort to recover, and whether the team can roll back a bad release. |
| Full workflow cost | Engineering time, AI usage, infrastructure, review, corrections and operational support. |

Maintenance and security count too. A safer dependency upgrade or a more reliable recovery process creates value without shipping a new feature. Decide what that value looks like before you judge the investment.

Cost needs the same care. EY's [September analysis of AI-assisted development](https://www.ey.com/en_us/insights/technology/hidden-costs-in-ai-assisted-development) treats the cost as the sum of several moving parts: retrieved code and documents, model calls, generated output, retries and repair loops, verification steps and parallel agent activity. A subscription invoice shows only part of that.

Use these numbers to improve the system, not to grade people. Turn them into individual quotas and people will optimize the number instead of the work.

## Separate adoption from success

Adoption data is useful. It shows who lacks access, where people need training, and which approved tools people actually find helpful. That's what it's for.

It's a poor productivity target for individuals.

Adaptavist's [New Developer Realities report](https://www.adaptavist.com/reports/new-developer-realities) asked 1,000 engineers in Europe and North America about AI at work, and 47% said they're assessed on how much they use AI rather than on the quality of their work. That's what developers report, not a measure of business performance, but it describes an incentive I wouldn't want to create.

A developer who solves a problem simply shouldn't need to burn more tokens for the work to count. A hard investigation may justify heavy AI use. Both should be judged by what they achieved.

## Make the next commitment conditional

For each delivery investment, agree on five things up front: the constraint, what you'll change to remove it, the budget, a review date, and the evidence needed to continue. At the review, expand it, adjust it or stop it based on what changed.

Leave room for uncomfortable answers. A tool can be useful while the way it was rolled out needs a redesign. A trial can remove one constraint and expose the next. A promising approach may need more evidence before wider use.

I'd also keep a separate discovery budget, meaning money set aside to learn about capabilities whose value is still unclear. Label it as exploration, cap it, and ask what was learned. Forcing every experiment to invent an immediate return makes the decision worse, not better.

## Before the next budget meeting

Here's where I'd start:

- Trace a handful of recent changes and note where each one waited, and for how long.
- Name the biggest wait and write down today's numbers for it.
- Require every request for new AI spending to say which constraint it removes, what improvement matters, how you'll recognize it, and when you'll check.
- Use adoption numbers to help people get more from the tools, and keep them out of performance reviews.

A request that can't answer those questions isn't ready yet. That's the bar I'd set before making the budget bigger.