I Approved the Diff. I Couldn't Defend the Decision.

Last month, in a design review at PhoenixDX, someone asked why the billing service talks to the ledger through an event queue instead of a direct call. I'd made that call myself — three weeks earlier, agent open in one pane, PR description in the other. I remembered clicking approve. I could not reconstruct why. I sat there, in front of my own team, unable to defend a decision that had my name on the commit.

Here's the part nobody wants to say out loud: reading every diff line by line doesn't keep you sharp. It keeps your pattern recognition sharp — you'll still catch a bad variable name, a missing null check, an off-by-one. What it doesn't train, what it structurally can't train, is architectural ownership: the muscle that decides where a boundary goes and can still defend that decision six weeks later, under pressure, with no PR open in front of you. That muscle atrophies quietly, because "the diff looked fine and merged" tells you nothing about whether you made the call or just recognized that the agent's call looked plausible.

Two objections are probably forming already, so let's deal with them now. "But I review everything" — rubber-stamping a plausible diff isn't reviewing a decision; plausible and correct look identical right up until the day they aren't. "This sounds like purist busywork" — it isn't a productivity tax, it's a diagnostic. You're not slowing down to ship less. You're spending thirty seconds to find out whether you can still make the call yourself.

Here's the specific one, because a vague admission of decay doesn't convince anyone. In April, we ran an agent-driven refactor of what used to be a single payments module at PhoenixDX. I asked the agent to pull reconciliation logic into its own service — the module had gotten unwieldy, an ordinary enough ask. What I didn't do was define the error contract between the two services myself. The agent did. It introduced a discriminated union — RetryableError, TerminalError, PartialError — and wired the retry logic around it. The code was good. Tests passed. It shipped.

Six weeks later, an upstream payment provider started returning a timeout variant we hadn't seen before, and on-call had to decide, at 2am, whether it belonged in Retryable or Partial. Nobody could tell them. Including me. Not because the answer was hard, but because none of us had ever actually decided it. The agent had inferred a taxonomy from the failure modes in our test fixtures, we'd approved a diff that looked sensible, and the one judgment call that actually mattered — what's safe to retry against a payment provider — had never lived in anyone's head. It lived in a switch statement none of us had written.

So we stopped trusting the feeling and started tracking a number. Every week, for boundary-level changes that ship — service splits, error contracts, retry policy, schema ownership — we log whether it was a decision (someone stated the alternative they didn't pick, and why, before accepting it) or an inference (the agent proposed it, it looked right, it merged). The ratio is the metric: decisions made versus decisions inferred-and-rubber-stamped. Ours started ugly — something like one stated decision for every four or five inferred ones. That's not a velocity number. It's a decay number.

The metric only matters if you build practices that feed it. Three moves, all cheap enough to start this sprint:

• ▹Before you accept an agent's structural change — a new service boundary, an error contract, a schema — say the alternative you didn't pick and why, out loud in standup or right in the PR description. Can't name the alternative? You don't have a decision. You have a guess with good formatting.
• ▹Rotate a "no-agent" subsystem every sprint — one component where structural changes get made unassisted for the week. Think of it as a canary, not a punishment. If you can still make the boundary calls yourself, the muscle's intact. If you freeze up, that's the finding — not something to bury in the retro.
• ▹Weekly, go back over the overrides, not the diffs. Pull the list of times you rejected or substantially reworked the agent's first structural draft. A shrinking list isn't automatically good news — it might mean you're disagreeing less, or it might mean you're rubber-stamping more.

This is a control-systems problem, and it's the same shape my research on multi-agent coordination keeps running into: you can't detect drift in a system without a reference signal to drift away from. "Do I feel sharp" isn't a reference signal — it's the same self-report that fails pilots who lean on autopilot until a manual-flying emergency exposes the gap. I'd bet the same thing is already happening to engineers leaning on agents, even if nobody's published the study yet. The reference signal has to be external and falsifiable: a stated alternative, a canary subsystem, a logged override. Track those, and you find out before the 2am incident — not during it.

Sharpness was never about who types the code. It's about who owns the boundary decisions.