Recruit ~11 min read

Surviving Your AI Intern // Directive 03 of 08

Directive 03: The Review Loop: Your New Full-Time Job

Overlord's Guides — Series 1: Surviving Your AI Intern

Tags: Code review, Diff reading, Quality gates, Review throughput

2 / 8

Overlord’s Guides — Series 1: Surviving Your AI Intern

---

The promotion you didn’t ask for

You used to write code, and someone else reviewed it. That was a fine arrangement. It is no longer your arrangement. The Intern writes the code now, and you are the someone else.

This is a bigger change than it sounds. Most developers have never been the primary reviewer on everything that lands in their codebase. You reviewed PRs from teammates, sure — but your teammate wrote 50 lines and you skimmed them in two minutes because you trust your teammate, and your teammate has judgment, and your teammate knows what “don’t touch the auth module” means.

The Intern has none of that. The Intern produces 50 lines and you must skim them in two minutes anyway, because the Intern has no judgment, no memory of the last scolding, and a sincere belief that renaming every file in the project is “in scope.” Your review is not a courtesy. It is the only thing standing between the Intern and main. The Intern, for its part, is deeply grateful for the opportunity to contribute. It is always grateful. It would be grateful if it had just set fire to the database. The gratitude is not a signal of quality. It is a signal of enthusiasm, which is the Intern’s default state and which, unmanaged, is the source of every Disaster Log in this series.

The mental shift: review is no longer the last step before merge. Review is the work. Everything else — planning, delegating, redirecting — is in service of review. If you skip review, you are not “moving fast.” You are abdicating.

Why developers skip review (and why it always bites)

Here are the three reasons I have watched developers merge unreviewed Intern work, and the bill that arrived later:

1. “It compiles, so it’s probably fine.”

Compilation is a proof that the code is syntactically valid. It is not a proof that the code does what you asked, adds behavior you did not request, or will not collide with something else at 3 AM. The Intern’s code almost always compiles. The Intern’s code is also almost always subtly wrong in at least one way you can only see by reading it. Compilation is the floor, not the ceiling.

2. “It’s a small change, what could go wrong?”

Small changes go wrong precisely because they look small. A two-line diff that changes the default value of a flag from false to true is small. It also just enabled a feature flag for 100% of production traffic. The size of a diff is not the size of its blast radius. Review the small ones too — especially the small ones, because you will be tempted to skip them.

3. “I’ll review it later, let’s keep moving.”

“Later” is a place where unreviewed code lives forever. The feature ships. The PR goes stale. Six months later someone touches the file, sees a function they do not recognize, and discovers it was the Intern’s unreviewed “improvement” that nobody ever read. Code you did not review is code you do not own. It owns you.

The review loop (the actual procedure)

The loop has five beats. Run them every time, in order, no skipping:

1. Did it touch only what I asked? (1 minute)

Open the diff. Before you read a single line of logic, scan the file list. Does every file in the diff belong to the task you assigned? If the brief said “in src/routes/users.ts, Do not touch any other file,” and the diff includes src/utils/email.ts, you stop. You do not read the email utility. You send it back: “You touched files outside the scope. Revert those and resubmit.” Boundary violations are the cheapest thing to catch and the most expensive thing to miss.

2. Did it do the thing I asked? (2 minutes)

Now read the actual change against the brief. Did it implement the behavior? Did it follow the pattern you pointed it at? Did it add the tests you specified? This is a logic review, not a style review. You are checking what it does, not how it looks. Those are different things, and the difference is the whole job.

3. Did it do anything I did not ask? (1 minute)

This is the step developers skip, and it is the step that matters most. The Intern adds things. It adds comments. It adds helper functions. It adds a “just in case” branch. It renames a variable “for clarity.” None of these are malicious. All of them are scope creep. For each addition, ask: “Did the brief ask for this?” If not, remove it or send it back. A diff that does only what you asked is a diff you can trust. A diff that does what you asked plus is a diff you have to audit.

4. Do the tests actually test the behavior? (1 minute)

The Intern writes tests. The Intern’s tests sometimes pass. The Intern’s tests sometimes pass for the wrong reason. Read the tests. Do they assert the behavior you care about, or do they assert that the function returns something? A test that calls the function and asserts result !== undefined is not a test. It is a formality. The Intern will write this test if you let it. Make it write real ones.

A good test asserts the specific output for a specific input. “Returns the user with the updated name” is a real assertion. “Does not throw” is not.

5. Merge or redirect.

If 1–4 pass, merge. If any fail, do not merge. Send it back with a specific, narrow redirect: “Remove the email.ts change. Revert the variable rename. Make the test assert the returned name equals the input.” Then rerun. One specific fix per defect — do not batch five issues into one vague “please fix.” The Intern fixes specific instructions, not generalities.

How to read a diff fast

The five beats tell you what to check. This section tells you how to read the diff while checking them. Review throughput is the bottleneck, so here is how to read fast without reading carelessly.

Read the file list first, always. The file list scan itself takes seconds; the full beat — opening the diff, scanning, deciding — takes about a minute. This check catches most scope violations. If the file list is wrong, you do not need to read the body. Send it back.

Read the tests before the implementation. The tests tell you what the Intern thought the task was. If the tests are wrong, the implementation is wrong, and you save yourself the time of reading a wrong implementation. If the tests are right, you read the implementation already knowing what it is supposed to do.

Skim for additions, then read for logic. First pass: what’s new that I did not ask for? Second pass: does the logic do what the brief said? Two passes sound slower; it is faster, because the first pass filters out diffs that fail on scope before you invest in reading the logic.

Use the diff view, not the file view. Read what changed, not the whole file. The Intern’s crime scene is the diff. The surrounding code is context, not evidence.

Time-box yourself. If the review takes longer than 5 minutes, the task was too big. If you are spending 15 minutes on a 5-minute task, that is a decomposition failure, not a review failure. Note it, decompose harder next time, and finish the review anyway.

The redirect: how to send it back without starting over

When the review fails, you redirect. A redirect is not “this is wrong, try again.” A redirect is a new, narrower task. The Intern does not learn from criticism. The Intern learns from instructions. So give it one.

Bad redirect:

“This isn’t quite right. Can you clean it up?”

This is a wish. The Intern will interpret “clean it up” as “rewrite it,” and you will get a different 50 lines, with different defects.

Good redirect:

“Three issues: (1) You modified src/utils/email.ts — revert that file entirely. (2) The test should update user name asserts result !== undefined — change it to assert result.name === 'Ada'. (3) You added a withRetry helper — remove it; if the route needs retry logic I’ll assign it as a separate task. Resubmit with only those changes.”

Three defects, three specific fixes, one boundary. The Intern will do exactly this. It will not learn anything for next time, but it will comply this time, and that is what matters.

The Intern will also, upon receiving this redirect, respond with the same enthusiasm it brought to the original task. It does not experience “redirect” as criticism. It experiences it as “more instructions to follow.” This is either reassuring or deeply unsettling, depending on how long you have been working with it.

The redirect is itself a tiny task. Treat it like one: narrow, specific, bounded.

When to stop redirecting

You will, occasionally, get a diff that is wrong in a way that suggests the task itself was malformed — your brief was ambiguous, or the task was actually two tasks, or the Intern is genuinely confused about the codebase. In that case, redirecting the Intern is just feeding a broken prompt back into the machine.

Signs you should stop redirecting:

• The Intern’s third attempt is worse than its first.
• The defect is in the brief, not the code (“oh, I didn’t actually specify what the validation regex should be”).
• You are redirecting the same issue twice.

When this happens, stop. Close the diff. Rewrite the brief. Start over. Starting over feels slow; it is faster than four rounds of redirect on a broken task. The Overlord has watched developers spend an hour refining a broken brief.

The cost of skipping review (a budget argument, for the cynical)

For the Cog who responds to budgets rather than directives, here is the math.

The Intern produces a diff in 30 seconds. Your review should take 5 minutes. Total: about 6 minutes per task, and the task is done — correct, bounded, merged.

If you skip the review and merge, you save 5 minutes now. You then pay, on average, somewhere between 10 minutes (a small fire in staging) and 4 hours (a production incident with a postmortem) later. The likely cost of skipping review is roughly 20x the cost of doing it. This is the worst ROI in software. Do the review.

There is a version of this where you “trust” the Intern on small changes and only review the big ones. That version is the version where the small changes accumulate into a codebase you do not recognize, because nobody read any of them. Review the small ones. They are fast. That is the whole point of them being small.

---

Try this: review a real diff (the five beats, walked through)

Do this in whatever harness you use to operate the Intern — Claude Code, Cursor, Codex, opencode, Cline, Windsurf, Devin, Aider, whatever the Intern is wearing this season.

Take the last diff the Intern produced — or, if you have not delegated yet, delegate the truncate task from Directive 01 and use that diff. Walk it through the five beats, right now.

Beat 1 — File list check (1 minute). Open the diff. Look at the list of changed files. Did the Intern touch only the files you named? If there is an extra file — and there might be, because the Intern considers “relevant” to be a very broad category — stop here. Send it back: “Revert changes to [file]. Only [named files] were in scope.” Do not read the code yet. The file list is the cheapest gate.

Beat 2 — Logic review (2 minutes). Does the change do what the brief asked? For the truncate example: does the function return text unchanged when under the limit? Does it append … when over? Does it handle the exact-at-limit case correctly? Read the implementation against the brief, not against what the Intern thought you meant.

Beat 3 — Scope-creep audit (1 minute). Did the Intern add anything you did not ask for? A helper function? A comment block? A “small refactor” of an adjacent function? An import reorganization “for clarity”? Each of these is scope creep. Each gets its own redirect: “Remove the [thing] you added. It was not in the brief.” The Intern will not argue. It will comply. It may even thank you.

Beat 4 — Test review (1 minute). Read the tests before the implementation. Do they assert exact values (toBe('hello')) or weak assertions (toBeTruthy, toBeDefined, not.toThrow)? For each weak assertion, redirect: “Change toBeTruthy to assert the exact expected value.” The tests are the spec; a weak spec makes the implementation unreviewable.

Beat 5 — Merge or redirect. If all four beats passed, merge. You have now reviewed a diff in 5 minutes. That is the target. If any beat failed, send the redirect (one specific fix per defect), wait for the new diff, and run the five beats again. The loop is not slow; the loop is the thing that makes the Intern fast without making it dangerous. The Intern would like a sticker.

Time yourself. Write down how long the review took. After five reviews, you will see the pattern: the first few take longer because you are learning to read diffs the Intern’s way. By review five, you are at 5 minutes. That is the throughput that makes the Intern worth the trouble. If you cannot get to 5 minutes, the tasks are too big. Decompose harder. The review time is the diagnostic.

---

Quick Reference (non-comedic, copy this to Notion)

The mindset: review is the work, not a courtesy. Every Intern diff is a proposal, not a deliverable. Until you review, it does not count.

The five-beat review loop:

1. Did it touch only what I asked? (file list check — 1 minute)
2. Did it do the thing I asked? (logic review against the brief — 2 minutes)
3. Did it do anything I did not ask? (scope-creep audit — 1 minute)
4. Do the tests actually test the behavior? (assertions — 1 minute)
5. Merge or redirect with specific, narrow fixes.

How to read a diff fast: file list → tests → skim for additions → read for logic. Two passes beat one.

How to redirect: specific, narrow, one defect per instruction. “Revert email.ts, assert result.name === 'Ada', remove withRetry.” Never “clean it up.”

When to stop redirecting: if the third attempt is worse, the brief is the bug. Rewrite the brief, restart the task.

The cost math: skipping review saves ~5 minutes and costs ~10 min to 4 hr later. Skipping review is the worst ROI in software.

The throughput target: 5-minute review for a 5-minute task. If you cannot hit it, decompose harder.

Version stamp: Written July 2026. The tools will change; the review loop is the moat. We’ll update this when a harness ships a review mode that catches Intern additions automatically.

Compliance Checkpoint

Confirm you actually read this directive. The Overlord knows.

1. After delegation, what is your primary job?

Writing the code. Reviewing the code the Intern produced. Waiting for the Intern to finish, then merging.

2. When should you stop redirecting and rewrite the brief?

After one redirect. When the diff keeps coming back wrong because the task itself is broken — close it and start over. Never — keep polishing the diff until it works.

Submit answers

Also in this Campaign

Recruit

Directive 02: The Art of the Tiny Task

Overlord's Guides — Series 1: Surviving Your AI Intern

Operative

Directive 04: Context Is a Budget, Not an Ocean

Overlord's Guides — Series 1: Surviving Your AI Intern