Review the AI's work the way you'd review a junior's

We already know how to check work produced by someone confident, fast, and new to our context. We've just forgotten to use it.

The best thing that happened to my early career was a tech lead named, well, let's call him D, who reviewed my work like it mattered. I'd hand him a test plan or a status pack, feeling quite pleased with it, and he'd put it on the desk, not look at it, and ask: "Before I read this. What did you assume? What didn't you check?"

I found it infuriating for about a month. Then I noticed something. He caught things no one else caught, in less time than anyone else spent, and I was learning more from his ten-minute reviews than from entire courses. He wasn't reading harder. He was reading in a different order.

I've been thinking about D constantly this year, because of a moment I'm not proud of.

The approval I almost gave

A few months ago I asked an AI assistant to draft a risk assessment for a data migration, the kind of document I've written dozens of times. What came back was, honestly, lovely. Clean categories, plausible likelihoods, professional tone. I read it the way you read something that looks finished, nodding along, and my cursor was hovering near "looks good, let's circulate" when a small voice asked D's question: what did it assume, and what didn't it check?

So I checked. The document quietly assumed a one-weekend cutover. Our plan was phased, over six weeks, which changes the entire middle of a risk assessment: coexistence risks, double-running costs, rollback windows. The draft wasn't wrong the way a bad document is wrong. It was wrong the way a brilliant stranger's work is wrong: fluent, confident, and built on a guess about a context it had never seen.

And here's the thing that actually scared me. If a human junior had handed me that document, I would have caught it in two minutes, because I'd have asked my opening questions. The polish switched my review brain off. I'd never have accepted "it reads well" as a reason to sign off on a person's work. I nearly accepted it from a tool.

The craft we already own

Here's what I keep coming back to: reviewing the work of someone fast, confident, eager, and new to your context is not a new problem. It's one of the oldest, most developed skills in delivery. Every good senior has a whole quiet method for it. We just haven't noticed that the method transfers.

Think about what a good reviewer of a junior's work actually does. They don't start at line one. They start above the document.

First, assumptions: what did you take as given? A junior, like an AI, fills every gap in the brief with a guess, and the guesses are where the damage lives. Second, approach: is this the right kind of answer at all, or a beautifully executed wrong turn? Third, edges: what happens when the input is empty, enormous, strange, or hostile? Fluency is manufactured in the middle of the happy path; truth lives at the edges. And only then, last and least, the line-by-line pass.

Weak reviews, of people and of models, run that ladder upside down. They live entirely on the bottom rung, fixing commas in a document whose premise is wrong. The polish is exactly what invites you down there, and with AI output the polish is relentless.

There's a social version of this too, and anyone who's reviewed juniors will recognise it. When a nervous first-year hands you something rough, you read carefully, because the roughness tells you to. When your strongest junior hands you something gleaming, you skim, and that's precisely the day the gleaming thing has a hole in it. Reviewers have known this trap for decades: confidence transfers from the artifact to the reader. AI output is that trap, industrialised. Every single draft arrives gleaming, including the ones built on a wrong guess, and so every single draft deserves the strong-junior treatment: warm respect, zero deference.

Where the analogy snaps, and it matters

I don't want to oversell the comparison, because the place it breaks is the most important thing in this post.

When D reviewed me, the review compounded. The next test plan I handed him was better, because I carried his questions into it. That's the deal with juniors: you invest review time now, you get judgment later. The AI doesn't hold up its end of that deal. It won't remember your context tomorrow. It will make the same confident weekend-cutover guess next week, in a different costume.

So the learning loop still exists, but it has to live on your side of the table. The lessons go into your prompt, your checklist, the context you feed it, the standing instructions your team shares. In a strange way, you become the junior's notebook: every mistake the review catches is worth writing down, because you, not the tool, are where the improvement accumulates. Teams that get this build a shared crib sheet of what the model gets wrong in their world. Teams that don't re-catch, or re-miss, the same errors forever.

Five questions before you accept its work

Here's the checklist I now keep beside me, built from the questions good reviewers have always asked juniors. They take about ten minutes. They've paid for themselves every single week.

• What did it assume? Ask it directly: "list every assumption this document makes about our context." The weekend-cutover guesses surface with embarrassing speed when you simply ask.

• What would make this wrong? The junior version is "what didn't you check?" If you can't name the conditions under which the output fails, you haven't reviewed it, you've admired it.

• Where did this come from? For any fact, figure, or claim that matters: can it say, and can you verify? A junior saying "I read it somewhere" wouldn't pass. The same bar applies.

• Verify the one thing that would hurt most. You can't check everything, and you don't need to. Find the claim that, if wrong, does the most damage, and check that one by hand. Reviewing juniors taught us triage; use it.

• Would I sign my name under this? Because you are. The moment you pass it on, it's your work, with your judgment wrapped around it. If that question creates a flutter of doubt, the review isn't finished.

Notice that none of these questions require you to be a machine learning expert. They're judgment questions, and they were in your toolkit before the tools arrived. That's the quiet good news inside all of this: the skill that protects you was never technical.

The reviewer is the role now

If you're a Scrum Master, a project manager, or anyone whose team is shipping AI-assisted work, I'd go one step further: reviewing this way, out loud, is now part of your craft. When you ask "what did we assume, what are the edges, what did we verify by hand" in front of the team, you're not just checking a document. You're teaching the whole room what acceptance means when drafts are free and confidence is infinite.

And if you're earlier in your career, here's the reframe I'd offer with real warmth: the industry just made review skill scarce and precious at the exact moment everyone assumed juniors were in trouble. The people who stand out over the next few years won't be the ones who generate the most. They'll be the ones who can look at a fluent, finished-seeming piece of work and know, in ten calm minutes, whether it deserves their name under it.

D retired a while ago. I like to think of his questions sitting on thousands of desks now, asked of a new kind of junior. Before you read it: what did it assume? What didn't it check? Everything I know about working with these tools fits inside those two questions, waiting at the top of the ladder.