A fast engineer with no memory
The one mental model that explains every rule that follows
Imagine a colleague who has read every manual, types at four hundred words a minute, never gets tired, and forgets everything the moment they leave the room.
Every morning they walk in fresh. They do not remember yesterday’s decision, the bug you fixed together, or that you hate semicolons. They will do exactly what is written on the whiteboard, brilliantly, and nothing that is not.
That is a coding agent. Hold this picture and most of the practice becomes obvious rather than arbitrary.
What follows from “fast”
Fast means the agent will do more than you asked if the ask was vague. “Clean this up” becomes a refactor across nine files. “Make the header look right” becomes a new design system. The fix is not to slow it down; it is to bound the task the way you would for a very eager new hire: name the files, name the outcome, say what not to touch.
Fast also means it will go a long way down a wrong path before you notice. The lessons in Part 3 are about building checkpoints that catch a wrong path cheaply: a screenshot, a test that encodes a rule, a curl against the live site.
What follows from “no memory”
Nothing you told it last week exists unless it is in a file it reads at the start. That is why every project here has a constitution file, why every app carries a state file with a “next step” line, and why the machine keeps a task board that says what every in-flight branch is for. None of that is documentation for humans. It is memory for the colleague who forgets.
It also means two sessions can start the same task without knowing about each other. That is not a hypothetical; it happened enough times that “check the task board first” became step zero of every session.
What follows from “does what is written”
The agent is literal in a way that is easy to forgive and hard to remember. If the constitution says “dev servers bind to localhost” it will bind to localhost, even though you test from a phone and have said so out loud a dozen times. The fix went into the file: bind to the LAN, own a fixed port, report the LAN URL. The day after it was written, it stopped being a problem.
The rule of thumb: anything you have corrected twice belongs in a file. The first time is noise. The second time is a pattern, and the file is cheaper than the third correction.
Why not just paste the whole history into every session?
Because context is finite and expensive, and because history is mostly noise. A memory file that says “dictation latency doubled when a remote health probe ran on the transcribe path; never put a blocking remote call there” is worth more than the two-hour transcript that produced it. The skill is compression: what changed, why, how to apply it. Part 6 covers the three layers this ends up in.
The part people skip
The colleague is not a junior. They have read more code than you ever will. What they lack is not skill; it is your context: which tradeoffs this project has already made, which files are load-bearing, what “done” means here. Treat them like a junior and you will over-explain the language and under-explain the project. Reverse that.
Fast, forgetful, literal, and widely read. Write down what only you know, bound what you ask, and check what comes back. That is the whole job.