Becoming an AI Power User

Delegating the labor still leaves you holding the call

Picture the shift in concrete terms. When AI drafts the email, summarizes the meeting, or prepares the analysis, your job is no longer to produce every line. It becomes catching what is wrong, missing, overstated, thin on evidence, or off-key for the person who will read it. That sounds lighter than writing it yourself, and it can be harder. Much of that catching can be handed off too: a judge prompt that scores each draft against your standard, or a second model asked to find the overstatements and missing evidence, will surface most of the routine slips before you ever read the output. What stays yours is the final call on the cases that need taste, relationship context, or a standard the system has not learned yet, and the less that judgment is exercised, the harder those calls get.

So delegate the labor freely and keep the judgment exercised. Let the model carry the typing, the formatting, the first pass. Keep doing, often enough that it stays in your hands, the part where you read the result against what you wanted and decide whether it clears the bar. The labor is the part that does not make you wiser to repeat. The judging is the part that does. You can hand off the first and still own the second, and owning the second is what lets the call rest on something you can stand behind.^[1]

Full delegation quietly dulls the skill you review with

There is a hidden cost to handing a task over completely, and it shows up slowly enough to miss. Run the same delegation forward in time and watch what happens to your attention. The first time you ask AI to write a client email, you read every sentence, because you do not trust it yet. After three months of letting it draft your emails, you start skimming. After six months, you might not notice that the model softened a risk you meant to flag, misstated a deadline, or struck the wrong tone for a delicate situation. You did not decide to stop checking. The checking just thinned out, one busy day at a time.

That fade is the predictable result of not practicing. Writing a good client email draws on a few skills working together: reading for tone, checking claims against what you remember, calibrating how direct to be for this particular relationship. Stop exercising those skills and they weaken, the way any unused skill does. The danger is not that the model declines. It is that your ability to tell a good draft from a flawed one declines, while the drafts keep arriving as fluent and confident as ever.

Choosing the collaboration mode is choosing which skill you keep

The fix is a routing rule, not a rule against delegating. Full delegation fits routine, low-stakes, well-defined work, the tasks where a wrong answer is cheap to catch and cheap to fix. Close collaboration fits work where a person's judgment currently shapes the result more than the model's does, where staying in the loop produces the better outcome. The skill is reading each task for which case it is, rather than turning a single delegation dial up for everything.

Experienced users often lean toward collaboration as much as toward more delegation. Anthropic's data on how Claude users mature points this way: many of the most practiced users are not simply handing off more, they are iterating more, working with the model collaboratively on harder problems. A large part of the road to power use runs through deeper collaboration on the work that matters, not only through delegating a wider and wider share of it. Power users tend to do both at once, pushing more routine work fully onto the system while going deeper on the calls that reward it.

It helps to picture more than two settings. The earlier chapter on choosing the collaboration mode gives you a useful starting split, directing the work yourself versus delegating it. In practice the choice spreads across four modes, and the simplest way to hold them is by who does the core work and who keeps watch:

• Tool use: you invoke the model for a discrete sub-step and do the core work yourself. As of 2026 this looks like asking for one paragraph or one calculation inside a task you are otherwise driving.
• Pair work: continuous partnership where you stay in the loop on every decision, trading the work back and forth turn by turn.
• Delegation: the model executes the whole task and you review the output after the fact.
• Supervision: the model runs on its own within bounds you set, and you watch its behavior in aggregate rather than checking each result.

The role automation makes rarer is the role it makes worth more

The risk framing above is half the picture, and the cautious half. The other half is that the human role is changing shape, and the new shape is worth more than the old one. When agents take the first drafts, the routine analysis, and the boilerplate, the human job concentrates on the parts that need judgment, taste, and thinking at the level of the whole system. That concentration is what makes the remaining human contribution worth more per hour, on the condition that you invest in the skills the new role asks for.

Ryan Nystrom, an engineering manager at Notion, names the shift plainly: 'I view our job as engineers evolving into systems thinkers and architects.' He also points to a side effect worth borrowing. When the agent produces the first pass, judging it becomes less personal. Reviewing your own work carries a charge, a quiet 'I wrote this, do not pick it apart.' Reviewing the agent's work is a flatter question: does this meet the spec. The emotional weight drops, and the quality of the evaluation can rise once it is no longer about defending your own draft.^[5]

Nystrom also leaves you a way to check your own setup. A workflow that is genuinely better should feel more relaxing, more enjoyable, and more productive at the same time. If yours feels like a trade instead, faster output at lower quality, or higher quality bought with exhaustion, the design needs work, not your willpower. When a workflow does land on all three, the defensive posture this subchapter describes loosens on its own. You keep your judgment exercised by staying in the architect seat: designing the system, writing the spec, evaluating the output, and owning the calls where your knowledge and taste produce the better result. The seat is a playful one too. A lot of the sharpest checks start as a wouldn't it be interesting if I asked the model for a wilder version, or had it attack its own draft, or invented a harder test case than the one in front of me. That experimenting is where your taste stays awake, and the best of those one-off probes is worth folding into the standard so it runs on every future draft.

Four failure modes follow from delegating without checking

When delegation runs ahead of review, the trouble tends to arrive in one of four shapes. Naming them turns a vague worry into a short checklist you can run against any workflow. The table below pairs each failure with how it builds and the move that keeps it from building.

Doubt the evidence too, including this book's numbers

Keeping a clear standard includes a habit that is easy to skip: doubting the evidence, including the evidence in this book. The research behind these claims has limits, and naming them is part of the discipline, not a footnote to it. A reader who takes every cited number at face value has handed the call to the page, which is the exact move this subchapter warns against.

Keeping your judgment sharp leans on the same articulation skill the chapter on following up until the output matches teaches. Staying articulate about what you want, why you want it, and what good looks like is how your evaluating ability stays sharp even as you delegate more. The power user whose judgment keeps improving is the one who keeps communicating precisely with the model, holding a clear standard, rather than letting the model's fluent defaults quietly set the bar.

One line keeps this from tipping into busywork: remove the effort that does not make you wiser, and keep the effort that builds judgment. Some cognitive work is waste to repeat, reformatting, hunting for files, copying between tools, and delegating it costs you nothing. Some cognitive work is how taste, skill, and supervision grow, and delegating it costs you the growth. The aim is not to keep a human in charge for its own sake. It is to get the best aligned result from whichever judgment is stronger on the task, yours or the model's, and to keep both improving. The chapter on building learning loops around your workflows scales how you evaluate quality. The deepest move is not to catch each drifting criterion by hand: it is to evolve the system, setting up an evaluation or a self-critique prompt that flags when your standard and the model's output have drifted apart, then encoding the new criterion into a standard, rule, or judge prompt that catches it on every future run. Each pass hands more of the noticing to the system and frees your attention for the next level up.

Audit your workflows and reset the modes that have drifted