Handoff radius

Day 29: Handoff Radius, the One Number That Shows Whether You're Getting Rusty

You can go a whole year without getting any better at your job and look busier than ever the entire time. When agents write most of your code, your output keeps going up whether or not you understand more. So you need a number that tracks your judgment, not how much you ship.

Six minutes, forty files

I've caught myself doing this. An agent opens a 40-file PR. CI is green, the diff is tidy, and the summary reads well. I approve it in about six minutes. On Monday someone asks a simple question: "Why is that safe to run against the live tenant table?" I can't answer from memory. I have to go back and read my own approved PR as if I'd never seen it.

Call it productive but not sure. You shipped a lot, and you can't fully explain what you shipped. Once those two drift apart you're losing sharpness, and none of your usual signals will tell you.

Delegation has two halves

Every handoff to an agent has two halves:

• ▹Specifying: deciding what should happen, within what limits, and how you'll know it worked. That was the focus of the earlier spec-writing days.
• ▹Verifying: confirming that what came back is correct and safe, and knowing where it could break. The code-review days covered how to do it.

Output volume measures neither half. PRs merged, lines changed and tickets closed mostly measure how fast the agent works. Of the two halves, verifying is the one that fades quietly. A bad spec usually fails loudly, because the agent builds the wrong thing and you notice. Weak verification fails silently. Everything still merges. You only find the gap later, in an incident or in a question you can't answer.

The metric, defined precisely

Handoff radius is the largest task you can delegate to an agent and then, within 10 minutes of it coming back, answer all three of these questions without asking the agent:

• ▹What changed? Describe the change in behavior in plain words. A list of files doesn't count.
• ▹Why is it correct? Give the reasoning that makes it right: the invariant, the contract, or the edge case it handles.
• ▹What would break it? Point to the riskiest line or assumption, and name the input or condition that would make it fail.

Why 10 minutes and not 60? Give anyone an hour and they can verify almost anything by grinding through it line by line. That tests patience. Ten minutes isn't enough for a full re-read, so the only way to pass is to already have a mental model of the system and check the diff against it. That model is what you're trying to measure. The time limit makes this a test of sharpness, not effort.

When not to use it: throwaway prototypes, spikes, and code you'll delete this week. Deep verification isn't the point there. Use it on work that ships to production or that other people will build on.

How to measure it this week

• ▹1. Pick 5 real agent tasks from your normal work, not practice tasks. Pick a range of sizes on purpose: a couple you're comfortable with and a couple that feel a bit too big.
• ▹2. Write the spec yourself before you delegate, and note the size: how many files you expect to change, the distinct concepts involved (auth, idempotency, schema migration and so on), or story points if your team uses them.
• ▹3. When the agent finishes, start a 10-minute timer. Review however you like: read the diff, run the tests, run it locally. Just don't ask the agent to explain anything.
• ▹4. When the timer goes off, close the diff and write your answers to the three questions cold: what changed, why it's correct, and the riskiest line.
• ▹5. Check your answers against the code. Read the agent's explanation only after you've written yours. Score it pass or fail. Partly right is a fail.
• ▹6. Write down the biggest task you passed. That size is your handoff radius for this quarter.

Pick one way to measure size and stick with it. Counting files is easiest. Counting concepts is more honest, because a 3-file change that touches concurrency is bigger than a 20-file rename. I record both.

Worked example: what my log looks like

I keep a plain text file with one row for each task I measure and one summary line per quarter. Here's the format, filled in with the two quarters that taught me the most. My radius grew in the first and shrank in the second.

HANDOFF RADIUS LOG

# Quarter A: new internal service (I wrote the design + specs)
task                          files  concepts  verify  result  riskiest line I named
----------------------------  -----  --------  ------  ------  ---------------------------
add job retry w/ backoff        4       2      7 min   PASS    retry on non-idempotent POST
new tenant-scoped endpoint      9       3      9 min   PASS    missing tenant filter in query
queue consumer + DLQ           14       4     10 min   PASS    ack before persist
schema migration + backfill    18       5     10 min   FAIL    (named wrong one: lock time)
RADIUS: ~14 files / 4 concepts   (last quarter: ~8 / 3)  -> GREW

# Quarter B: payments module (I had only ever reviewed it)
task                          files  concepts  verify  result  riskiest line I named
----------------------------  -----  --------  ------  ------  ---------------------------
rename currency helper          6       1      4 min   PASS    rounding call site
refund partial amounts          7       3     10 min   FAIL    couldn't say why totals hold
webhook signature handling      5       3     10 min   FAIL    named one, missed replay window
retry provider timeouts         8       3     10 min   FAIL    didn't know idempotency key rule
RADIUS here: ~6 files / 1 concept  -> SHRANK (in this area)

What made the difference? In Quarter A I had designed the service, so I already had the mental model before the agent wrote a line. To verify, I just checked the diff against a picture I already had. In Quarter B I'd approved plenty of payments PRs over time, but I'd never built that model. After all that time reviewing other people's work, the code felt familiar, but I didn't understand it. My overall output that quarter was high. In payments, the biggest thing I could verify was about the size of a rename.

So track your radius separately for each area, not as one global number. You can be sharp in one part of the codebase and stale in another, and an average hides that.

What makes the radius grow

Three habits, each with one concrete action:

• ▹Tighter specs before delegating. Before you hand off a task, write down its one invariant (the thing that must stay true) and its riskiest assumption. If you can't write them, you won't be able to verify the result either. Make the task smaller, or learn the area first.
• ▹Read where you fail. For every FAIL in your log, spend 30 minutes that week reading that code path from start to finish: entry point, data flow, failure handling. No agent and no summary, just you and the code.
• ▹Rebuild something without an agent now and then. Once a quarter, take the piece you failed to verify and rebuild a small version by hand on a scratch branch. For example, write a partial refund calculator with a test that feeds it random inputs and checks that the totals always add up. Then throw the code away. The understanding you gained is what you keep.

What makes the radius lie

The metric only works if you're honest with it. It usually goes wrong in one of three ways, and each has a guardrail:

• ▹Rubber-stamping because tests passed. Green CI means the code passes the tests the agent wrote or kept. It doesn't tell you whether those tests check the right thing. Guardrail: "the tests pass" is not an answer to "why is it correct?" Name the specific test that would fail if the riskiest line were wrong. If no such test exists, that's a FAIL.
• ▹Picking easy tasks to look good. If all five tasks are comfortable, you've measured your floor, not your radius. Guardrail: at least two of the five must be bigger than last quarter's radius. A good measurement includes some failures.
• ▹Mistaking "the agent explained it" for "I understand it." A fluent summary from the agent feels like understanding, but usually you're just recognizing what it says. Guardrail: write your three answers before you read any agent explanation, then compare. Anything you only knew because the agent told you counts against you.

For EMs and tech leads: don't use it to rank people

Once there's a number, someone will want it on a dashboard. Don't. Turn handoff radius into a ranking and people will pick easy tasks and grade themselves generously. That's Goodhart's law, in Marilyn Strathern's well-known phrasing: when a measure becomes a target, it ceases to be a good measure. With this metric, gaming doesn't just distort the number. It makes it useless, because the person doing the measuring is the person being measured.

• ▹Share your own number first, including where it shrank. When I showed my team my payments row, people opened up far more than any framework had ever gotten them to.
• ▹Bring it into 1:1s as a conversation starter, not a score. Ask things like "Which area would you hate to verify in 10 minutes right now?" and "What would make that area feel like Quarter A?"
• ▹Turn the answers into growth work, like pairing in that area, a spec-writing rotation, or a small rebuild without an agent. Keep them out of performance ratings.
• ▹Expect someone's radius to drop when they move into a new area. That's normal. What deserves attention is a radius that stays flat in an area someone has worked in for several quarters.

Your one action today

• ▹Write down your handoff radius today. A rough version from this week's tasks is enough: the biggest task you passed, in files and concepts, and which area it was in.
• ▹Set a calendar reminder for 90 days from now, titled "Measure handoff radius again."
• ▹When it fires, run the five-task test again and compare honestly. If your radius grew, you're getting sharper. If it's flat or shrinking, you're going stale, no matter what your output says.

Day 30 builds directly on this. Today you found where your radius ends. Tomorrow you'll turn the FAIL rows into a deliberate practice plan, so the areas you can't verify become the areas you're learning on purpose.

Extend your knowledge

• ▹Start your log today: a plain text or markdown file with the columns from the worked example (task, files, concepts, verify time, result, riskiest line). Add rows every week and a summary line each quarter.
• ▹Before you introduce any engineering metric to your team, read up on Goodhart's law, both Charles Goodhart's original idea and Marilyn Strathern's well-known phrasing.
• ▹Read Peter Naur's essay "Programming as Theory Building" (1985). He argues that the real product of programming is the programmer's mental model of the system. That model is what handoff radius tries to measure.
• ▹Try one rebuild without an agent this month. Take your most recent FAIL, rebuild a small version by hand on a scratch branch, then measure that area again.