Team-level AI spend averages are the management equivalent of checking the mean salary to understand whether everyone is paid fairly. The number is real, but it obscures the distribution — and the distribution is where the actual story is.

If your team of ten developers spends $400/month on AI tools, $40 per developer sounds reasonable. But that average could be hiding two developers at $160 each and eight developers at $10 each. The $10 developers are underusing a tool they have access to. The $160 developers either have legitimate high-output work or are burning tokens inefficiently. Without per-developer data, you cannot tell the difference.

What averages conceal

Three patterns that team-level aggregates routinely hide:

The high-cost, high-output developer. Some developers use significantly more AI than their peers and produce significantly more commits in return. This is the ROI story. Without per-developer data, their output gets averaged away and their cost gets flagged as overspend.

The high-cost, low-output developer. The inverse: heavy token usage, few commits shipped. This is not necessarily bad — they might be working through a genuinely complex problem. But it is worth understanding. Per-developer data surfaces it; team averages bury it.

The non-user. In most teams, a meaningful subset of developers with AI access barely uses it. This is a training and adoption problem, not a usage problem. But you cannot identify it from aggregate data.

The metric that matters per developer

Raw spend per developer is a starting point but not a destination. The number that matters is output per dollar spent:

Commits per dollar — lines merged to the repository divided by AI spend in the same period
Tasks closed per dollar — issues resolved divided by AI spend
Cost per feature — AI spend on a project divided by shipped deliverables

These ratios vary widely by developer and by type of work. A developer doing infrastructure refactoring will have very different numbers than one shipping small feature tickets. The point is not to rank developers against each other — it is to understand what patterns correlate with high-value AI usage so you can replicate them.

Finding your high performers

In almost every team that tracks per-developer AI metrics, a small number of developers have dramatically better output-per-dollar ratios than the rest. These are not always the developers who were already most productive before AI adoption — sometimes they are mid-performers who have found specific workflows that leverage AI unusually well.

Identifying them is the first step. The second is understanding what they are doing differently:

Are they using shorter, more focused sessions?
Are they prompting for specific tasks rather than open-ended exploration?
Are they using a particular model or toolset?
Are they working on a certain type of task where AI has more leverage?

This information is worth more than any vendor claim about average productivity improvements. It is what your team's actual high-ROI AI usage looks like in practice.

Spotting inefficient patterns before they compound

On the other side, per-developer data surfaces inefficient usage patterns that team averages normalize away:

Context window bloat. A developer running very long sessions with large files pasted repeatedly will show high token spend relative to commits. This is often fixable with a workflow change — shorter sessions, more focused prompts — and is invisible at the team level.

Model mismatches. Some developers default to the most expensive model for every task. Opus for a documentation update costs the same as Opus for a complex architectural refactor, but the value delivered is not remotely comparable. Per-developer model-level breakdowns catch this.

Abandoned sessions. Token spend with no corresponding commits in the same period can indicate exploratory sessions that did not produce usable output. Some of this is legitimate; a lot of it is avoidable with better task scoping.

How to use this data without damaging team culture

The risk with per-developer analytics is that it feels like surveillance. The way to avoid this is transparency and framing.

Developers should know the data exists and what it tracks. It tracks cost and output metrics — not prompts, not code quality, not what questions they asked. The goal is to understand where AI is working well and where it is not, not to build a case against individual engineers.

The most effective use of per-developer data is in aggregate patterns: "developers who use shorter, task-scoped sessions are getting 2× the output per dollar of those who use longer open-ended sessions" is a coaching insight, not a performance judgment. That distinction matters.

Tazmin surfaces per-developer AI spend alongside commit and task data so you can see who is getting the most from AI tooling and what patterns are worth spreading across the team. Join the waitlist to get early access.