What AI leverage actually means
Most managers asking this question have noticed the same thing. The team adopted Claude Code, Cursor, or Codex months ago, activity is up and to the right, and nobody can say whether more is shipping. Leverage is the metric that answers that.
Quick Answer
To benchmark AI leverage across an engineering team, measure output per unit of effort: shipped work (merged PRs, closed issues) divided by what it cost to produce (audited human hours, agent runs, token spend). Track that ratio for the whole team against its own history, month over month, rather than ranking developer against developer. Commit counts and diff size belong on neither side of the ratio. An agent can generate a 4,000-line diff in ninety seconds, and a one-line fix can follow an hour of thinking. The rest of this guide covers a precise definition of leverage, the Effort x Leverage quadrant, a step-by-step benchmarking method, and the false readings that make a healthy team look bad.
Leverage is a ratio. The numerator is shipped work: merged PRs and closed issues, work that crossed the line into the product. Drafts, generated code sitting in a branch, and burned tokens do not count. The denominator is total effort: audited human hours (tracked session time, not estimates), agent runs, and the token cost of those runs. Divide one by the other and you get output per unit of effort, the only version of "is AI making us faster" that survives a finance conversation.
Both sides matter equally. A team that ships the same amount while halving its human hours has rising leverage. A team that ships the same amount while its token bill triples has falling leverage, even though a dashboard that only reads git shows nothing changed. In practice this means leverage can move sharply while commit activity looks flat, which is why you have to build the metric from session data rather than repo data alone.
Why commit counts and diff size fail on both sides of the ratio
If your current proxy for team output is commits per week or lines changed, AI agents broke it on both sides at once, as a measure of output and as a measure of effort.
As an output measure, diff size now says almost nothing. An agent scaffolds an entire feature, tests included, in one enormous commit. The diff cannot tell you whether that was a week of shipped value or a plausible first draft that review will shrink by 60 percent. Merged PRs and closed issues are slower signals, but they mean a human accepted the work into the product.
As an effort measure, commit patterns are worse. The old intuition, big diff means big effort, has inverted. The huge diff took ninety seconds of agent time. The one-line concurrency fix took a senior engineer an hour of reading before she touched the keyboard, and that hour was the most valuable engineering of the week. Any benchmark that reads effort from git will systematically reward thrash and penalise thought. Git is a useful cross-check for a leverage benchmark, but it cannot measure how long the work took or how much effort it cost.
The Effort x Leverage quadrant
Once you have the two axes, effort in and leverage out, every stretch of team work lands somewhere on a two-by-two. We built DevClocked around this grid because it turns one ambiguous number into a position you can act on. Plot team-weeks or projects on it, not people.
| High leverage | Low leverage | |
|---|---|---|
| High effort | Compounding: heavy investment, heavy shipping. The team is working hard and the AI stack is multiplying it. Sustainable if the hours are. | Agent thrash: long hours, high token spend, thin shipped output. Agents are generating and regenerating work that never merges. |
| Low effort | Quiet leverage: modest hours, strong output. Often a team that has learned which work to hand agents and which to keep. Study it. | Idle: low input, low output. Sometimes a problem, often just a planning gap, a holiday fortnight, or a waiting-on-dependencies stretch. |
Agent thrash is the quadrant AI created, and the one worth watching. It looks like productivity from every angle a git dashboard can see: constant activity, big diffs, rising AI adoption. The session data tells the real story: six agent runs to land one small PR, context resets burning tokens, an afternoon of prompting that got reverted. You will often see a team drift here in its second or third month of heavy agent use, after the novelty and before the judgement. Catching that drift early is most of the value of benchmarking at all.
The quiet leverage quadrant is the other finding managers miss. A sub-team that ships steadily on moderate hours and cheap agent runs has usually figured out something about task selection that the rest of the org should copy. Without a leverage benchmark, that team just looks unremarkable.
How to benchmark AI leverage across your engineering team
You need a baseline and a cadence, not a measurement programme. Five steps, in order.
- Instrument effort first. Capture real session data: human hours from the editor and terminal, agent runs, token spend per session. Estimated hours or vendor-level adoption stats will not survive step four. Teams that skip this end up with leverage numbers built on guesswork.
- Define output narrowly. Merged PRs and closed issues, counted at merge and close. Resist the urge to add generated lines or commit counts back in. If a class of shipped work does not appear in git at all (incident response, reviews), note it, because it will explain dips later.
- Take a 30-day baseline before you judge anything. One month of the ratio, team-level, no conclusions. The first month exists to learn your team's normal range, not to grade it.
- Track the team against its own baseline, monthly. The benchmark question is "are we getting more shipped per unit of effort than we were in June", not "is Priya above Tom". Different codebases, different task mixes, and different seniority make cross-developer comparison mostly noise, and cross-company comparison entirely noise.
- Investigate movement with sessions, not opinions. When the ratio moves, the follow-up is a look at where effort went: which projects consumed the agent runs, where token spend spiked, which work stalled before merging. The number tells you when to ask. Session data tells you what happened.
One rule sits above all five. Benchmark teams, not individuals, and never wire the number to consequences for a person. An individual leverage leaderboard used punitively is the failure mode of this entire category. It has a predictable ending: engineers optimise the metric within a fortnight, quiet high-leverage work stops being quiet, and the data stops being honest. Individual-level data is useful to the individual, for their own calibration. The moment it becomes a ranking with stakes, the measurement destroys the thing it measures. If you cannot deploy this without someone turning it into a stack rank, do not deploy it.
Reading the number: real signals and false ones
A leverage trend is only useful if you know which movements mean something. Some readings are what they look like. Rising leverage on stable hours means the team is converting AI spend into shipped work more efficiently, and the practices behind it are worth spreading. Falling leverage with rising token spend and flat output is agent thrash, and the fix is usually task selection and prompting habits, not more effort.
Other readings are false alarms, and calling them out in advance is how you keep trust in the metric.
A refactor month looks low-leverage. Weeks of effort, few closed issues, PRs that delete more than they add. The output was real (a codebase agents can now navigate) but the numerator cannot see it yet. Annotate it and expect the payback as higher leverage the following quarter.
Onboarding reads the same way. A new engineer adds hours to the denominator for weeks before adding much to the numerator, so a growing team can show falling leverage while doing everything right. Segment new joiners out of the trend for their first sixty days.
So do hard problems. The week your two best engineers spent on a data-corruption bug produced one merged PR. Any reading that punishes that week has forgotten what engineering is. This is why the number opens conversations and never closes them.
Where DevClocked fits
DevClocked is built for this workflow. It captures sessions from IDEs, terminals, and AI agents (Claude Code, Cursor, Codex CLI), ties human hours, agent runs, and token costs to merged PRs and closed issues, and computes the Leverage Score, output per unit of effort, from that audited record. The team version, which adds shared workspaces, org dashboards, and leverage benchmarking against your own baseline, is the Business tier at $29 per seat per month. There are no screenshots, no keystroke logging, and no file-content capture, only session metadata, which is what makes it deployable without the surveillance conversation. Details on the team setup are at /teams.
It is not the answer for every org. A 200-developer organisation that needs survey programmes, resource allocation, and board-level reporting is better served by DX or Jellyfish today; see the DevClocked vs DX comparison for an honest split. LinearB wins if delivery-pipeline automation is your priority, and Swarmia wins on working agreements and self-serve team health. Those tools are good at what they measure. Their data stops at the repo, the PR, and the vendor admin API, so none of them can build the effort side of the leverage ratio from what happened in the terminal and the agent sessions before anything became a commit. DevClocked wins for teams of roughly 2 to 50 that live in AI agents and want that ground truth.
Related Guides
- How to measure AI coding productivity: the parent guide on measuring what AI-assisted teams ship.
- Measure AI adoption across an engineering team: the adoption metrics that come before leverage.
- How to measure developer productivity: the wider measurement question, without the AI framing.
- Building an engineering manager productivity dashboard: where a leverage trend should live day to day.
- Measuring the ROI of AI coding assistants: turning the leverage ratio into a spend decision.
