> ## Content Index
> Fetch the complete content index at: https://writing.harshsinha.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Engineering Leadership Lessons from Rippling’s Launch of an AI Spend Console
- URL: https://writing.harshsinha.com/engineering-leadership-lessons-from-ripplings-launch-of-an-ai-spend-console/
- Published: 2026-08-27T12:30:22.000Z
- Updated: 2026-08-27T12:30:22.000Z
- Author: Harsh S
- Tags: Hiring and Teams, Artificial Intelligence

The Hiring Plan Has a Second Number Now

Rippling's finance team projected the company was on track to spend forty percent of its R&D headcount budget on AI tokens, according to Rippling's own account in the [AI Spend Console](https://www.rippling.com/blog/introducing-ai-spend-console?ref=writing.harshsinha.com) write-up. Left alone, that share was headed toward ninety percent within the year. One engineer alone was burning fifty thousand dollars a month.

It's tempting to read this as an ordinary story about software sprawl: a company oversubscribed to a new tool, got the bill, reined it in. That reading misses what's actually different here. Per-seat software pricing is built around a simple assumption: it costs roughly the same whether the employee uses the tool constantly or barely opens it. That's not a universal law of SaaS, but it's how most seat-based pricing works, and it's why a finance team can budget headcount tools without checking usage logs every month. Inference billing breaks that assumption. What actually varies now isn't just who you hired. It's that hire plus however much compute they draw on in a given month, and a fifty-thousand-dollar month is what happens when nobody is watching that second number.

This is a story about knowledge work you can see the output of, mainly software engineering, and I'm not stretching it further than that. Inside that scope, AI agents let one person direct a lot more work than before, and at Rippling, at least, that work carried a real per-use cost that depended on which model got called and how often. Route a routine request to a frontier model that a cheaper model could have handled, and you can pay many times more for comparable output. The FinOps Foundation's [guidance on optimizing generative AI usage](https://www.finops.org/wg/optimizing-genai-usage/?ref=writing.harshsinha.com) argues for the same fix: match each request to the cheapest model that can do the job, instead of defaulting everything to the most capable one.

Rippling reports having done something close to that: spend caps, routing rules, a dashboard showing who spent what. By the company's own account, projected spend fell from roughly forty percent of headcount budget to roughly fifteen percent, while overall AI use held steady. Rippling doesn't attribute the drop to one cause, and I won't either. Caps that force cheaper models by default, and routing that stops sending simple requests to frontier models, are the likeliest levers, but the write-up doesn't isolate which did more work, and claiming otherwise would be borrowing precision the source doesn't offer. If I were building this, I'd expect the caps to do the emergency braking (nobody hits a fifty-thousand-dollar month with a hard ceiling in place) and the routing rules to do the slower, compounding work of keeping the average request cheap. That's a reasonable guess about mechanism, not something Rippling confirmed.

Now the trend is running the other way. Prices per token, for comparable model quality, keep falling, a pattern [tracked across major providers over the past two years](https://a16z.com/llmflation-llm-inference-cost/?ref=writing.harshsinha.com). That's real, and it doesn't shrink the management problem; it changes its shape. When something gets cheaper per unit, people use more of it. That's ordinary demand behavior, not a Rippling data point, but it's a reasonable bet for why a total AI bill can keep climbing even while the price per call keeps dropping.

Rippling's write-up suggests the caps and routing were addressable within months once someone built the visibility to see the problem. The harder problem shows up in one line of the same writeup: a dashboard flagging engineers with high AI spend whose coworkers keep sending their code back in review. That's not a cost question anymore; it's an attempt to say whether the money was worth it, and the token count won't answer it. Getting sent back in review is a signal of possible wasted effort, nothing more. Picture two engineers who both trigger that flag: one burned compute generating throwaway attempts at a genuinely hard migration, the other burned it iterating on a routine ticket because the first three prompts didn't land. Same signal, opposite story. The dashboard can't tell those two apart. A human has to read the diffs.

There's a real objection here, worth taking straight: turning dollars spent into a verdict on one person's output takes someone to define what "good" looks like, someone to review it, someone to settle the arguments that follow. For work that's built by a group, or that only pays off months later, I'd argue that effort risks costing more than it teaches you, though that's my inference, not something Rippling tested. That argues against building a productivity score for every job in the company. It doesn't argue against Rippling's narrower case, because code review already happens; it's a byproduct of normal engineering work, not a new measurement system built for this purpose. Reading it correctly still takes judgment. Whoever built that dashboard still has to sit with the diffs, not the dollar figure, to know what the rework actually means.

The narrower, mechanical fix is the one worth taking at face value: use detailed usage data to route requests and cap spend, and save people-level scoring for the small number of roles where the output is cheap to evaluate honestly.

The planning question is where I'll go further than what Rippling reported. Rippling's write-up doesn't say whether the company has merged its hiring plan and its AI budget into one process, only that the AI budget surprised the finance team enough to need its own console. My own conclusion, not theirs: whatever conversation currently produces next quarter's headcount plan should include compute in the same breath. Weigh one hire's fully loaded cost plus their expected compute draw, and what that combination can produce, against the same two numbers for a different hire, or for expanding an existing engineer's compute allowance instead of adding a seat. A bigger compute allowance doesn't replace a second hire. But the value of adding capacity now runs through two numbers instead of one, and a headcount plan that only counts the first number is measuring the wrong unit.