Review fatigue

Day 23: Review Fatigue and the Craft Budget

Your best senior engineer can be green on every dashboard and still be on the way out. Since my team adopted coding agents, I've watched strong people leave, and pay and workload weren't the reason. They stopped feeling like builders. In my experience your usual retention tools won't catch this. If you can't name the problem, you'll lose the people your metrics say are doing fine.

The signal I almost missed

It came up in a routine 1:1 with one of my strongest seniors. Almost in passing, they said: "I don't think I've written anything in three months." Every metric we tracked said this person was thriving. High PR merge count, fast review turnaround, few incidents, strong peer feedback. Two weeks later they resigned. Money wasn't the reason and there was no burnout story. They did have another offer, but on paper it was barely better. The only reason they gave me was "I want to build things again."

What I misread

I took it for burnout, so I offered time off and a lighter sprint. That made it worse. On an agentic team, a lighter sprint means fewer hard problems. The agents still do the drafting, so the person spends the sprint approving the same kind of output, only less of it. Workload was never their problem. Their role had moved from author to approver, and nobody had chosen that on purpose.

Naming it: review fatigue

Review fatigue is what happens when an engineer's job changes from making things to judging things that someone, or something, else made. On teams using Claude Code, Cursor, Copilot agents or Codex, it tends to go like this:

• ▹The agent writes the first draft: code, tests, migration, even the PR description.
• ▹The human's job shrinks to checking whether that draft is correct, safe and consistent with the system, then approving it or sending it back.
• ▹That judgment matters, and it's often the most important part of the work. Nobody sees it, though. A good review mostly shows up as an incident that never happened.
• ▹Over the months, the engineer's sense of themselves as someone who makes things wears thin. They're still busy and still good at the job. None of the work feels like theirs any more.

A typical day looks like this. They review 14 agent-drafted PRs, send 3 back with comments, tweak 2 prompts so the agent can retry, and write zero lines from scratch. Keep that up for a quarter and you get someone who looks productive and feels hollow.

Why the usual retention playbook misses it

Raises, promotions and wellness days each answer a question: "Am I paid fairly?" "Am I growing?" "Am I tired?" Review fatigue asks a different one: "Am I still making anything?" Someone can say yes to the first three and still leave over the fourth.

• ▹1:1s. Earlier in this series I said 1:1s exist for the things that never appear in status updates, and review fatigue is one of those things. A 1:1 template that asks about blockers and workload will walk right past it.
• ▹Career ladders. A lot of ladders still reward visible output: PRs shipped, features delivered, scope covered. Agents inflate every one of those numbers. The person approving 14 agent PRs a day looks senior on paper, and the person who spends a week on one gnarly design problem looks slow. Your ladder might be pushing your best builders toward exactly the work that drains them.

The diagnostic question

About once a month, in every 1:1, I now ask: "What's the last thing you made that you're proud of, and how much of it was yours?" The first half tells you whether they're proud of anything. The second half tells you whether they feel they wrote it.

Here are two answers from my team, given about a week apart:

• ▹Answer A: "The new retry and idempotency design for the payments webhook. The agent wrote most of the handler code, but I spent two days working out the failure modes and the state machine. That part was mine." This person is fine. Agents handled the volume, the core idea was theirs, and they know it.
• ▹Answer B: a long pause, then: "I guess the search refactor? But honestly the agent did it, I just steered." That's the warning sign. They named something and disowned it in the same sentence. This was the second senior I nearly lost.

Two other answers to listen for: ones that only mention volume ("we shipped a lot") and ones that only mention other people's work ("the team did X"). In my experience both usually mean the person has nothing they think of as their own.

Fix 1: the craft budget

Every engineer keeps one hard problem per cycle that a human explicitly owns. Agents can help at the edges with research, test scaffolding and boilerplate. The engineer writes the first draft of the core design and code, and their name goes on it.

How we choose these problems:

• ▹Ambiguous: the spec isn't settled, so working out what to build is part of the job.
• ▹High-judgment: there are real tradeoffs, such as consistency vs latency, build vs buy, or data model choices, and a confident wrong answer costs a lot.
• ▹Architectural: the decision shapes other people's work for months. Think service boundaries, core abstractions, or the eval harness itself.
• ▹Never busywork: if an agent could do it well in an hour, it doesn't count. The point is that it's hard.

The cost is real. Throughput drops, and you should say that out loud. In our sprint planning, the craft-budget problem took roughly a fifth to a third of each engineer's capacity. Agents would have produced something in that time, often faster. Velocity dipped visibly for the first two sprints. I took that to leadership as a deliberate cost: you're paying to keep the people who can tell when the agent is wrong. The designs that came out of craft-budget work were also the ones we had to revisit least. I can't give you a clean number to prove it, though.

Fix 2: make agent design count as authorship

Some seniors find a new kind of making in the agent system itself. On an agentic team, that system is real engineering:

• ▹Prompts and instructions: CLAUDE.md, AGENTS.md, system prompts and skills, all versioned in the repo.
• ▹Guardrails: what agents are allowed to touch, plus permission rules, hooks and pre-merge checks.
• ▹Eval suites: the tests that tell you whether a prompt or model change made agent output better or worse.
• ▹Workflow: how work moves between agents and humans. When does an agent open a PR, who reviews it, and what gets escalated?

The rule is that these are artifacts with a named owner. They get reviewed like code and they count on the career ladder. If someone redesigns the eval suite and the rejection rate on agent PRs goes down, that's an engineering achievement, not "tooling stuff." A CODEOWNERS entry is a cheap way to make that visible:

# CODEOWNERS: agent design artifacts have human authors
/.claude/            @team-lead-agent-workflow
/AGENTS.md           @senior-eng-a
/evals/agent/        @senior-eng-b
/guardrails/         @senior-eng-c

# Each owner is listed in the cycle review for what they changed and why.

Some people won't go for this. A builder may want to build the product, not the machine that builds it. That's fine, and it's the reason this is Fix 2 and not the whole answer.

Fix 3: split review load by temperament

An even split of review work sounds fair, but it doesn't hold up. Some people really do enjoy being the editor. They like catching the subtle bug and they get satisfaction from a clean approval queue. In my experience, most of your best builders aren't like that.

• ▹Ask people how much of their week they'd like to spend reviewing versus authoring. People will often just tell you.
• ▹Send more review work to the people who like it, and treat it as a skill rather than a chore.
• ▹Rotate hands-on weeks, where someone authors and only reviews their own area, so nobody spends a whole quarter just approving.
• ▹Keep an eye on the extremes. Someone who reviews everything and authors nothing is a retention risk, even if they say they're fine.

What happened next

The engineer who left didn't come back. We parted on good terms, and most of this lesson comes from their exit conversation. The second senior, the one who gave Answer B, took the first craft-budget problem we assigned: redesigning our agent task-routing layer. They told me later it was the first time in months they'd stayed late because they wanted to. They're still on the team.

The quarterly signals shifted a little. More people answered the diagnostic question without hedging, and fewer people had review-only weeks. It isn't solved. Agents keep getting better at the hard problems as well, so the line between what humans own and what agents draft moves every quarter. Picking craft-budget problems is now a planning decision we make every cycle. It isn't a one-time setup.

Takeaway for this week

• ▹Check each person's author-to-review ratio: PRs they wrote themselves versus PRs they reviewed over the last 30 days. Start with the script below.
• ▹Ask the diagnostic question in your next three 1:1s and write down exactly what people say.
• ▹Protect one human-owned problem in your next sprint plan. Name the owner and tell the team why you're doing it.
• ▹Next, in Day 24: if agent output inflates every metric, how do you measure team health at all?

#!/usr/bin/env bash
# Rough author-to-review ratio per engineer, last 30 days.
# Assumes agent-drafted PRs carry the label "agent-authored" (adapt to your convention).
# Uses GNU date; on macOS use: date -v-30d +%Y-%m-%d
REPO="your-org/your-repo"
SINCE=$(date -d '30 days ago' +%Y-%m-%d)

for u in engineer-a engineer-b engineer-c; do
  authored=$(gh search prs "repo:$REPO author:$u created:>=$SINCE -label:agent-authored" \
    --limit 200 --json number --jq 'length')
  reviewed=$(gh search prs "repo:$REPO reviewed-by:$u created:>=$SINCE" \
    --limit 200 --json number --jq 'length')
  echo "$u  authored=$authored  reviewed=$reviewed"
done
# A ratio near 0 for a quarter is a conversation, not a verdict.

Extend your knowledge

• ▹Read Daniel Pink's "Drive" with autonomy and mastery in mind, and ask which of the two agents have taken from your engineers.
• ▹Go back to Camille Fournier's "The Manager's Path" on managing senior engineers and notice where it assumes they write the code themselves.
• ▹Read Will Larson's writing on staff-plus roles ("Staff Engineer", lethain.com) for ways to recognise judgment and architecture work that output volume doesn't capture.
• ▹Try it: write up one agent-design artifact on your team (a CLAUDE.md, an eval suite, a guardrail) with a named owner, and bring it to your next promotion calibration as evidence.