Hand off the work. Keep the thinking.

Why it mattersWhatever ships, a person answers for it. If you've lost track of why the result is right, you can't fix it, defend it, or change it, and you won't notice you've lost track until someone asks.

Addy describes three positions on a spectrum. The difference between them is who owns the reasoning, not how much the AI does:

• Offloading: the AI does the task and you still own the result. Do this all day.
• Deferral: the AI's output becomes your next input. You've stopped treating it as a guess to check.
• Cognitive surrender: the output quietly becomes your own and you feel no need to check it. (The term comes from Shaw and Nave at Wharton.)

You don't decide to slide down the spectrum. You drift, one reasonable-seeming step at a time. Step through it:

The ownership test

You don't have to hold all of a big system in your head. The Claude Code team rebuilds understanding when they need it: they ask Claude to explain the part they're working on. So the test isn't “do I remember everything?” The test is:

“When you can't explain the answer to a question, even by way of your agent, you've ceded ownership.”

You just need to know what you don't know. As Addy points out, this kind of debt is easier to recover than most engineers expect.

Stakes set how much to keep

Surrender is sometimes fine. Addy let an AI choose between three similar hotels and would do it again. The rule: hand it off when being wrong is cheap. Keep the reasoning when other people will live with the consequences. Try sorting these, using the examples from the article:

Why it mattersA person would push back on a vague request. An agent fills in the gaps and hands back something that looks finished. If you never thought it through, a polished answer will hide that, and after reading it you can't picture any other answer.

Guess first

Before any non-trivial task, write down, even just in your head, what you think the answer is. A bad guess is fine. You need it before you read the agent's well-written answer, because after that you'll struggle to imagine anything else. If you really have no idea, ask for a blind-spot pass: tell the model what you know and have it find what you don't know you don't know.

Your prompt shows how well you understand the problem

“If you can't express it clearly, it may not be clear in your own mind.”

• Write a short brief in your own words: who it's for, what's out of scope, what “done” means.
• If two rounds of corrections haven't fixed it, stop tweaking and rewrite the prompt. The problem is your thinking, not the wording.
• If you're unclear, have the agent interview you about what it doesn't understand. That's collaborating instead of delegating. A session went well if your own understanding got sharper.
• Know whether you're asking it to help you think or to think for you. Both are fine, as long as you know which one you're doing.

Why it mattersAgents make tests so cheap that you'll see a lot of green. You can surrender to checks too: “Is there evidence for my conclusion?” quietly becomes “Did it go green?” A green check proves one thing, and it's easy to assume it proved everything.

• Build the loop. Give the agent a way to check its own work (end-to-end tests, property tests, actually using the app) so it can fix and retry before you look. Boris Cherny calls this “give Claude a way to verify its work.” Then you review the evidence instead of every line.
• Decide what “verified” means up front. Once you've seen the result, you'll find a way to call it good.
• Make the finish line something you can see: a passing test, a screenshot, a log. When the agent says it's done, read the command it ran and what it printed before you read its summary.
• Make self-review automatic. Have a subagent with a fresh context review the work every time, not just when you remember. Then ask “Did I miss anything?” Addy says it often turns up two or three more things.
• The same applies outside code. If an agent summarized fifty customer calls, read a couple of the actual calls. Recalculate the number your recommendation depends on.

// shipping.ts
const shipping = (total) => total > 50 ? 0 : 7.99

// shipping.test.ts
test('free shipping for big orders', () => {
  expect(shipping(60)).toBe(0)
}) ✓ passed

“When a check goes green, ask what it proved. Then ask what it didn't.”

A rule of thumb from the Claude Code team's code review: if you can't say what the checks would miss, ask for a real review, not a quick approval. Agents make checks cheap to set up. Knowing what a good check looks like is still on you.

Why it mattersReviewing tends to find only what you already expected. A 600-line PR with sensible names and passing tests can hide a reordered transaction or a flipped default for an edge case. Someone may ask you about it one day, and you need to be able to answer.

• Read the diff as if the AI didn't write it. Writing and reviewing are different skills, and at some point reviewing becomes rubber-stamping.
• Look past the diff at its decisions. Over a long session the agent makes many small choices for you: defaults, what's out of scope, which requirement wins when two conflict. A summary that says everything went well won't show them, so ask.
• Quiz yourself. Pick lines at random: what does this one do? For a document, close it and write the main argument from memory. Some people have Claude end its change report with a quiz and only merge after a perfect score.
• Hold your own standard. Everything now comes out neat and confident, so polish tells you nothing. If you wouldn't put your name on it, don't ship it.
• Turn rejections into rules. When something falls short, write down why in shared config, a hook or a test, so it doesn't happen again. Addy calls this how taste compounds.

Agents can also protect your attention. On his open source project, Addy uses agents to sort incoming PRs and point him to where he's actually needed. Then he does the thinking himself: is this the right problem, solved the right way?

Why it mattersEvery extra session adds output, but your review time stays the same. Past that limit you've stopped reviewing, even if it still feels like reviewing.

Addy calls this the orchestration tax: the gap between what your agents produce and what you'd be willing to put your name on. When finished work piles up faster than you can get through it, another session makes things worse. You have two fixes: tighten the checks so less of the work needs you, or slow down.

“When you're producing more than you can stand behind, you're no longer reviewing. You're hoping.”

Why it mattersAnthropic's research calls it the paradox of supervision: “supervising Claude requires the very coding skills that may atrophy from AI overuse.” Skills you stop using fade, probably faster than you'd guess, and with them goes your ability to catch the agent's mistakes.

“But the models will be better at this than me”

Maybe at catching problems, and Addy supports handing more of that to agents. He keeps the skill anyway, for three reasons:

• Someone is responsible for what ships, however much AI helped.
• Deciding how much to trust an agent is a judgment call, and the models' mistakes keep changing. Reviewing the work is how you keep that judgment accurate.
• Some questions are yours no matter how good the model is: what are you building, why is it worth it, who does it affect, and what are you willing to give up?

“You may offload the work and much of the auditing, but not the accountability.”

Small, regular practices

• Weekly: write some code without an agent, or do one real thing you'd hate to forget how to do.
• Monthly: list what you've stopped doing and decide which of those you're fine letting go. Ask yourself: how lost would you be if AI didn't exist?
• When something is beyond you, learn it properly, so you know where it fits, instead of pasting a one-line explanation.
• Schedule the checking. Checking the machine properly is real work. Give it its own time or it won't happen.