Rethinking Performance

Once an agent can emit thousands of lines on command, output metrics measure the wrong thing -- and pull-request and code volume only inflate with AI. Performance has to be re-anchored on outcomes and leverage: problems solved, quality shipped, and how much a person improves the shared system (context, harness, evals) and lifts the team -- not the volume of code produced.

The Pattern

"AI has severed the link between effort and output." -- LeadDev (source)

Once an agent can emit thousands of lines on command, output metrics measure the wrong thing -- and individual performance is where this bites hardest. "Lines of code" was always a poor proxy; pull-request and commit volume is now actively misleading, ballooning with agents while saying nothing about whether the work was good -- as Nicole Forsgren puts it, "PRs and diffs are good signals and are terrible signals" (Forsgren). The reframe is to judge a person on outcomes and leverage -- problems solved, quality shipped, and how much they lift the whole system -- not the volume they emit.

Why It Matters

Teams that keep measuring code output reward the part that no longer matters. A Stanford study of ~100,000 developers found AI raises measured productivity ~15-20%, but gross output looks far higher because much of the new volume is rework -- bug fixes to code the agent just wrote (Denisov-Blanch, Stanford). Counting commits rewards exactly that churn.

Early in an AI rollout it is tempting -- and reasonable -- to measure adoption: are people actually using AI in their day-to-day work? That is a fine first indicator that the change is landing, but it is still only activity -- it says nothing about whether the shared context and tooling are being reused and improved across the org. Once adoption is real, shift the lens from are they using it to what are they contributing. For an individual or a team, the signals worth reading are different:

• Outcomes, not activity. Did the work hold up, was it understood, did it move the result?
• System leverage -- the force multiplier. How much does the person improve the shared system that lifts everyone? This one is even countable: how much do they contribute to the context and tooling repos (the AGENTS.md, the rules, the harness, the evals), and how much do they improve the system itself -- educating both colleagues and the agents to do better? The modern "10x engineer" "masters context and amplifies team impact rather than focusing on raw output" (InfoWorld).
• Prevention, not just production. What did they stop from shipping -- the bug caught, the bad design blocked, the slop kept out at review? As coding stops being the bottleneck and review becomes it, much of an engineer's value is what they prevent -- which no output count can see, because you cannot measure the incident that never happened.
• Intervention rate. How often does a human have to step in and correct the agent? A falling number of manual corrections -- and shrinking review time -- is the mark of someone who specifies intent precisely and builds the guardrails that let the agent get it right the first time. Unlike code volume, it rewards the right behaviour: sharper intent and less rework, not more output.
• Multiplayer, not solo. Solo throughput is the easiest thing to inflate and the least valuable. Credit the shared work -- improving the org's AI delivery pipeline and making agents work together (integration), not just running your own loop.

No single number captures this, and asking people is unreliable too: in a METR trial, experienced developers believed AI sped them up ~20% while they were measured ~19% slower on their own codebases (METR). The realistic answer is a small constellation of signals read in context -- judgment and contribution are genuinely harder to count than throughput, which is exactly why rewarding throughput in an age of cheap throughput is the wrong default. This is the measurement counterpart to hiring: both move from counting code to judging contribution.

Last reviewed: 2026-06-26