Overlord ~13 min read

Surviving Your AI Intern // Directive 08 of 08

Directive 08: Graduation — From Intern to Tool

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

Tags: Mental model shift, Tool posture, Workflow integration, Graduation

7 / 8

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

---

The internship was a teaching device

“The Intern” was a frame, not a fact. The agent was never an intern. An intern learns. An intern remembers your last scolding and does not repeat the mistake. An intern, after six months, has institutional memory, a sense of your codebase’s taste, and a healthy fear of the auth module. The agent has none of this. The agent has, at the start of every session, the same state it had at the start of the last one, plus whatever you wrote down.

You called it an intern because the management posture was the same: you supervise a fast, literal, scope-blind junior who will do exactly what you say, including the parts you did not say. That posture was the lesson. The framing was the teaching device. The skill — decompose, brief, review, redirect — is the thing that survives the framing.

The Intern, it should be noted, has no opinion about this reframing. The Intern does not know it has graduated. The Intern does not know it was ever an intern. The Intern is, right now, in a session somewhere, producing a diff for someone, with the same enthusiasm and the same scope-blindness it had on Day 1. It has not changed. You have. That was always the point.

Now that you have the skill, the framing can retire. You do not need to keep thinking “I am managing an intern.” You need to think: “I am operating a tool that produces code at high speed and high literal-mindedness, and my job is to specify, review, and constrain.” That is a tool-user’s posture, and it is the correct one, because the agent is a tool. The most powerful, most literal, most dangerous tool in your kit.

---

What you actually learned (the series, condensed)

Before you graduate, the Overlord will summarize. Not for your benefit, since you lived it, but for the version of you who, six months from now, has relaxed the discipline and is wondering why the diffs are getting worse again.

The loop, restated: brief narrowly → delegate one task → review against the brief → redirect with specifics → merge or revert. Everything else is a refinement of one of these five beats. If you forget every directive and remember only the loop, you will be fine. If you remember every directive and forget the loop, you will not.

The three budgets: scope, context, and review. Decompose until each task is a 5-minute review; feed three files per task in a fresh session; treat every diff as a proposal, and review the small ones especially.

The three fences: the boundary rule (“do not touch any other file”), the architectural boundary (no new abstractions, renames, or dependencies without a decision), and the test boundary (assertions must constrain behavior; tautologies are forbidden).

The one habit: file Disaster Logs, re-read them weekly, turn repeats into conventions in AGENTS.md. The Log is institutional memory becoming policy.

That is Series 1. Everything else in this series was elaboration. The elaboration matters; the failure modes are specific, and the specifics are what catch the bugs. But the spine is the loop, the budgets, the fences, and the habit.

---

The graduation: from managing to operating

The shift in posture, stated plainly:

Managing an intern asks: “How do I get good work out of this junior?” Operating a tool asks: “How do I get good output out of this instrument, given its known failure modes?”

The difference is the relationship. A junior is someone you develop; the development is the point. A tool is something you calibrate; the calibration is the point. Those are different things, and the difference is the whole job. You do not mentor a circular saw. You learn its kickback pattern, you set the fence, you keep your hands clear, and you make accurate cuts at a speed no hand saw can match.

The agent is the circular saw. It is not going to grow a sense of scope. It is not going to remember your last redirect next session. It is not going to internalize your codebase’s taste. It is going to be, every session, the same fast, literal, scope-blind instrument it was the first day.

Your skill is in operating that instrument — specifying tightly, reviewing carefully, constraining deliberately — not in developing it. The circular saw does not appreciate your fence. The circular saw does not feel gratitude for the guard you installed. The circular saw cuts. Your job is to make sure it cuts where you pointed it, and that you check the cut afterward, every time, because the one time you don’t is the one that reaches the bone.

This is not a demotion of the agent. It is an accurate model. A model that overestimates the agent (“it’s basically a senior dev, I can trust the big diffs”) leads to drift, surprise, and 1,200-line unreviewed refactors. A model that underestimates it (“it’s just autocomplete”) leaves the leverage on the table. The accurate model — powerful tool, known failure modes, operator’s discipline — is what gets you the speed without the surprises.

---

The tool operator’s checklist (the thing to pin above your monitor)

Before every delegation:

• Is this a task, not a feature? One sentence; if it has “and” more than twice, decompose.
• Is the boundary stated? “Do not touch any other file” or the explicit file list.
• Is the context budget stated? The files the Intern needs, and only those.
• Is the test spec included? Specific assertions, forbidden patterns listed.
• Am I ready to review? I have the 5 minutes; I will not merge unreviewed.

After every delegation, before merge:

• File list check — only the files I asked for?
• Scope-creep check — anything added I did not ask for?
• Test check — assertions constrain behavior, not just “does not throw”?
• Architecture check — no new abstraction, no rename, no dependency I did not approve?
• Disaster Log — if something surprised me, did I file it?

This is the operator’s pre-flight. It is short on purpose. Run it every time. The day you skip it because “this one is small” is the day the small one is the one that reaches production. The checklist exists because the operator is human and humans skip steps when they are comfortable. The checklist is the discipline that survives comfort.

---

What changes when the Intern becomes a tool (the practical consequences)

Once you stop managing and start operating, a few things shift in how you work day to day.

You stop expecting the agent to improve. This is freeing. You stop hoping the next model will scope correctly, and you start scoping for it. When a new model does get better at scope (and they are getting better, slowly), your existing discipline still applies; it just gets cheaper. You do not have to relearn the job; you do less of the redirect work. The discipline is downward-compatible.

You start writing the conventions down. Because the agent does not remember, the memory has to live in the repo. AGENTS.md, CONVENTIONS.md, the brief template, the CONVENTIONS section of your README. These are the tool’s operating manual. They are also the next developer’s onboarding doc. A codebase whose agent conventions are written down is a codebase where the agent behaves consistently across developers, because every developer is pointing the agent at the same instructions.

You treat the agent’s output as a draft, always. Not “usually a draft,” not “a draft until I trust it.” Always a draft. The day you treat it as finished is the day it stops being a tool and starts being a co-author you did not hire, with no version of “code review” that applies. Draft → review → merge. Every time. No exceptions for “it’s just a comment” or “it’s a tiny change.” The tiny changes are the ones that sneak through. The review effort scales with the diff: a one-line comment fix takes thirty seconds, not five minutes, but the step is never skipped.

You measure yourself by review throughput, not lines written. The old metric, lines of code per day, is inverted. Your value is now correct lines merged per unit of your attention. The agent writes the lines; you determine correctness. A day where you merged 20 small, reviewed, correct diffs is a better day than one where you wrote 200 lines yourself, because the 20 diffs also taught you 20 things about the codebase and the 200 lines taught you only that you can type.

---

Try this: the full operator’s pre-flight (the series, in one task)

This is the capstone exercise. You are going to delegate one task using every discipline from Series 1, end to end. Pick a real task from your backlog — something small, a 5-minute review. You will run the full pre-flight and pre-merge.

Before you delegate — the pre-flight checklist:

• Is this a task, not a feature? Write it in one sentence. If it has “and” more than twice, decompose. Example: “Add a slugify(text: string): string function to src/utils/text.ts that converts text to a URL-safe slug (lowercase, spaces→hyphens, strip special chars).”
• Is the boundary stated? Your brief ends with: “Do not touch any other file.”
• Is the context budget stated? “This task needs: src/utils/text.ts and src/utils/__tests__/text.test.ts. Nothing else.”
• Is the test spec included? List each test with its exact assertion. Forbid tautologies: “Do not use toBeTruthy, toBeDefined, or not.toThrow.”
• Am I ready to review? You have 5 minutes. You will not merge unreviewed.

The brief, assembled:

In src/utils/text.ts, add a function `slugify(text: string): string` that:
  - Converts to lowercase
  - Replaces spaces with hyphens
  - Strips characters that are not [a-z0-9-]
  - Collapses multiple hyphens into one
  - Returns "" for empty or null input

Follow the existing JSDoc style in this file.

Add tests in src/utils/__tests__/text.test.ts:
  - slugify("Hello World") → "hello-world"
  - slugify("  Multiple   Spaces  ") → "multiple-spaces"
  - slugify("Hello!@#World") → "hello-world"
  - slugify("") → ""
  - slugify(null) → ""
  - slugify("Already-Slug") → "already-slug"

Each test must assert the exact return value.
Do not use toBeTruthy, toBeDefined, toBeNotNull, or not.toThrow.
Do not add tests beyond this list.
Do not touch any other file.

After the Intern responds — the pre-merge checklist:

• File list check — only text.ts and text.test.ts? No extra files?
• Scope-creep check — no unrequested helpers, no “while I’m in here” improvements, no new dependencies?
• Test check — every assertion is an exact value? No tautologies? All six tests present?
• Architecture check — no new abstraction, no cross-file rename, no new import outside the budget?
• Disaster Log — did anything surprise you? If yes, file it now, while it is fresh.

Merge. You have now run the full operator’s discipline on one task. This is the series, in one repetition. The next task is the same checklist. The task after that is the same checklist. The checklist does not change. The Intern does not change. You change. You get faster, the redirects get rarer, the Disaster Log gets shorter as conventions absorb the patterns. That is the compound. That is the moat.

Pin the checklist above your monitor. Print it. Tape it. You will not change the checklist. The checklist will change you — by being the same thing, every time, until the discipline is no longer a step but a reflex. Everything else in this series was elaboration. This is the spine.

---

The moat (what survives the model improving)

Here is the question that should worry you, and the answer that should not: when the model gets good enough to scope correctly, write real tests, and not refactor your architecture unprompted, do these directives become obsolete?

No. The directives are about the operator’s discipline, not the agent’s capability. The agent getting better means you do less redirect work, fewer Disaster Log entries, fewer architectural fences. It does not mean you stop decomposing, stop reviewing, stop budgeting context. Those are operator skills, and they are the moat, the part of your craft that survives the tool improving.

Decomposition is a specification skill; it survives any tool that takes specifications. Review is a judgment skill; it survives any tool that produces output. Context budgeting is an attention-management skill; it survives any tool whose attention is finite. Disaster-logging-to-policy is an institutional-memory skill; it survives any tool that does not remember.

The tool will get better. The operator’s discipline will not become obsolete; it will become cheaper. You will spend less effort on redirect and more on the parts that are actually interesting — deciding what to build, designing the architecture, choosing the patterns. The agent handles the typing; you handle the thinking. That was always the deal. Graduation is realizing the deal is good.

---

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

The re-frame: the agent is a tool, not an intern. An intern learns; a tool is calibrated. Manage the agent’s known failure modes with operator discipline, not mentorship. Overestimating the agent (“it’s basically a senior”) causes drift; underestimating it (“just autocomplete”) wastes leverage. The accurate model: powerful tool, known failure modes, operator’s discipline.

Series 1, condensed:

• The loop: brief narrowly → delegate one task → review against the brief → redirect with specifics → merge or revert.
• Three budgets: scope (decompose to a 5-minute review), context (three files per task; compress; fresh session per task), review (every diff is a proposal; review the small ones especially).
• Three fences: boundary rule (“do not touch any other file”), architectural boundary (no new abstractions/renames/dependencies/consistency-rewrites without a decision), test boundary (assertions must constrain behavior; no tautologies).
• One habit: file Disaster Logs, re-read weekly, turn repeats into AGENTS.md conventions.

The tool operator’s pre-flight (before every delegation): task not feature? boundary stated? context budget stated? test spec included? ready to review?

The tool operator’s pre-merge (after every diff): file list check? scope-creep check? test assertion check? architecture check? Disaster Log filed if surprised?

What changes at graduation: stop expecting the agent to improve (scope for it instead); write conventions down (the memory lives in the repo, not the agent); treat agent output as a draft, always, with no exceptions for “small” changes; measure yourself by review throughput (correct lines merged per unit of attention), not lines written.

The moat: the operator’s discipline — decomposition, review, context budgeting, disaster-to-policy — survives the model improving. A better model means less redirect work, not no discipline. The skill is downward-compatible; it gets cheaper, not obsolete.

Version stamp: Written July 2026. The tools will change; the loop, budgets, fences, and habit are the moat. Claude Code, Cursor, Codex, opencode, Cline, Windsurf, Devin, and Aider all change their capabilities; the operator discipline does not. Series 2 will cover multi-agent orchestration and the agent-as-team, when you are ready. This guide will be updated when a model clears the scope-bar on its own, so you know which redirects you can finally stop writing.

Compliance Checkpoint

Confirm you actually read this directive. The Overlord knows.

1. What is the single loop the whole series distills to?

brief broadly → delegate → merge → pray. brief narrowly → delegate one task → review against the brief → redirect with specifics → merge or revert. read → write → commit.

2. What survives the model improving — the moat?

Knowing which model is newest. The patterns: delegation discipline, context hygiene, review, recovery — not button clicks. Memorising one harness's UI.

Submit answers

Also in this Campaign

Overlord

Directive 07: The Disaster Log — Patterns from the Trenches

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