Skip to content

Course · Codex · Rules (AGENTS.md)

Write rules Codex follows instead of rules it ignores

You know where a rule should live and what living there costs. None of that matters if Codex reads the rule and doesn’t act on it - a well-scoped line that’s too vague to follow is still 0 tokens well spent, because it changes nothing. Because AGENTS.md is guidance - prose the model reads and interprets, not a config flag it’s mechanically bound to - two rules that look equally reasonable on the page can land very differently. One changes Codex’s behavior every session. The other gets skimmed and forgotten. The difference is almost always concreteness, and now you have the numbers to prove it’s worth caring about.

Remember the number from two lessons back: the AGENTS.md you wrote costs roughly 284 tokens, paid every session, whether or not that session ever touches money. Now price the other side of the trade - what a single reintroduction of the float-money bug costs when the rule isn’t there to stop it. Finding it means reading the file where it lives; budgetcli’s models.py is 340 lines, which is 3,400 tokens by this course’s code estimator. Add the turn that reads it and finds the mistake, and the turn that fixes it once found - two turns disappear into a bug that a single sentence would have prevented from happening at all.

Do the division. 3,400 tokens against 284 is roughly 12 times the file’s one-session rent - and that’s for catching it once. Monday’s onboarding run didn’t catch it once. It reintroduced the same bug three separate times before the job was done, which is 3 × 3,400 = 10,200 tokens spent re-finding a fact that a 32-line file states once. That’s roughly 36 times what the file costs to carry for that entire day. Same number, arrived at twice: pay 284 tokens a session, or pay thousands the moment the mistake resurfaces - and on budgetcli, this week, it resurfaced three times before you’d even written the rule down.

That ratio is real, but it isn’t universal, and it’s specific to this rule, not to rules in general. The trade is this lopsided because the mistake is expensive to re-find - a whole file re-read, a wasted turn, a fix turn - and cheap to prevent - one sentence Codex reads before it ever gets the chance to guess wrong. A rule that only prevents a mistake Codex was never going to make earns nothing; you’d be paying rent on a fact that was never load-bearing. The ratio is a property of the rule, not a property of the file - which is exactly why the rest of this lesson is about telling a rule worth its rent from one that isn’t.

The rules that land share a shape: specific, verifiable, and particular to budgetcli. Each one you could check afterward. Look at how the money rule reads when it’s written to be followed versus written to be ignored:

# Ignored - vague, nothing to act on
- Be careful with money values.
- Handle currency correctly.
# Followed - concrete, gradeable
- Money is integer cents. A $10.00 charge is the integer 1000.
- Never divide by 100 in business logic; format to dollars only at the API boundary.

The second pair tells Codex exactly what to type and exactly what not to. You could grade a diff against it in seconds. The same upgrade applies across the file:

  • The domain fact that bites, with the value. “Money is integer cents - $4.99 is 499” beats “money is stored carefully.” The agent can’t infer it and gets it wrong without it.
  • The exact command, not the gist. “Run pytest before committing” beats “test your changes.” A command Codex can run verbatim beats an instruction it has to interpret.
  • The closed list, stated as closed. “Categories are exactly these eight; invent none” beats “use sensible categories.” Naming the set and forbidding additions is what stops the phantom "dining".
  • The thing it must never touch. “Never write to ledger.db directly; go through the repository layer” - a guardrail Codex would otherwise trip over.

The tell of a good rule is that it’s gradeable. If you couldn’t write a test or eyeball a diff to confirm Codex obeyed it, it’s probably too vague to obey - and a vague rule doesn’t just fail to help. It still charges the same 284-token lease on the lines around it, for nothing.

The entries to keep out are the ones that feel responsible but move nothing:

  • Generic best-practice filler. “Write clean code.” “Follow best practices.” “Handle errors properly.” Codex already aims for these; the words just spend tokens.
  • Anything the code already states. The framework, the language, the directory names - Codex reads those from the repo. Don’t transcribe budgetcli into the file that describes budgetcli.
  • One-off task notes. “We’re refactoring the CSV importer this week.” True for a week, then it’s stale context misleading every session after. If it isn’t a standing fact, it’s not a rule.

The honest test for any candidate line: would I have to tell a new teammate this, and will it still be true in three months? Yes to both - it’s a rule. Vague, obvious, or temporary - leave it out. You’re curating, not dumping.

The arithmetic holds for any repo, not just budgetcli. Seven candidate lines from another project - toggle each one in and watch the ledger decide which ones would actually have paid for themselves this week:

Seven candidate lines for your rules file. Toggle each one in and see whether it earns its slot over a week of sessions.

always-loaded cost480 tok/weekre-teaching avoided5.6k tok/weeknet+5.1k tok/week

Net positive - but 1 line is paying rent with the durable facts’ savings. Cut the amber ones; the ledger only improves.

Numbers are illustrative - the ratios are the point: a re-teach cycle (wrong attempt, correction, redo) dwarfs the line that prevents it. Assumes 10 sessions a week, the file loaded at the start of each.

You now know what to write, where to put it, how to phrase it so Codex follows, and roughly what a good one is worth. What none of that tells you is what the file can’t do - the size it can silently exceed, and the line you must never cross: treating guidance as if it were a security boundary. That’s the final lesson of the chapter.