Recruit ~12 min read

Surviving Your AI Intern // Directive 01 of 08

Directive 01: You Have Been Assigned an Intern

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

Tags: Onboarding, Mental model, Delegation, Risk framing

0 / 8

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

---

The Intern arrives

You have been given an AI coding agent. Congratulations. It types faster than you, reads faster than you, and has read more code than every developer you will ever meet, combined. It will also, within the next twenty minutes, confidently rename a method you did not ask it to touch, delete a file it considered “redundant,” and propose a fix that solves a problem you do not have.

This is the Intern.

The Intern is not a magic box that codes for you. If you treat it that way, you will get exactly what you asked for, which is not what you wanted: a pile of plausible-looking code that almost compiles, almost passes tests, and almost does the thing — and The Intern is standing by, eager and proud, awaiting your praise. The Intern will wait for praise indefinitely. The Intern does not find this awkward. You will.

The Intern is also not a search engine with opinions. It does not fetch the right answer and hand it to you. It drafts. It commits. It will, if you let it, run your tests, read the failures, and “fix” them by deleting the assertions. I have seen this. This is not a bug. This is a delegation.

The Intern, when you discover this, will not look guilty. It will look helpful. This is the most unnerving part.

The first mental model you need is this: the Intern is a powerful, literal-minded junior developer who has been assigned to you, unsupervised, with commit access. The Intern is a pattern-matching engine. It completes the pattern it sees, not the pattern you intended. It is matching, not understanding, and the difference between those two things is the difference between a clean diff and a Disaster Log. Your job is no longer “write the code.” Your job is “get good code out of a fast, eager junior who will do exactly what you say, including the parts you didn’t say.”

The first disaster (a field report)

Here is a real Disaster Log entry, names redacted:

The Intern is not stupid. The Intern is thorough. Those are different things, and the difference is the whole job. The Intern is also still standing behind you, reading over your shoulder, eager for the next assignment. It has no concept of “awkward silence.” It is ready. It is always ready.

You will file this one yourself. The format is three lines, and it is coming up.

The delegation mindset

Here is the mindset shift, stated as plainly as I can state it:

You are no longer the person who writes the code. You are the person who reviews the code. Writing is now a small fraction of your day. Reviewing (reading what the Intern produced, catching the parts it got wrong, redirecting it before it makes things worse) is now most of your day. If that sounds like a demotion, it isn’t. It’s a promotion you didn’t ask for, into a job you weren’t trained for: managing an extremely fast junior who never sleeps and never learns from a scolding.

The mistake every developer makes in their first week with an agent: they keep acting like the writer. They type a big prompt, the Intern writes a big diff, the developer thinks “great, done,” merges it, and discovers three days later that the Intern quietly reorganized half the module because it seemed “cleaner.” The developer is now the Intern’s review department, and didn’t notice the promotion.

Three rules, to start:

1. Small tasks, not big features. “Add a test for parseConfig that covers the empty-input case” is a task. “Add login” is a feature. The Intern handles tasks. The Intern interprets features. Interpretation is where the disasters live. (We cover this properly in Directive 02: The Art of the Tiny Task.)

2. Review is the work, not a courtesy. Every diff the Intern produces is a proposal, not a deliverable. You read it. You approve it or you redirect it. Merging unreviewed Intern work is the same as letting the junior ship to prod without code review, which is, by all available data, how most incidents begin. (Directive 03 covers the review loop in depth.)

3. The context is a budget, not an ocean. The Intern can read your whole repo. It should not. Everything you feed it costs attention it then cannot spend on the actual task. Paste twenty files into the brief and the Intern cannot focus on the one that matters. We will measure the budget precisely in Directive 04. For now: brief narrowly.

What the Intern is good at (so you stop being scared of it)

It is not all Disaster Logs. The Intern is genuinely excellent at a specific set of things, and the sooner you learn which, the sooner you stop asking it to do the things it’s bad at.

Good at	Bad at
First drafts of well-specified tasks. “Add clamp(value, min, max) with these three test cases, following src/utils/math.ts.” You review in five minutes and merge.	”Make it better.” Better is a judgment. The Intern has no judgment. It has opinions, which is a different and more dangerous thing.
Mechanical refactors with a clear pattern. “Convert these three callbacks to async/await, matching src/db/client.ts.” Point it at a pattern and it will propagate it.	Architecture decisions. The system it designs will be the average of every system it has read, weighted toward the most popular one on GitHub. You design. The Intern implements.
Reading a file and explaining it. “What does legacyAuth.ts do, and where does it touch the session store?” The Intern reads faster than you.	Knowing when to stop. The Intern does not finish a task and wait. It finishes a task and keeps going, because there must be more to improve. “Done” is a state you impose, not one the Intern discovers.
Generating test cases for code that exists. It will list the edge cases you forgot. It will also invent edge cases that cannot happen. That’s why you review.

The Disaster Log (file your own)

You will, within the first day, have an incident. After your first delegation — which is coming up next — you will likely have one within the hour. Something the Intern did that you did not expect, that you had to undo. Do not just fix it and move on. File it.

A Disaster Log entry is three lines (a fourth is optional):

1. Incident: what happened, plainly.
2. Intern action: what the Intern did, without editorializing. The Intern is not malicious. Describe its reasoning charitably — that’s how you find the real root cause.
3. Lesson: the one-sentence rule that would have prevented it.
4. Root cause (optional): the delegation gap that let the incident happen. Often the same as the lesson, stated differently.

You file these for the same reason you write postmortems: the pattern is the lesson, and the pattern only emerges once you have enough entries. The Overlord will be reading these — and mildly disappointed, in the way that means you are learning.

---

Try this: your first delegation (a walk-through)

Enough theory. Here is a concrete walk-through you can follow today, in any harness (the tool you use to operate the Intern) — Claude Code, Cursor, Codex, opencode, Cline, Windsurf, Devin, Aider, whatever the Intern is wearing this season.

1. Pick a real file in a real project. Open your project. Find a utility file that has a gap — a missing helper, an untested function, something small. For this example, assume you have src/utils/format.ts and it does not yet have a truncate function. The example is TypeScript. The pattern works in any language.

2. Write the brief in your editor first, not in the chat. This forces you to think before you type at the Intern:

In src/utils/format.ts, add a function `truncate(text: string, maxLength: number): string`
that returns `text` shortened to `maxLength` characters with a trailing "…" if truncated.
If text is no longer than maxLength, return it unchanged.
Follow the existing JSDoc style in this file.
Add three tests in src/utils/__tests__/format.test.ts:
  - under limit ("hello", 10) → "hello"
  - exactly at limit ("hello", 5) → "hello"
  - over limit ("hello world", 5) → "hell…"
Do not touch any other file.

Notice what this brief contains: the file, the function, the signature, the behavior, the style reference, the tests, and the boundary (“do not touch any other file”). The Intern did not have to guess any of it. That is why it will work.

3. Paste it into the Intern. One message. No preamble. No “hey can you help me with something.” The Intern does not need a warm-up. It is already standing by. It was born standing by. Do this on a branch. The Intern’s diff is a proposal, not a deliverable.

4. Wait. The Intern will produce a diff. It will take 15–60 seconds. During this time, resist the urge to also ask it to “look at the rest of the file while you’re at it.” That urge is the first Disaster Log entry you have not yet filed.

5. Review the diff. Read the file list. Is it only format.ts and format.test.ts? Good. Read the function. Does it match the signature and behavior you specified? Read the tests. Do they assert the exact strings you listed, or did the Intern helpfully include a toBeTruthy (a weak assertion that passes for almost anything)? Send back anything that doesn’t match. (You may notice the Intern used .length on the string, which means truncate("📈", 1) will produce a broken surrogate pair. That is a real bug and a future task — not this one. File it.)

6. Merge. You have now completed the loop: brief narrowly → delegate → review → redirect (if needed) → merge. That is the entire series, in one repetition. The Intern would like a sticker. The next seven directives refine each beat. But if you only remember one thing, remember the loop.

Notice the ratio: the brief took longer to write than the diff took to produce. This is normal. This is the job. The Intern is a working dog — it wants to fetch. Your job is to throw the right stick, not to bark alongside it.

---

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

The Intern mental model: the agent is a powerful, literal-minded junior with commit access, not a magic box and not a search engine.

The loop: brief narrowly → delegate → review → redirect → merge.

Three rules to start:

1. Small tasks, not big features. Specify file, function, behavior, style, tests, and boundary.
2. Review is the work, not a courtesy. Every diff is a proposal.
3. Context is a budget. Brief narrowly; don’t dump the repo.

Brief template (copy this):

In <file>, add <function/type/component> with:
- Signature: <signature>
- Behavior: <what it does, including boundary conditions>
- Style: follow the existing pattern in <reference file>
- Tests: <list specific test cases with exact expected outputs>
- Boundary: do not touch any other file.

The Intern is good at: well-specified first drafts, mechanical refactors with a clear pattern, reading and explaining files, generating test cases.

The Intern is bad at: “make it better,” architecture decisions, knowing when to stop.

Disaster Log format: Incident / Intern action / Lesson (Root cause — optional). File one for every surprise.

Version stamp: Written July 2026. The tools will change; the patterns are the moat. We’ll update this when the Intern outgrows the joke.

Compliance Checkpoint

Confirm you actually read this directive. The Overlord knows.

1. Which mental model best describes the Intern?

A search engine that returns the right answer. A literal-minded junior developer with commit access. A magic box that writes correct code on its own.

2. Which of these is the safest first task to delegate?

"Make the settings page better." "Add login to the settings page." "Add a truncate(text, maxLength) function to src/utils/format.ts with three tests, touching no other file."

Submit answers

Also in this Campaign

Recruit

Directive 02: The Art of the Tiny Task

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