Performance Reviews When Agents Do the Typing

TL;DR: Commit volume, PR count, and lines shipped used to be rough but honest proxies for how much an engineer contributed. Agents broke that proxy — anyone on the team can now generate a wall of commits in an afternoon, and the number tells you nothing about whether the work was any good. Search “how to measure engineer performance with AI agents” and every result on page one is a metrics dashboard pitching you a new number to replace the old broken one. That’s the wrong direction. The fix isn’t a better dashboard — it’s a better conversation. What I actually evaluate now: the calls an engineer makes about what not to let the agent do, the quality of their review on work they didn’t type, which problems they chose to spend agent time on, whether they verify before they ship, and how they behave when the agent quietly breaks something. None of that shows up on a chart. All of it shows up in twenty minutes of the right questions.

The metrics stopped meaning anything

I ran engineering reviews for a decade before any of this, and the informal signal always leaked in through the numbers, even when nobody said the number was the metric. You’d glance at someone’s commit graph, their PR count for the quarter, roughly how much surface area they’d touched. It was a bad proxy even then — a quiet engineer who spent three weeks on one gnarly migration could look worse than someone shipping ten small tickets. But it was a directionally honest bad proxy. More commits generally meant more hours of actual human typing, thinking, and testing behind them.

That correlation is gone. I wrote about this directly from the inside — in six months of running an AI-agent-heavy workflow on one project, I logged 4,154 commits, more than my previous four years combined. The commits are real, they compile, they run in production. But the number stopped being a proxy for effort the moment I stopped typing most of the code myself. Anyone on your team who’s decent at prompting an agent can produce that graph now. It costs an afternoon, not a career.

It’s not just anecdotal. GitClear’s 2026 analysis of AI-era code changes found refactoring — the “moved” code that signals someone actually restructured a design instead of bolting on more of it — fell from 13% of changed lines in 2023 to 3.8% year-to-date in 2026, while copy-pasted code climbed from 9.4% in 2022 to 15.7% in the first half of 2026, and two-week code churn (code revised almost immediately after it was written) rose another 15% (GitClear, 2026). Volume is up. The signal that volume used to carry — sustained, deliberate design work — is down. If you’re still grading on output, you’re grading the wrong axis, and you’re rewarding exactly the pattern the data says is getting worse.

What review actually costs now

The place the inflated-output problem shows up hardest isn’t the person writing the code — it’s everyone downstream of it. The 2026 AI Engineering Report found that under high AI adoption, median time to first PR review is up 156.6%, average time spent in review is up 199.6%, average PR size is up 51.3%, and bugs found per PR are up 54% (Faros AI, 2026). Read that as a system, not a set of stats: the volume of code needing scrutiny went up, the time available to scrutinize it didn’t, and the defect rate went up too. Somewhere in your org, a senior engineer is absorbing all three of those numbers at once, and it’s not visible on any dashboard that just counts commits.

That’s the actual shift a performance review has to account for. The engineer who “shipped the most” this quarter might be the one who generated the most PR volume for someone else to clean up. I’ve seen this pattern enough now to trust it as a category, not a one-off: agent-assisted code is stylistically clean — consistent formatting, sensible variable names, idiomatic-looking structure — which is exactly why it’s harder to review. The old tell for “something’s off here” was ugly code. Ugly code doesn’t happen anymore. The bugs hide behind good formatting now, which means the reviewer has to actually understand the logic, every time, because the visual shortcut is gone.

If your review criteria still rewards raw throughput, you are structurally rewarding the person generating the most review debt for the rest of the team. That’s the opposite of what a performance review is supposed to select for.

What to evaluate instead

Once commit count, PR count, and lines shipped are off the table, here’s what’s left — and it turns out to be a better read on an engineer than the old metrics ever were, because it was always what those metrics were a weak proxy for.

What they told the agent not to do. This is the single highest-signal thing I look for now. Anyone can prompt an agent to generate a feature. The engineers worth promoting are the ones who can tell you, specifically, where they stopped the agent — the shortcut it wanted to take on error handling, the migration it wanted to run without a rollback path, the test it wanted to skip because the assertion was inconvenient to write. That’s judgment. It doesn’t show up in a diff. It shows up in what’s not in the diff, and the only way to see it is to ask.

Review quality on work they didn’t type. Since agent-written code passes the “does it look clean” test by default, the engineer’s real contribution shifts to whether they caught the thing that looked fine and wasn’t. I look at their review comments on agent-authored PRs the same way I used to look at their own code: are the comments specific and load-bearing, or are they rubber-stamp approvals because the diff was tidy and the tests were green?

Problem selection. When typing is nearly free, the constraint moves entirely to which problem gets the agent’s time. An engineer who points three agents at three well-scoped, well-understood problems and ships all three cleanly is doing more real work than one who points an agent at something ambiguous and gets a plausible-looking wrong answer back. Picking the right problem to delegate — and recognizing which ones shouldn’t be delegated at all — is now a core skill, not a nice-to-have.

Verification discipline. Did they run it, read the output, and check the edge case before merging — or did they trust that green CI meant correct? The failure patterns I catch from agents every week are rarely subtle once you look — confidently wrong answers, silently dropped context, a test that passes because it tests the wrong thing. The engineers I trust with more scope are the ones who assume the agent is capable of exactly those failures and verify accordingly, every time, not just when something feels off.

How they handle agent failure. Everyone’s agent breaks something eventually. What I actually watch for is what happens next: do they own it immediately and walk through what they should have caught, or do they reach for “the agent did it” as a shield? Owning the whole outcome — the failure, the fix, the postmortem — was always the definition of professionalism I cared about. An agent in the loop doesn’t change whose name is on the outcome. It’s still theirs.

Promotion criteria: seniority is what you can safely delegate

The old ladder measured seniority mostly by scope: how big a system you could own, how much ambiguity you could resolve alone, how many people’s work you could unblock. Those axes still matter, but a new one has become the load-bearing one — how much you can hand to an agent and still stand fully behind the result.

That’s a real skill with a real failure mode on both sides. Under-delegate — insist on typing everything yourself because you don’t trust the agent — and you’re slower than peers who’ve built the judgment to delegate safely, without actually being more careful in any way that matters. Over-delegate — hand off scope you can’t verify — and you’re the person whose name is on an outage nobody can explain, because you can’t explain the code either. I wrote about the version of this that hits earlier in the pipeline, at the junior level, where the traditional path to senior ran through grunt work an agent now does in one prompt — juniors are losing the reps that used to teach this exact judgment before they’re old enough to need it. The senior review conversation is the adult version of the same question: not “how much did you produce,” but “how far out can you extend your judgment through a tool and still be right.”

Promotion packets should read differently now. Instead of “shipped X features, closed Y tickets,” I want to see: the scope of decision this person can delegate to an agent unsupervised, the size of system they can review agent output on without a second reviewer, and at least one specific example of them stopping an agent from doing something that would have shipped a real defect. That last one is the tell I trust most, because it can’t be manufactured by volume. You either caught something or you didn’t.

The 1:1 script

Here’s what I actually ask, in the room, instead of pulling up a dashboard. None of these have a single right answer — the answer isn’t the point, the specificity of the answer is.

• “Walk me through a diff you rejected or heavily rewrote this quarter. What was wrong with what the agent gave you, and how did you catch it?”
• “Tell me about a time you told an agent not to do something it wanted to do. What was the shortcut, and why did you stop it?”
• “What’s a bug an agent introduced that made it past your own review? Where did your process fail, and what did you change?”
• “Pick a PR you approved that you didn’t write. Defend the logic to me like it’s yours, right now.”
• “What’s something you deliberately did not delegate to an agent this quarter, and why?”

If someone can’t answer the first two with a specific instance — not a hypothetical, an actual diff or an actual moment — that’s the finding. It doesn’t mean they’re not contributing. It might mean they’re rubber-stamping agent output and haven’t been caught yet, which is a much bigger flag than a light quarter of commits ever was.

Don’t let a dashboard have this conversation for you

I get why the metrics-dashboard category exists and why it’s selling well right now — DORA-style delivery metrics, time-allocation breakdowns, agent-usage telemetry. Some of that data is genuinely useful as an input. None of it is a substitute for the conversation above, and the risk I’d flag to any manager evaluating one of these tools is treating the dashboard as the review instead of as one data point feeding into it.

A dashboard can tell you PR throughput went up. It cannot tell you whether the throughput came from good problem selection or from an engineer letting an agent run wild and hoping review catches it. It can tell you review time went up. It cannot tell you whether that’s because the reviewer is being appropriately careful or because the code genuinely got harder to understand. The judgment questions above are cheap — twenty minutes, no tooling budget — and they get you closer to the actual signal than a subscription will. If you’ve bought the dashboard, keep it as a second opinion. Don’t let it replace the conversation you’re supposed to be having anyway.

This is the same operating-system shift I’ve written about more broadly: whether the teammate typing the code is a person or an agent, the system that has to hold is trust — clear ownership, outcomes over hours, and a manager who actually knows what “good” looks like from either. Reviews are just where that system gets tested out loud, once a quarter, in front of the person it’s about.

Where to start

If your review cycle is coming up and your rubric still leans on commit count, PR volume, or “lines shipped,” it’s measuring an axis that’s actively getting less honest, per the data above, every quarter agents get better. Rewrite the rubric around judgment before the next cycle, not after a bad promotion decision forces the question. If you want a second opinion on what that rubric should look like for your team specifically — leveling criteria, the 1:1 structure, what a promotion packet should actually contain now — that’s a conversation I have often in fractional engineering-leadership engagements, and it’s usually a half-day fix, not a quarter-long process.