How do you attribute AI spend to engineering output?

Attribute AI spend the way you already attribute payroll: to the team that owns the work, then to what that team merged. Add AI cost to people cost for each team, divide by merged pull requests, and watch the trend against the team's own history. When a team's cost per merged PR moves the wrong way, the manager who knows the work explains why. Attribution is the step most teams skip when finance asks whether their AI coding investment is paying off, and it's what turns AI in software development from an open-ended experiment into a budget line you can defend.

Token spend measures input, and the CFO is asking about output. A bill that doubled tells you usage grew. It can't tell you whether the extra usage shipped more work, reworked the same work twice, or ran an agent on a side quest nobody asked for. Attribution starts when spend is tied to an owner and to merged changes.

AI coding bills arrive in two shapes. Seats are flat per person and hide how differently people use them. Metered usage, in tokens or agent time, shows the variation but carries no context: no project, no team, no pull request. Neither shape answers "what did we get for it" until you join it to the work.

Which outcomes count as a return is its own question, and the parent page answers it. This page takes the outcome as merged pull requests and covers the mechanics: where the cost goes, and who explains it.

Attribute it to the team and its accountable owner, not to the individual pull request. Cost per PR swings with task size and is too noisy to act on one PR at a time. A team's blended cost per merged PR, read monthly against its own baseline, is stable enough to trust and specific enough to start a conversation.

Blended means both halves of the bill: the team's loaded people cost plus every AI line that maps to it. Leaving people cost out makes AI look expensive. Leaving AI cost out hides it.

Merged, not opened. An agent that opens pull requests nobody merges adds cost and no output, so counting only merged PRs keeps wasted runs inside the number instead of flattering it.

Map every AI bill line to a team, add that team's people cost for the same month, and divide by the PRs it merged. Plot each team against its own trailing months rather than against other teams. The view is ready when every usage key and agent account has a named owner, because unowned spend can't be attributed.

1. Map each AI bill line to a team. Seats map through your identity provider. Usage keys and agent accounts need an owner tag first; without one they sit in an unattributed bucket, and that bucket's size is your first finding.
2. Add the team's loaded people cost for the same calendar month as the bill.
3. Count merged pull requests per team from git, with AI-assisted and agent-authored PRs tagged so you can split the number later.
4. Divide, then plot each team against its own trailing months. A rising line is a question. A falling line means the same spend is paying for more merged work.
5. Send the outliers to their managers first, with the numbers, before the view goes to finance.

Step 3 is where most homegrown versions break, because self-reported tags drift. LinearB, the engineering productivity platform, correlates AI activity with git commits and pull requests across 50+ AI tools, with no local installation required, so the tagging comes from the work itself.

The manager who already knows what the team is working on. A spend report says where cost moved. It can't say whether the work behind it was a hard migration, an experiment the team agreed to, or waste. Treat the review like a performance conversation: held early, with the numbers in hand, and aimed at the team's plan.

At Together AI, Dan Fu's team keeps DRIs on every key project and reviews AI spend against the same picture managers use at review time: who owns what, and what shipped.

"you bring it to the managers who, who knows who's doing what, um, and who's tracking kind of, kind of the impact, the same way that you do at a perf review cycle."
— Dan Fu, VP of Kernels at Together AI, on Dev Interrupted, Bet on research, not on vibes

Most of the time, Fu says, spend and impact match. The case the review exists to catch is the person who seemed quiet and turns out to be spending heavily on AI with little to show for it. High performers, in his experience, tend to be calibrated.

The headcount question becomes a headcount-plus-spend question. Agent work still needs a named owner, because an agent can't explain its own cost. Give every agent account and usage key a human DRI, and its spend lands on that owner's team like any other cost, with its merged PRs counted the same way.

"now it's 1,000 people plus the AI spend"
— Dan Fu, VP of Kernels at Together AI, on Dev Interrupted, Bet on research, not on vibes

Unit cost against a human baseline is the version of this a finance team reads fastest. Apiiro prices its automated vulnerability fixes against what the same fix costs a person in triage, fix and test hours:

"You calculate that, and you get to, on average, $78 for a vulnerability."
— Idan Plotnik, co-founder and CEO at Apiiro, on Dev Interrupted, Stop pretending you read every line of code (read the recap)

Engineering teams can run the same comparison on work they repeat, like dependency upgrades or test backfills, where one merged PR is close to a like-for-like unit whether a person or an agent wrote it.

It misleads when the unit changes underneath it. Teams on migrations, incident work or greenfield builds produce very different pull requests, so comparing cost per PR across teams rewards easy work. Rework hides in the count too: a PR that fixes an earlier AI-generated PR shows up as fresh output.

• Cross-team rankings. Compare each team with its own history. A platform team and a product team will never share a healthy number.
• Rework. Track how many merged PRs revert or patch recent ones, and read cost per merged PR beside it.
• Shared keys. One API key used by three teams can't be attributed. Split it before you report on it.
• Billing calendars. Usage billed in arrears lands a month late. Align the bill to the month the work merged, or say which month you used.
• Precision theater. A per-PR dollar figure to the cent invites arguments about one PR. Decisions come from the team trend.

Should we attribute AI cost to individual developers?

Not for decisions. Individual figures go to the person's manager as input to a conversation, the way Fu describes, and stop there. Reporting them upward turns a cost question into a ranking and teaches people to spend less instead of ship more.

Which AI coding tool gives the best return?

That comparison needs the same outcome measures run per tool, and it gets its own page in this tree. Until it's live, the parent page covers what counts as a return across tools.

How often should we review cost per merged PR?

Monthly with the managers, quarterly with finance. Monthly is frequent enough to catch an agent running unattended and slow enough that one large PR doesn't swing the line.