How to measure the ROI of AI coding spend

AI coding spend is going through the roof. Teams that spent a few hundred dollars a month on Claude Code last year are spending thousands now, and tokenmaxxing has turned into an actual strategy. More agents, more context, more parallel runs, more tokens. The whole bet is that the output is worth what you are pouring in.

Here is the problem. Almost nobody can tell you whether it actually is. Of all the money going into Claude Code, how much of it turned into code that shipped?

You can get your spend to the dollar. Every tool will show you that. Spend by model, spend by engineer, spend over time, spend on a nice chart. What none of them tells you is the one thing worth knowing, which is whether any of it is working.

That gap is the whole reason we built this, so let us make the argument plainly.

Token spend is an input. Counting it tells you what you poured in. It tells you nothing about what came out.

We have made this mistake before as an industry. We judged engineers by lines of code. We judged teams by hours logged. Every time, we picked the thing that was easy to count over the thing that mattered, and every time it just taught people to game the easy number. Tracking token spend on its own is the same move with a new coat of paint. It feels like measurement. It isn’t.

If you want to talk about ROI, and ROI is the right frame for this, then spend is only the denominator. You cannot compute a return with half the equation. You need the numerator. You need to know what the spend produced.

So that is the metric we built this around. We call it yield.

AI coding yield is the share of your spend that turns into shipped code.

That’s it. Out of every dollar spent with an AI coding tool, how much ended up in something that merged and shipped, and how much went nowhere?

When you start measuring that, the picture gets uncomfortable fast. A real share of AI coding spend never ties to a single merged PR. Not because anyone is slacking. Sessions get abandoned. Branches die. People try three approaches and ship one. That is normal and healthy. But until you can see it, you cannot tell the difference between healthy exploration and money quietly leaking out the side.

The way we measure it is boring, which is how we like it. We capture each Claude Code session as metadata, connect to your repos through a GitHub App, and match the spend to the pull request it actually went into. From there every dollar lands in one of three states. It shipped, in a merged PR. It is in flight, in an open PR or recent work. Or it never tied to a PR at all.

That last bucket is the one that changes how people think. It is the spend with nothing to show for it, sitting in plain sight where you can finally do something about it.

Now, we will be the first to say a merged PR is not a perfect measure of value. People merge things that get reverted. People ship small. A PR is a proxy. But it is the first proxy that is objective, available, and hard to fudge, which is exactly why we started there. Output is bigger than pull requests, and over time we will measure more of it. Issues closed. Incidents resolved. Features that actually reach users. PRs are step one, not the finish line. We start with GitHub because that is where the clearest signal lives today.

Here is what surprised us about measuring yield. We expected a cost-cutting tool, and it turned out to be almost the opposite. Once you can see which kinds of work turn spend into shipped code, the move is not to spend less. It is to spend more, on purpose, where the return is obviously there, and go fix the places where it is not. You stop arguing about whether AI coding is worth it in the abstract and start managing it like any other investment, by the return.

That is the whole philosophy. Stop measuring the input. Measure what it produced. Token spend tells you what AI coding cost you. Yield tells you what it was worth.