The Right Way to Think About AI Spending Caps for Software Developers
Editor's Note: I'm experimenting with a slightly different style for this post.
Most of my writing of late has tended to be shorter, more opinionated, and focused on a specific observation or argument, largely around AI in software engineering. This time, I wanted to take a more structured approach and develop a practical framework that engineering and technology leaders can apply when thinking about AI spending and developer productivity.
I'd be interested to hear whether you find this format more or less useful than my usual style.
Developer AI Spending Caps Are Here
Uber’s decision to cap employee AI spending at $1500 per month per agentic coding tool should not surprise anyone who has worked inside a large technology organization. According to TechCrunch, the company introduced the cap after exceeding its AI budget within four months, while still allowing employees to request exceptions when justified. If you work in a large non-Uber technology organization, be advised, these policies are coming for you.
The early phase of enterprise AI adoption has been defined by experimentation, enthusiasm, and a certain amount of (shall we call it?) intentionally loose governance. That was probably appropriate. When a technology appears capable of changing how software engineering gets done at a fundamental level, developers need room to explore. And leaders need to see what is possible before they can decide what is truly valuable and worthwhile.
But that freewheeling phase was never going to last forever.
At some point, AI spending stops being an innovation story and becomes a cost story. It moves from “let’s encourage people to use these tools” to “what are we getting for this level of spend?” That is not a CFO being “anti-AI”. It is normal business discipline like you’re going to find in any company that must report results to shareholders. It’s no different from any other category of enterprise spending.
Obviously companies were eventually going to cap AI spending. The more interesting question is how they should think about those caps.
A flat $1500 per month limit may be a reasonable starting point. From what I’ve heard around the industry, some people will think that’s reasonable, and some will think it’s far too low. More likely, for Uber it is more likely stake in the ground more than a deeply optimized number. Either way, it raises a useful question for every engineering leader:
What’s the right amount to spend on AI tools per developer?
That sounds like a simple budget question. It is not. It is really a question about the economics of software engineering productivity.
The Implied Bet Behind a Spending Cap
A $1500 monthly AI cap equals $18,000 per year. For a U.S.-based software engineer, that is not remotely equivalent to hiring another engineer. It is a fraction of the fully loaded cost of a senior developer, and still well below the cost of even a junior engineer in most U.S. markets.
For context, the U.S. Bureau of Labor Statistics reports a median annual wage of $133,080 for software developers, with even the lowest-paid 10% earning nearly $80,000 annually before fully loading with benefits and overhead.
From that perspective, $18,000 per year per engineer may look easy to justify. If an AI coding tool makes a $150,000 engineer only (say) 12% more productive, the spend appears to pay for itself. If the productivity gain is 20%, 30%, or more, the case looks even stronger.
But that is where the analysis gets difficult.
The phrase “developer productivity” has always been slippery, and as an engineering leader I get uncomfortable when asked to “measure” it. Academic researchers and software organizations have spent decades trying to measure it well, and the results have been mixed at best. Lines of code is the classic example: easy to count, easy to compare, and almost completely misleading. And yet it’s what many organizations fall back to because they have been unable to come up with anything better.
It is the old “streetlight problem”: a foolish person looks for the keys where the light is better, not necessarily where the keys were lost.
Aside: AI introduces a new version of the same problem. Instead of counting lines of code, companies appear to have succumbed to the temptation to measure engineers by “count of tokens consumed”, “prompts submitted”, “agent sessions launched”, “pull requests generated or tasks completed by AI”. These numbers are easy to collect, but they are often poor proxies for value.
Token consumption, in particular, measures usage rather than outcomes. It’s a terrible productivity metric, but it’s perfect to use as a line item on a bill. A spending cap controls the financial downside, but it does not answer the productivity question by itself.
The Human Talent Comparison
Recently we’ve also started to hear industry rumblings about AI being more expensive than human engineers. Let’s unpack that a bit.
The $18,000 annual number for AI spend per engineer becomes more interesting when we compare it to human engineering capacity. In the U.S., $18,000 does not hire a software engineer. It is not close. Even junior developers in U.S. markets typically cost far more than that once salary, payroll taxes, benefits, equipment, management, and overhead are included.
We still live in a globalized world, though, and globally, the comparison becomes less abstract.
In some high-quality international talent markets, especially for junior or early-career roles, $18,000 per year starts to become a meaningful number. Average software engineering compensation in countries such as the Philippines, Brazil, or Poland can be dramatically lower than in the United States, depending on experience level and hiring model.
That does not mean AI spending should be directly compared to offshore hiring. Clearly there are other factors to consider, many of which directly impact (yes) productivity. But as AI spending rises above $18,000 per developer per year — especially if multiple tools, API usage, premium models, and internal platform costs are included — the tradeoff becomes more concrete.
At $30,000, $40,000, or $60,000 per developer per year in AI-related spend, leaders have to ask a different question:
Are we buying marginal productivity for existing engineers, or are we spending enough to consider additional human capacity?
That does not mean “hire people instead of using AI.” That’s overly simplistic. The right comparison is not AI versus engineers. The right comparison is the optimal mix of engineers, AI tools, internal platforms, review capacity, and governance.
A junior engineer and an AI coding agent are not interchangeable. A human engineer can learn the business, participate in design discussions, build judgment, improve systems over time, and take accountability. An AI tool can accelerate certain tasks, explore alternatives, summarize unfamiliar code, draft tests, generate scaffolding and boilerplate, and reduce friction in specific workflows.
Whether AI replaces humans or not is the wrong question. We need to ask where each dollar spent gives us the best ROI.
The Real Sweet Spot Is a Portfolio Problem
The best way to think about AI spending is as an engineering portfolio allocation problem.
Every engineering organization has a finite budget. That budget can be spent on senior engineers, junior engineers, contractors, testers, platform teams, SaaS tools, cloud infrastructure, training, documentation, internal frameworks…and now AI coding tools.
When viewed in that light, AI coding tools need to compete for budget just like every other productivity investment.
That means leaders should not ask only, “Is this AI tool useful?” Many tools are useful. The better questions are:
Does this tool improve the throughput of valuable work?
Does it reduce cycle time without increasing defects?
Does it improve developer flow or simply create more output for reviewers to inspect?
Does it help senior engineers spend more time on architecture and judgment?
Does it help junior engineers learn, or does it allow them to bypass learning they actually need?
Does it create security, compliance, intellectual property, or maintainability risks that offset the apparent gains?
Does the same value require the most expensive model, or would a cheaper model, better documentation, or an internal tool solve the problem?
These questions point to a more mature framework than either unlimited experimentation or blunt-force cost cutting.
A Practical Framework for AI Spending Caps
In my view, a useful AI spending cap should have at least five layers.
1. Establish a default budget, not an entitlement
A default cap gives teams a starting point for what is reasonable without additional justification.
But the cap should not be treated as an entitlement. If the limit is $1500 per month, that does not mean every developer should spend $1500 per month. It means usage up to that level may be acceptable when there is a plausible business reason.
The cultural message matters. The goal should not be to maximize AI consumption. The goal should be to maximize engineering effectiveness while maintaining engineering discipline.
2. Segment usage by role and workflow
This might be hard for some folks to hear, but not all developers should have the same AI budget.
A senior engineer working on a large migration, an infrastructure engineer debugging distributed systems, a frontend developer generating routine UI scaffolding, and a junior engineer learning an unfamiliar codebase may all use AI differently.
The cap should reflect workflow value, not some notion of organizational equality.
Some roles may justify higher usage because they are working on high-leverage areas of the system. Others may need lower default caps with access to higher limits for specific projects.
Similarly, not all AI tasks deserve the same budget. Codebase search, test generation, documentation, refactoring, incident analysis, and agentic implementation work have different cost profiles and risk profiles. Treating them as one category hides the actual economics.
3. Measure outcomes, not usage
Analogous to the streetlight problem and using LOC as a productivity metric, the most dangerous version of AI governance is one that measures what is easy rather than what matters.
Token consumption, prompt counts, agent runs, and generated pull requests are operating metrics. They are useful for cost control and anomaly detection. They are not ROI metrics.
Better measures include cycle time, escaped defects, review burden, deployment frequency, lead time for changes, rework, developer satisfaction, onboarding time, incident recovery time, and the amount of senior engineering time freed from repetitive work.
In fact, you might recognize these metrics because they predate AI altogether. They are classic attempts at measuring software engineering productivity.
As always, even these metrics need care. No single metric captures software productivity. But a balanced set of engineering organizational health and performance indicators is far better than pretending that AI spend or token volume tells the whole story.
4. Require justification for higher limits
Caps should be flexible, but exceptions should teach the organization something.
If a team needs to exceed the default limit, the approval process should not be bureaucratic theater. It should capture the business case:
What work is being accelerated?
Why is AI the right lever?
Why is this model or tool required?
What human review or quality control is in place?
How will the team know whether the additional spend was worth it in retrospect?
This creates a learning loop and makes AI usage subject to accountability. Over time, the company can identify where AI spending is genuinely accretive and where it is simply expensive enthusiasm.
5. Rebalance between AI / humans / platform investment
The most mature organizations will not treat AI spend in isolation. They will compare it against other ways to improve engineering productivity.
Sometimes the answer will be more AI budget.
Sometimes it will be better internal documentation.
Sometimes it will be hiring another junior engineer.
Sometimes it will be assigning a senior engineer to remove a recurring platform bottleneck.
Sometimes it will be reducing AI usage because the organization has discovered that the tools are generating more review burden than value.
The right answer will move over time. AI models will get cheaper or more expensive. Tool pricing will change. Developer workflows and expertise will mature. Teams will learn which use cases are high value and which are distractions.
A spending cap should therefore be revisited regularly. It should be a management control, not a permanent truth.
The Strategic Risk of Getting This Wrong
There are two obvious failure modes on the journey to a more mature framework for AI coding tools spending.
The first is uncontrolled spending. In that world, companies encourage everyone to use AI as much as possible, then discover that usage-based pricing scales faster than expected. The finance department reacts, trust erodes, and the organizational pendulum swings from enthusiasm to restriction.
The second failure mode is overcorrection. Leaders see the bill, impose blunt caps, and accidentally suppress the highest-value use cases. Developers learn that experimentation is risky. Teams stop using AI where it could have helped most. The company saves money in the short term while losing learning velocity.
The goal is to avoid both extremes and find the happy medium.
Contrary to much of the hype, AI coding tools are not magic infinite productivity machines. But they are also not just another software subscription. They are becoming part of the engineering production function. That means they deserve real budget, real governance, and real measurement. (One of the reasons this is such a shock to many organizations is because many core developer tools have been essentially free for a really long time now.)
The companies that handle this well will not be the ones that proudly spend the most on AI. They will be the ones that understand where AI changes the economics of software delivery and where it does not.
Capping Spend Is the Beginning, Not the Final Strategy
Uber’s reported $1,500 monthly cap is a useful signal. It suggests that enterprise AI adoption is entering a more disciplined phase. As engineering leaders, we have to dig in and determine how much AI usage is worth, where it creates measurable leverage, and when additional spending stops producing acceptable ROI.
That is exactly the right conversation for engineering and finance leaders to have.
But the answer will not come from token dashboards alone. And it will not come from pretending that AI tools and human engineers are simply interchangeable.
Indeed, the evidence on AI productivity itself remains nuanced. Some controlled studies have found substantial gain. For example, GitHub research reported developers completing a coding task roughly 56% faster with Copilot assistance. But other studies have found weaker changes in commit-based activity despite positive developer sentiment. The key takeaway is that measuring the impact is harder than measuring usage.
The better framing is this:
AI spend is now part of the software engineering capacity portfolio.
The goal is to find the point where AI tools, human talent, platform investment, and engineering discipline combine to produce the best business outcome
