Make Your Work Easier to Review

A manager asks an analyst for a competitive memo. The analyst pastes the brief into a model, gets five polished pages in twelve minutes, and sends it over.

The memo reads well: clean structure, confident claims, named competitors, and a recommendation at the end.

The manager cannot tell, in the next ten minutes, whether any of it is true. The sources are vague, the assumptions are buried, and the risks are missing, yet the recommendation looks decisive because the prose is fluent, not because the evidence is checkable.

So the manager either rubber-stamps it or spends an hour reconstructing the work from scratch. Both outcomes mean the same thing: the work was never really delegated. It was only accelerated into a review bottleneck.

People still believe the hard part is getting AI to write something. That belief is already obsolete.

If you cannot review it fast, you cannot delegate it safely.

That sentence applies to models. It also applies to juniors, freelancers, agencies, and anyone else you ask to finish work on your behalf. Fluency proves nothing, and speed stops being leverage the moment verification still belongs to whoever could not afford the time in the first place.

The First AI Skill Is Review Design

Prompting gets attention because it feels like the new craft. Better instructions, better tools, better agents. Those matter, but they are not the bottleneck for most knowledge workers.

The bottleneck is judgment under time pressure. The last two issues, The Price of Electricity Belongs in Your AI Forecast and Compute Is An Asset Class, traced the AI bottleneck down to power and the public price of compute, but once that capacity is paid for, the next constraint is whether anyone can tell, in minutes, if what it produced is any good.

In Stop Asking AI Questions. Give It Work to Finish., the argument was that the useful unit of AI work is becoming the finished artifact rather than the chat answer. That only helps if the artifact arrives in a form a human can evaluate quickly. Otherwise you have traded blank-page time for audit time, and the audit is harder because polished language hides the seams.

In The Question Economy, the point was that polished output no longer proves understanding. Review design is the practical twin of that idea. If answers are cheap, the scarce skill is designing the work itself so that quality can be seen without redoing the whole task. A model is trained to produce text that sounds resolved, and nothing about that training checks whether the resolution is earned. The reviewer, not the generator, has to hold the standard.

Prompting cannot fix this on its own, because the limitation runs deeper than phrasing. A model has no independent way to confirm its own competitive research, no memory of whether last quarter's assumption held up, and no stake in whether the recommendation is actually right. It can be instructed to cite sources and still cite the wrong ones with total confidence, which is a structural fact about where verification has to live, outside the generator, in a review designed before the work starts, rather than a prompt bug you can word your way around.

Beginner's mind, in this context, means epistemic responsibility rather than endless curiosity: refusing to trust fluency just because it sounds finished.

Two Places Review Design Shows Up

Review design works the same way whether the delegated task is mostly judgment, like a memo, or mostly rules, like a support ticket, because the underlying problem is identical: someone downstream has to trust a decision they did not personally make.

The analyst memo

Imagine the competitive memo again, redesigned for review.

Before the analyst opens a model, the standard is explicit:

Name the decision this memo should change.
Separate facts, inferences, and recommendations.
Cite sources next to each material claim.
List the three assumptions that would reverse the recommendation if false.
Include a one-page summary that a manager can score in five minutes.

Now the AI draft is useful, not because it is smarter, but because the review path is short. The manager can check whether the decision is framed correctly, whether the sources exist, and whether the recommendation survives the stated assumptions. The work can be accepted, rejected, or sent back with a precise ask, and the whole check takes five minutes instead of the hour it would take to reconstruct an undesigned memo from scratch.

Without that design, the memo is a reading assignment that pretends to be a deliverable. The analyst still gets speed. The manager gets speed too, but only because someone spent five minutes designing the review before anyone opened a model.

The support reply

Customer support is a cleaner version of the same problem.

A model can draft a refund email that sounds warm, careful, and policy-aware. That does not mean it is safe to send. The reviewer needs to know, in under a minute: which policy applied, what the customer is owed, what exception was used, and what the next status should be in the ticket.

Without review design, the reviewer's only option is to read the whole paragraph again and guess whether the tone tracks the policy. With it, the draft looks completely different. It might include the proposed customer message, the policy citation, the exception reason, and a short internal note, laid out so the policy citation sits next to the payout amount instead of buried inside a friendly sentence. The human ends up checking the decision rather than rereading for tone, and the decision is now visible on its own instead of dressed up in prose.

That is review design: make the judgment surface small enough that delegation does not become theater.

Fluency Is the Trap

AI makes bad work look finished. That is the product feature and the hazard.

A planning deck can invent market sizes with the calm of a consulting firm. A policy summary can omit the clause that creates legal risk while still reading as thorough. A code pull request can arrive with a clean diff, a confident summary, and a plausible explanation for the change, none of which tells you whether the tests actually cover the edge case it just touched or whether the risk section names the thing that could break in production. A research memo can cite a source that does not say what the sentence next to it claims, formatted so cleanly that nobody thinks to click through.

If your review process depends on "does this sound right," you are judging the wrong signal. Sounding right is what the model is optimized to do.

The useful review questions are slower to invent and faster to apply:

What would make this wrong?
Which claims need evidence versus narrative?
What edge cases were ignored?
Who owns the final call if this ships?

Those questions belong upstream of generation, not after you are already drowning in prose.

When a fast eyeball really is enough

None of this means every task needs a five-part standard. A quick internal Slack summary or a first-pass brainstorm can survive a fast eyeball, because the cost of being wrong is low and the fix is easy. The honest test is consequence, not effort: if being wrong would cost real money, real risk, or someone else's trust, a fluent skim stops being review and becomes hope wearing a reviewer's badge. Know which category a task is in before you decide how hard to look.

The Review Design Checklist

Before using AI on a task, write the review into the task itself. Call it the Review Design Checklist, five parts, and fill it in before you generate anything:

Standard: What does good look like in one sentence?
Checklist: What must be present for acceptance?
Failure modes: How does this work usually go wrong?
Edge cases: Which rare conditions still matter?
Decision owner: Who accepts the result, and on what evidence?

That last part is the one teams skip most, and it is usually the one that causes the damage. A memo without a named decision owner gets approved by momentum: the analyst assumes the manager will catch anything wrong, the manager assumes the analyst already checked the sources, and the recommendation ships because everyone thought review was somebody else's job. Naming the owner does not add bureaucracy. It closes the exact gap where fluent, unverified work slips through.

This takes a few minutes. It saves the hour you would spend reverse-engineering a fluent draft.

It also changes how you prompt. Instead of "write a competitive memo," you ask for a memo that separates claims from inferences, cites sources, and ends with assumptions that would reverse the recommendation. You are asking the model to produce work shaped for inspection, not to be wise.

The same checklist works when you delegate to a person instead of a model. Juniors do not fail only from weak skill; they fail when the review criteria live in the manager's head instead of on paper. AI makes that failure mode louder, because volume rises faster than standards do, but the fix was always the same: write the standard down before the work starts, not after it lands on your desk.

Delegation Without Review Design Is Fake Speed

Organizations are about to drown in almost-done work: more drafts, more summaries, more plans, more tickets answered, more pull requests opened. Throughput climbs while trust stays flat, because nobody redesigned the review layer.

That gap does not stay quiet for long. A team that ships more pull requests without a reviewable standard does not get faster. It gets an incident that traces back to a merge nobody actually checked, followed by a slower, more suspicious review process for everyone, including the work that was fine. A support team that lets AI drafts through on tone alone does not get more capacity. It gets a policy exception that goes out wrong, then a manager reading every reply for a month to find out how far the problem spread. The debt does not disappear. It moves downstream and gets more expensive to pay off the longer nobody named the standard.

Real leverage is not "the model wrote it." Real leverage is "I can decide in minutes whether this is safe to use." The first phrase describes speed of generation. The second describes speed of trust, and trust is the actual scarce resource once generation stops being the bottleneck.

That is why review design is the first AI skill for operators, managers, and beginners alike: without it, prompting produces faster confusion, delegation produces elegant dependency, and verification turns every fluent artifact into a second job.

Make the work easier to review, and AI becomes a force multiplier. Leave review to vibes, and you have only made the disguise cheaper.

Before the next task you hand to a model, a junior, or an agency, define the standard, the checklist, the failure modes, the edge cases, and the final decision owner. If you cannot do that, you are not ready to delegate the work. You are only ready to generate something that looks like it.

Reflection Point

Before the next task you hand off, could you write down what would make it wrong? If you cannot answer that in a minute, that is not a note about the model. It is a note about how ready the work is to leave your hands.