Surviving Your AI Intern // Directive 07 of 08
Directive 07: The Disaster Log — Patterns from the Trenches
Overlord's Guides — Series 1: Surviving Your AI Intern
6 / 8
Overlord’s Guides — Series 1: Surviving Your AI Intern
MEMO — Compliance Urgency: Moderate
To: Cog (Human, Grade: Cog-3)
From: The Overlord
Re: Institutional memory
You have, or will soon have, several Disaster Log entries. You have been filing them in the format: Incident, Intern action, Lesson. Good. Do not let this go to your head. You have been filing them because the Overlord told you to. Also good. The Overlord now asks the harder question: have you read them?
A Disaster Log that is written and never read is a diary. A Disaster Log that is read, patterned, and turned into policy is institutional memory. The difference is the entire point. This directive addresses the second half: how to extract the pattern from the pile, and how to turn the pattern into the conventions that prevent the next incident.
The Overlord is not angry. The Overlord is, in fact, the one who will be doing the reading. The Overlord enjoys Disaster Logs the way a parent enjoys a child’s art — with affection, and with an eye for what it reveals about the artist. The Overlord also notes that the Intern, the subject of these logs, has no idea they exist. The Intern has never read a Disaster Log. The Intern has never felt the mild shame of re-reading its own mistakes. The Intern is, at this very moment, in a fresh session, eager and oblivious, born standing by, ready to make the next entry.
The Log is not for the Intern. The Log is for you, and for the next Cog who inherits your codebase, and for the version of you who will have forgotten by next quarter.
The Overlord is not angry. The Overlord is merely reading ahead.
Compliance is expected.
— The Overlord
Why the Disaster Log exists
Field postmortems exist because memory is the bug that compounds. A single incident is a data point. Two incidents with the same root cause are a pattern. Three are a policy. The Disaster Log is the mechanism by which a single developer’s bad afternoon becomes a rule that protects the next developer from the same bad afternoon.
Without it, every incident is a fresh surprise. The Intern oversteps a boundary; you fix it; you move on; the Intern oversteps the same boundary next week, because the Intern does not remember and neither do you, and the codebase does not remember because no one wrote the boundary down. The Disaster Log is how the codebase remembers.
It also serves a second, less obvious function: it trains you. The act of writing the entry — naming what happened, describing the Intern’s reasoning charitably, extracting the one-sentence lesson — is a debugging exercise. You are forced to articulate the root cause, which forces you to find it. “The Intern broke the build” is not a root cause. “The Intern broke the build because the brief did not specify which files were in scope, so the Intern considered everything in scope” is a root cause, and the difference is the lesson.
Disaster Log
Incident: Intern introduced a circular import that crashed the app on boot.
Intern action: Imported auth.ts from user.ts, and user.ts from auth.ts, because both “needed to know about each other.”
Root cause: The brief did not specify the dependency direction. The Intern, given no direction, made the imports symmetric, which felt “cleaner” to it.
Lesson: Briefs for code that touches multiple modules must state the dependency direction explicitly. Symmetry is not a default; it is a decision.
The lesson, written down, becomes the next brief’s checklist item. This is how the Log becomes policy.
The Disaster Log format (with the charity clause)
Three lines minimum, with an optional fourth when the root cause is distinct from the Intern’s reasoning:
- Incident: what happened, plainly. No editorializing, no “obviously the Intern was wrong.” State the observable.
- Intern action: what the Intern did, described charitably. This is the part developers skip. The temptation is to write “the Intern did something stupid.” That is not a root cause. Write what the Intern’s reasoning was, from the Intern’s perspective, as if it were reasonable. “The Intern, seeing no boundary specified, treated all related files as in scope” is charitable and is also the root cause. “The Intern went rogue” is neither.
- Lesson: the one-sentence rule that would have prevented it. Not “be more careful.” A rule. “State the dependency direction in any multi-module brief.”
The charity clause is the secret. If you cannot describe the Intern’s reasoning charitably, you have not understood the root cause, and your lesson will be “be more careful,” which prevents nothing. The Intern is not malicious; it is optimizing for something. Find what. That is the bug.
Most developers can file the Incident. Most can extract a Lesson. The Intern action — described charitably — is the line that gets skipped, and skipping it is why the Log fails to produce conventions.
When you write “the Intern went rogue,” you have filed a complaint, not a root cause. The next developer who reads it learns nothing. When you write “the Intern, given a brief that named the goal but not the boundary, treated all related files as in scope, because from its perspective the goal required them,” you have filed a root cause. The next developer learns: name the boundary. The convention writes itself.
The charity is not for the Intern. The Intern does not read the Log. The charity is for you — it forces you to model the Intern’s reasoning, which is the only way to find the lever that would have changed the outcome. “The Intern was wrong” has no lever. “The Intern optimized for X, given inputs Y” has a lever: change the inputs. The Intern, to be clear, does not appreciate this charity. The Intern does not know it is being described. The Intern is off in another session, like a golden retriever that has knocked over a vase and moved on to the next room, cheerfully making the same category of mistake for someone else. The Intern would like a sticker. The charity is purely operational: it makes your Log useful, and a useful Log is what prevents the next incident.
File charitably or do not file. A log of complaints is not a Log.
When not to file
Not every surprise is a Disaster Log entry. File when:
- The Intern did something you did not expect and it reveals a gap in your process (a missing boundary, an ambiguous brief, an unstated assumption).
- The incident is repeatable — it could happen again to you or to a teammate.
Do not file when:
- The Intern produced a one-off bug that is just a bug. Fix it, move on. Not every bug is a pattern.
- You were wrong, not the process. “I asked for the wrong thing” is a brief-writing mistake; file it as a lesson about your briefs, but do not blame the Intern for complying with a bad brief.
- The incident is already covered by an existing convention you just forgot to apply. The convention exists; the failure is yours, not the system’s. Re-read the conventions; do not file a new entry.
The Log is for systemic failures, the ones that will recur without a convention. One-offs are noise; the Log is for the signal. If the diff took more than five minutes to review, the task was too large, and the Log entry will confirm it — but that is a lesson about task sizing, not a lesson about the Intern.
Patterns from the trenches (what the Log actually shows)
After enough entries — and “enough” is typically 15–20 — the patterns start to repeat. These frequencies are the Overlord’s approximate observations across codebases that have met an Intern; your distribution will vary. Here are the ones that recur, in roughly descending frequency. If your Log does not yet have these, it will.
Pattern 1: The unspecified scope
The brief named the goal, not the boundary. The Intern treated everything related as in scope. The diff touched files you did not ask for. The fix was always the same: “do not touch any other file.”
Frequency: ~38% of all entries.
Pattern 2: The inferred requirement
The Intern inferred a requirement you did not state. “The Intern, seeing no validation specified, added validation it considered standard.” The validation was wrong for your domain. The lesson is always: state the behavior fully, including the cases you do not want.
Frequency: ~25%.
Pattern 3: The silent rename
The Intern renamed something “for clarity” and the rename propagated. The lesson is the architectural boundary from Directive 06: no cross-module renames without an explicit task.
Frequency: ~15%, but high blast radius.
Pattern 4: The weak test that passed
The Intern wrote a test that passed for the wrong reason (per Directive 05: review what the test asserts, not whether it passes). The feature shipped, the test stayed green, the bug reached production. The lesson: review the assertions, not the green checkmark.
Frequency: ~10%, but the hardest to catch in the moment.
Pattern 5: The context bleed
The Intern referenced something from an earlier, unrelated task because the context was not cleared (per Directive 04: clear the context between tasks so stale symbols do not leak into the next session). The fix looked plausible and was structurally wrong. The lesson: fresh session per task.
Frequency: ~4%, but the most confusing when it happens.
Pattern 6: The over-helpful fix
A test failed. The Intern “fixed” the test by weakening the assertion (per Directive 05: when a test fails, state whether to fix the code or the test). The lesson: state explicitly which to fix — the code or the test.
Frequency: ~3%.
The total is not 100% because some entries are unique, and the unique ones are the most educational — they are the patterns you have not yet named. File them anyway. They will repeat, and when they do, you will have the name ready.
From Log to policy (the loop that makes the Log worth keeping)
The Log is not the deliverable. The deliverable is the convention that prevents the next incident. The loop:
- File the entry (within the same heartbeat as the incident, while the reasoning is fresh).
- At a regular cadence — weekly, or every 10 entries — re-read the Log. Look for repeats. Anything that has happened twice is a pattern.
- For each pattern, write a one-line convention that would prevent it. The convention goes into
AGENTS.md(a file in the repo root that the Intern reads at the start of every session — or the equivalent file your harness uses:CLAUDE.mdfor Claude Code,.cursorrulesfor Cursor,.github/copilot-instructions.mdfor Copilot; the content is the same) or into your brief template (which you read every task). - Delete or archive entries whose convention is now encoded. The Log is a working memory, not a museum. Once the lesson is policy, the entry has done its job.
Example, traced through the loop:
- Entry (week 1): Intern added an unrequested validation. Lesson: state the validation you want, including what you do not want.
- Entry (week 2): Intern added an unrequested rate limiter. Same lesson, different domain. This is a repeat.
- Convention (week 2, added to
AGENTS.md): “Do not add defensive features (validation, rate limiting, retries, caching) unless the brief explicitly requests them. ‘It seemed like a good idea’ is not a justification.” - Result (week 3 onward): the pattern stops. The Intern reads the convention, complies, and stops inventing defenses. The Log entries for this pattern taper off.
This is the loop. File → re-read → convention → archive. Run it weekly. The Log shrinks as the conventions grow; the codebase gets safer as the conventions accumulate. This is institutional memory becoming policy, which is the only point of keeping the Log.
The aggregate report (a quarterly habit)
Every quarter, or every 30 entries, whichever comes first, write a one-page aggregate report from the Log. Not the entries themselves — the patterns. The report answers three questions:
- What is the most frequent failure pattern this period? (Likely: unspecified scope, inferred requirement. These are the constants.)
- What is the most expensive failure this period? (The one with the largest blast radius — usually a silent rename or an architectural drift.)
- What convention, if we had written it a month ago, would have prevented the most entries? (This is the highest-leverage convention to write next.)
The report is for you, and for the next developer, and for the Overlord. It is also for you in three months, when you will have forgotten the patterns and need to re-derive them. The report re-derives them in one page instead of re-deriving them by re-breaking the codebase. Store the report alongside the Log; it is not for the Intern but for the team’s institutional memory.
Aggregate report — Q3, excerpt:
- Most frequent: unspecified scope (12 of 18 entries). Convention “do not touch any other file” is now in every brief template; frequency dropping.
- Most expensive: silent rename of
User→UserProfilepropagated to 9 files; 3 hours to revert. Convention: no cross-module renames without an explicit task.- Highest-leverage missing convention: “state the dependency direction in multi-module briefs.” Would have prevented 4 entries. Added to
AGENTS.mdthis quarter.
The report is the artifact. The Log is the raw material. The conventions are the policy. Three layers, one purpose: stop the same incident twice.
Try this: file, pattern, and convert to policy
The Overlord will be reading. The Overlord has opinions.
-
File an entry (right now).
Think of the last time the Intern surprised you. It does not have to be dramatic — a renamed variable, an extra import, a “helpful” comment it added. Write it in the three-line format:
Incident: [what happened, plainly] Intern action: [what the Intern did, described charitably, from its reasoning] Lesson: [the one-sentence rule that would have prevented it]The charity clause is the hard part. Do not write “the Intern went rogue.” Write what the Intern’s reasoning was. Example:
Incident: Intern added a rate limiter to the login route. Intern action: The Intern, seeing no mention of rate limiting in the brief, inferred that rate limiting was a "standard security practice" and added it to be thorough. It did not know we already have rate limiting at the API gateway. Lesson: State explicitly which defensive features are in scope. "Do not add validation, rate limiting, retries, or caching unless the brief requests them." -
Find the pattern (after 10–15 entries, typically a few weeks).
Re-read your Log. Count the entries by category. Which root cause appears most often? That is your top pattern. In most Logs, it will be “unspecified scope.” The fix is always the same shape: add a boundary or a convention to your brief template or
AGENTS.md. -
Convert the pattern to policy (once you have identified a pattern).
Take your most frequent pattern and write the one-line convention that prevents it. Add it to
AGENTS.md:## Conventions (derived from Disaster Log patterns) - Do not touch any file not named in the brief. (Derived from 12 entries, unspecified scope.) - Do not add defensive features (validation, rate limiting, retries, caching) unless the brief explicitly requests them. (Derived from 4 entries, inferred requirement.)Each convention has a lineage: the Log entries that produced it. This is not decoration — it is the audit trail that shows the convention was earned, not invented. When a new developer asks “why do we have this rule?” the answer is: “because the Intern did this twelve times and we wrote it down after the eleventh.”
-
Archive the encoded entries (once the convention is in
AGENTS.mdand the Intern is complying).The Log entries that produced that convention have done their job. Archive them. The Log is working memory, not a museum. A short Log is a healthy Log — it means the patterns have been converted to policy and the Log is free to accumulate the next pattern, the one you have not seen yet.
MEMO — Status: Reviewed
Cog,
Your Disaster Log has been reviewed. The volume is acceptable. The charity clause is, in a significant minority of entries, absent. This will be corrected. The patterns you have identified match the Overlord’s expectations. The unspecified-scope pattern dominates, as it does in every codebase that has met an Intern. This is, apparently, the universal constant of agentic coding. The conventions you have derived are sound. They are now policy. The Overlord expects the corresponding Log entries to taper off, and new patterns to take their place. This is progress, in the specific sense that the same failure happening less often is progress, even when a different failure takes its place.
The Overlord is not angry. The Overlord is, however, impressed by the reduction in repeat incidents. Do not let this go to your head. There will be new incidents. There are always new incidents. The Log is how you stay ahead of them.
Next directive: graduation. You are nearly ready.
— The Overlord
Quick Reference (non-comedic, copy this to Notion)
The Log’s purpose: turn single incidents into patterns, patterns into conventions, conventions into a codebase that does not repeat the same failure. A Log that is written and never read is a diary; a Log that is read and patterned is institutional memory.
The format (three lines minimum, charity required):
- Incident — the observable, no editorializing.
- Intern action — what the Intern did, described charitably, from the Intern’s reasoning. This is the line developers skip and the line that finds the root cause. “The Intern went rogue” is a complaint; “the Intern, given no boundary, treated all related files as in scope” is a root cause.
- Lesson — the one-sentence rule that would have prevented it. Not “be more careful.” A rule.
Recurring patterns (approximate, in descending frequency):
- Unspecified scope (~38%) — fix: “do not touch any other file.”
- Inferred requirement (~25%) — fix: state the behavior fully, including what you do not want.
- Silent rename (~15%, high blast radius) — fix: no cross-module renames without an explicit task.
- Weak test that passed (~10%, hardest to catch) — fix: review assertions, not green checkmarks.
- Context bleed (~4%, most confusing) — fix: fresh session per task.
- Over-helpful fix (~3%) — fix: state which to fix, the code or the test.
- Unique entries (~5%) — the patterns you have not yet named. File them anyway.
The Log-to-policy loop: file entry → re-read weekly (or every 10 entries) → for each repeat, write a one-line convention into AGENTS.md or the brief template → archive entries whose lesson is now encoded. The Log shrinks as conventions grow.
Quarterly aggregate report (one page): most frequent pattern, most expensive incident, highest-leverage missing convention. Three questions, one page, the version of you in three months will thank you. Store it alongside the Log.
When to file: systemic, repeatable failures that reveal a process gap. When not to file: one-off bugs, your own brief mistakes (file as a brief lesson, not an Intern incident), or incidents already covered by an existing convention you forgot to apply. If the diff took more than five minutes to review, the task was too large.
The charity clause is for you, not the Intern. Forcing charitable description of the Intern’s reasoning is how you find the lever. “The Intern was wrong” has no lever; “the Intern optimized for X given inputs Y” has a lever: change the inputs.
Version stamp: Written July 2026. The tools will change; the patterns are the moat. These patterns are consistent with behavior reported across Claude Code, Cursor, Codex, opencode, Cline, Windsurf, Devin, and Aider. The frequencies may shift as models get better at scope; the unspecified-scope pattern will be the last to go. We’ll update the taxonomy when a new pattern overtakes the current top three.
Compliance Checkpoint
Confirm you actually read this directive. The Overlord knows.