The shift from encouraging AI adoption to worrying about AI spend happened remarkably fast. In a lot of engineering organizations, the time between “we need to get more people using these tools” and “hold up, what is everyone doing?” was probably measured in weeks, if not days.
Historically, we’ve budgeted engineering organizations largely around headcount. A CTO or VP of Engineering could work with the CFO to decide what the company wanted to deliver, how many people it would take, and what the organization could afford. Once the hiring plan was set, a significant portion of engineering spend was relatively predictable.
AI introduces a very different kind of expense. Individual engineers can now consume meaningful amounts of compute through their everyday work, and with unbounded token consumption, someone could theoretically spend the equivalent of an engineer’s salary in an afternoon. Financial decisions that used to happen largely between engineering and finance leadership are now influenced by thousands of small decisions happening throughout the development process.
The challenge isn’t simply to rein that spending in. Engineering leaders need to figure out what the right amount is and how to make it predictable as AI usage grows.
Start With What the Organization Is Optimizing For
Limiting usage is one way to make spend predictable, but consumption alone tells you very little about value. A high-spending engineer might be producing substantially more valuable work, or they might just be experimenting aggressively. A low-spending engineer might have found an incredibly efficient workflow, or they might be struggling to figure out which tools to use in the first place. You have to understand what’s happening underneath the number before you decide what to optimize.
That context matters because AI ROI isn’t instantaneous. We’re spending money on tools, compute, and experimentation today with the expectation that some of the return will come later through increased productivity, faster delivery, or new capabilities. At the same time, “we’ll eventually get value from this” isn’t much of a financial model. Leaders still need to understand what they’re spending, what they’re getting from it, and how those numbers will change as adoption increases.
Learn From the Distribution, Then Build for Everyone
We learned this firsthand at CircleCI when our AI spend started growing exponentially. The first problem was visibility. The providers themselves don’t give you much insight into what’s driving that spend, and we learned pretty quickly that a “leaderboard” wasn’t particularly useful. Knowing who consumed the most didn’t tell us what they were getting from it.
So we looked at the distribution and talked to engineers at the high, middle, and low ends of consumption.
At the high end, some team members were delivering a huge amount of value and pushing the tools in ways we could learn from. Others were experimenting heavily because they were excited about what was possible, but struggled to get any real returns. Spend alone couldn’t tell us which was which.
The other end was just as interesting. Some engineers weren’t using AI much because they didn’t need it for the work they were doing. Others had been given so many tools and options that we’d inadvertently made adoption harder. Their feedback was essentially, “I’m trying to be successful at my job. Just tell me how to use this.”
And then there were the engineers in the middle. We knew they were productive, they were getting meaningful value from the tools, and they weren’t consuming extraordinary amounts of compute to do it. That became an important signal for us. What were they doing differently? What context were they providing? Which tools were they choosing for which jobs? Where could we turn those practices into defaults for everyone else?
That’s the role I think engineering leadership and platform teams need to play. If someone is getting great results, I don’t want to show up and clamp down on their spending. I want to understand what they’re doing and give them better tools for managing context and consumption. Then I want to take what we learn and build it into the tooling around our repositories and workflows so every engineer doesn’t have to become an expert in models, tokens, prompting, and cost optimization.
We’ve already done versions of this elsewhere. We don’t expect every developer to personally optimize the company’s cloud bill every time they provision infrastructure. We build platforms, defaults, guardrails, and feedback loops that incorporate what we’ve learned about operating those systems effectively. AI usage should evolve in a similar direction.
Predictability Can Matter More Than Magnitude
When an AI bill starts growing, the natural response is to ask how to make it smaller. Sometimes that’s necessary, but from a financial planning perspective, predictability can be just as valuable, if not more valuable, than the absolute size of the expense.
If I can forecast what we’re likely going to spend next quarter and understand how that number changes as usage grows, I can manage around it. If I can also get a rough sense of the ROI, I can make an informed decision about whether increasing that investment makes sense.
The harder situation is one where spend can change dramatically without a clear relationship to output. A usage cap might make the bill more predictable, but our experience taught us that the number alone doesn’t tell you where to draw that line. You need to understand who’s getting value, what they’re doing differently, and which of those practices can be built into the system.
AI adds a new variable to engineering budgets, and we’re still learning how to model it. The goal is to understand what we’re spending, what we’re getting for it, and make those economics predictable without putting that burden on every engineer.
Once you can do that, magnitude becomes a decision rather than a surprise.