A few weeks ago, a group of engineering leaders I trade notes with got into it over a question none of us has a clean answer to: How much should you let an engineer spend on AI?
One SVP at a company of similar size and stage is in calibration mode and capping engineers at $200 per month. Hit the cap, you can self-bump by $100. Hit that, you need your manager. I told the thread our number. $5,000.
That’s a 25x gap between two engineering orgs that look more alike than different. And we’re the boring middle. Uber burned through its entire 2026 AI budget in four months as its AI agent went from 1% of code changes to 8%. Meta stood up an internal token leaderboard, then shut it down when it got weird.
Nobody knows what the right number is. Most leaders are afraid to commit to one in writing.
My Personal Math
I don’t think about AI as replacing engineers. I think about it as an alternative to hiring more of them.
A fully loaded U.S. engineer costs about $250,000 a year, all-in: base, benefits, overhead. Capping AI tooling at $5,000 per engineer per month is $60,000 per year. Across four engineers, that’s $240,000, about the cost of one new hire.
The bet is simple. If AI lifts the output of my four existing engineers, I get four engineers’ worth of additional work for the cost of one. That’s the trade. Every dollar I spend on tokens is a dollar I’d otherwise spend on payroll, recruiting, onboarding, and the year of ramp before a new hire delivers.
The only question is whether the productivity lift is real. We’re seeing it in our own org. If you’re an engineering leader, you already have a strong intuition about whether your team is shipping more this quarter than last. Trust it. Pressure-test it with PRs, story points, whatever metric your team uses. Then put a number on it and track it.
Research Report
FinOps In The AI Era: A Critical Recalibration
What 475 executives told us about AI and cloud efficiency.
Why $5,000 And Not $10,000
The most common pushback I get is: if $5K is working, why not $10K? Wouldn’t that double your outcome?
It doesn’t, and the reason matters. Tokens aren’t the binding constraint. The engineer is. A senior engineer who knows the codebase, knows what good looks like, and catches the model when it’s wrong can put a lot of tokens to work. A junior engineer asking the model to write the whole thing burns money producing slop. The $5,000 cap is what my best engineers can absorb before marginal return falls off a cliff. For most people, the cap doesn’t bind. For the few who push it, it’s enabling.
This is also why I’m skeptical of the leaderboard model. The engineer with the highest token bill isn’t the most productive. Sometimes they’re the ones who haven’t figured out how to use the tools yet.
The Question No One’s Asking: What Did You Get In Return?
Per-engineer AI spend is the easy question. The harder one: What business value are you getting for it?
Most engineering orgs hit a wall here. You can measure tokens. You can measure PRs and bug fixes. Connecting any of that to the cost of serving a customer, shipping a feature, or running the product is harder. A food delivery app needs to know: What’s our cost per order, and is AI moving it? A SaaS company needs to know: What’s our cost to ship a feature customers use?
Most leaders can’t answer. Those who figure it out first will have an advantage over those who don’t. (We built CloudZero to answer this question. The discipline matters whether you use us or not.)
Where This Goes
In six months, I expect the $200-to-$5,000 spread to compress. Either the $200 leaders will discover their teams are starving and raise the cap, or the $5,000 leaders will tighten up after they figure out where the spend is and where it isn’t moving the needle. Spreads like this don’t last.
In the meantime, the leaders running the math now (what an engineer costs, what AI costs, what productivity is moving) are the ones who’ll have an answer when their CFO asks. The rest will get one chosen for them.
FinOps In The AI Era: A Critical Recalibration
What 475 executives told us about AI and cloud efficiency.
