Last week you caught it in review: asked to accept prices with an extra decimal place, your coding agent parsed them as floating-point numbers and rounded, and a price of 1.005 was stored a cent short. You explained in the chat that money here is whole cents, never a float. The agent apologised and fixed it.
This morning a fresh session, in a different file, formatted a total with toFixed(2). Same mistake, new clothes.
You scroll back for the conversation where you settled this, and find nothing: that chat ended, and everything you taught in it ended with it.
Your coding agent repeats a mistake because nothing it can read changed after the first time. The model does not learn between sessions, so a fix made in chat ends with the chat. Treat the second occurrence as a bug in your harness: log every miss, add a check that catches the repeat, run it as early as it is cheap, and prove it with a planted defect.
The first time a coding agent makes a mistake, it is the model’s. The second time, it is a bug in your harness. Read “bug” as you would in a tracker: worth investigating, not a verdict that the fix must be a check.
Why can’t the agent learn from a correction?
Each session begins from the repository and the request, and last week’s chat is in neither. Even within one session, early instructions fade in a crowded window, which Anthropic’s Applied AI team calls context rot (opens in a new tab).
From the field. When I began shipping with coding agents every day, at the start-up I co-founded, an agent repeated, within the first few weeks, a mistake I had already corrected in an earlier session: it rewrote a test’s expected value to match its own output. I corrected it again and recognised the feeling at once. It was the recurring review comment, except that the agent forgot in an hour what a team forgets in a year.
That move has its own post and its own chapter, Chapter 6, the book’s free sample.
A rule is a wish until a check enforces it
The usual response to a repeat is a new line in AGENTS.md, which Mitchell Hashimoto describes as one half (opens in a new tab) of engineering the harness. A line asks; it does not check.
The book sorts controls as Birgitta Böckeler does in “Harness engineering for coding agent users” (opens in a new tab): a guide works before the agent writes; a sensor inspects what it produced.
A guide with no sensor fails silently. So pair every rule in your instruction file with the command that enforces it, a pattern the book calls Rules, Not Wishes (P05), in Chapter 3:
Each rule names the check that enforces it.
- Money is integer cents, never floats:
`npm run check:money`How do you turn a repeated mistake into a guard?
The book calls this The Second-Time Rule (P02), in Chapter 2. The first time, fix the instance and log it. The second time, the harness has a bug:
- Log it, asking why until the answer names a gap in your harness.
- Choose a sensor, computational where a script can decide.
- Place it as early as it runs cheaply: edit, commit, build, deploy or live.
- Prove it with a seeded defect: it passes clean and fails with the mistake planted.
- Write down when to retire it, as an observable condition.
For mistakes you cannot afford even once (destructive actions, leaked secrets), treat the first time as the second.
A worked example: float money
Last week’s mistake, reduced to its core:
const cents = Math.round(parseFloat("1.005") * 100);
// 1.005 * 100 is 100.49999... in floating point,
// so this rounds to 100 cents: a cent short.This morning’s toFixed(2) has the same root cause, so it earns a sensor: a script that flags parseFloat, toFixed and decimal literals on lines that handle money.
It passes on a clean copy. Plant last week’s mistake and it must fail, with a message along these lines:
no-float-money: FAILED, 1 problem
- prices.ts:42: parseFloat() turns a money amount into a float.
Fix: money here is integer cents. Parse text with parseCents()
and format with formatCents(). Do not round floats.The Fix line speaks to the agent: told only “unexpected parseFloat”, it will swap in Number() and keep the float. That is The Fix-It Message (P11), in Chapter 5.
When does a mistake not deserve a guard?
Not every repeat earns a guard. Some end in a recorded “no control” because the code was throwaway, others in a clearer requirement or a smaller task. And a check that fires falsely once a week teaches everyone to ignore it. The working rule, until Chapter 12 prices it: a guard must be faster to run than the mistake is to find by hand, and quieter than the people who will read it.
Try it yourself. In the companion repository (opens in a new tab), npm run drill D06 runs this check on Invoicer, a small invoicing app written for the book: it passes on a clean copy and fails on the agent’s float patch. No API key or model is needed.
The next time it happens
Replay this morning with the check in place: the agent reaches for toFixed(2), the check fires, and its message says what to use instead. The lesson you typed into a chat that ended now lives in the repository, where the next session cannot get past it.
Questions people ask
Does adding the rule to AGENTS.md fix it?
Partly: the line is a guide, and it competes with everything else in the session. Keep it, and name the enforcing command beside it.
Which mistakes deserve a guard?
A root cause that turns up twice in your incident log earns one, as does a mistake you cannot afford even once, such as a leaked secret. A one-off, or a guard that costs more than the mistake, gets a written “no control”.
Does this work with Claude Code, Codex and Cursor?
Yes: a check like this is a plain program with an exit code, so it works whichever agent wrote the change. Only the wiring differs; Appendix C of the book covers it for five agents, dated October 2026.
