What share of the engineering budget should AI be?

The short version. Hold AI spend against the full cost of an engineer, not against your software budget. At a realistic full cost, even generous AI tooling lands near 3% of what an engineer costs. So the interesting question is not "is 3% too much." It is "does this 3% buy more than 3% more output."

That second question has a real answer, and it varies a lot by team. Most companies cannot answer it. KPMG's Global AI Pulse survey of 2,145 C-suite leaders (June 2026) found only 7% report having established ROI on AI. It also found 42% can only partly see what they are spending. Among leaders who can see their costs clearly, the ROI figure rises to 15%. Among those who cannot, it is 3%. Seeing the costs is not the whole story, but you plainly need it first.

The comparison that does not work: AI as a share of software spend

Cledara's live data hub currently puts AI at 16.9% of total software budget (July 2026). It is a clean, quotable number. It will be in a board deck near you shortly.

It is also the wrong thing to divide by, and the reason is arithmetic. That ratio moves whenever your *non-AI* software spend moves. Merge three overlapping monitoring vendors and your AI share jumps, without a dollar of AI spend changing. Sign a big new CRM contract and your AI share falls, again with no AI decision behind it. The top and the bottom of that fraction are set by committees that never talk to each other.

Worse, it invites the wrong comparison. If a peer company reports 22%, that tells you they buy less other software than you do. It does not tell you their engineers get more out of AI.

Use it as market context. Do not use it as a target.

Comparison one: AI spend against the full cost of an engineer

Here is the arithmetic that changes the conversation.

Take a fully loaded engineer cost of about $110 an hour. That covers salary, benefits, payroll tax, equipment and a share of overhead. At about 173 working hours a month, that is roughly $19,000 per engineer per month.

Now put AI tooling next to it:

• $200/month — the low end of DX's observed range for teams mixing inline and agent tools — is 1.1% of that engineer's cost.
• $600/month — the high end of that same range — is 3.2%.

Even the expensive case is a rounding error against the person using it. That is the number to put in front of a board that is anxious about AI lines growing 40% quarter over quarter. Growing fast, still small, and small against the right thing.

Even at the top of the observed range, AI tooling is about 3% of what an engineer costs. The question is not whether 3% is too much — it is whether that 3% buys more than 3%.

DX's range spans about 3x on its own, from $200 to $600. That width is not a mistake. Different companies, different rules about which token spend counts, different periods. A token is the unit AI vendors bill for, roughly a few characters of text. Treat the range as the edges of one wide spread that describes other teams, not as an answer about you.

Comparison two: spend per engineer against the change in output

The second comparison puts the 3% against what it returns. This is where the honesty has to hold.

DX's AI Efficiency Plateau study (May 2026) covered 400+ companies from November 2024 through February 2026. It found a median gain in pull requests shipped of 7.76%. If that were the whole finding, the math would be easy. Cost 3%, output 8%, obvious yes.

It is not the whole finding. The spread is what matters.

• P10: −3%
• P25: +2%
• P50: +8%
• P75: +17%
• P90: +44%

Those rows are percentiles — a percentile is where you sit if you lined every company up in order. The bottom tenth got slower. The top tenth got much faster. For the median team, 3% for 8% is plausibly a good trade. For the bottom tenth it plausibly is not, at any price. You cannot tell which one you are from a benchmark. You can only tell by counting your own teams.

There is one more wrinkle. DX found 69.7% of developers hit peak time savings within two quarters, and 66.1% of those then saw the savings fall away. Whatever your gain is today, it is not guaranteed to be your gain in a year. Budget for that, and count again.

Pull requests shipped is not output either. It is a stand-in that ignores review load, defect rate and rework — the work that has to be redone. That is part of what the speed cost you. Throughput is how much work gets finished, and a throughput number reported without the costs of going faster is a marketing number. Honest AI ROI modeling covers how to show a range instead.

Budgeting mechanics: bands, not caps

A fixed percentage cap is a poor control, for three reasons.

It is tied to the wrong thing. A cap set as a share of the software budget inherits every unrelated buying decision, as above. A cap set as a share of engineering payroll at least tracks headcount. It still does not track whether the spend is working.

It creates the wrong year-end behavior. Teams under the cap spend up to it. Teams over it get throttled mid-quarter. They usually cut the tools with the least political cover, not the ones with the least value.

It hides the spread. A team sitting on the org-wide average can hold five engineers spending $40 and two spending $900. That average tells you nothing you would act on.

A better control is a per-engineer band with a review trigger. Set an expected range — say $150–$450 per engineer per month — tuned to your own mix of inline and agent tools, not to a benchmark. Then decide what happens at the edges. A team below the band for two months running is an adoption question, or a sign that seats are being paid for and not used. A seat is a paid license for one person. A team above the band gets a review, not an automatic no. Heavy spend on an agent-driven team in the middle of a migration may be exactly right. The trigger buys you a conversation with evidence in it. The cap buys you a spreadsheet argument.

One structural warning. You can cap seats, but token spend floats. Seat licenses are a fixed line you can forecast. Pay-per-use is not. It moves with how people work, which model they pick, and how much text they feed it. A per-engineer band that only governs seats will be quietly broken by the usage bill. The metered traps hiding in AI tool pricing covers how that happens. How to forecast next year's AI budget covers building a range you can defend.

The honest caveats

The $110 an hour figure is an assumption, not a count. Use your own fully loaded rate. In high-cost markets it may be half again as much, which makes AI's share smaller and the argument easier. So do not lean on it without checking.

The DX spread is throughput, not value. A team can sit in the top tenth on pull request count while shipping more defects, more review load and more duplicated code. Throughput reported without the costs of going faster overstates the case.

And nothing here proves cause. Teams that adopt AI hard differ from teams that do not, in ways that also affect throughput. The defensible version compares matched teams inside your own company over time. That is a compared number. It is not your team held against a published benchmark.

Find your recoverable AI spend

Spendassay produces an AI cost report — one page that shows what your AI tools cost and what you get back, team by team. Spend is stated per engineer, not as a share of anything. Model your own band with the cost calculator.

`Start free` → /login?src=blog_ai-share-of-engineering-budget