TECHNICAL MEMORANDUM                                          TM-26-006

SUBJECT:      Every rule the agent follows began as an incident
DATE:         2026-07-18


SUMMARY. Seven weeks of building a product with an AI coding agent
left behind a set of written working rules. Reading their history
back, the pattern is plain: nearly every rule traces to a specific
incident, most were written the same day, and the week with the most
rules was also the most productive one. Rules cost the incident that
motivates them; paid once, they stay verifiable and reusable.

1. BACKGROUND. Three of us are building a bootstrapped product; one
developer (me) pairs with an AI coding agent daily. The agent
works under written rules: a conduct file per repository, plus its
own notebook of lessons it keeps between sessions. After seven weeks
I went back through the version history of every rule file and the
recorded sessions to see where each rule actually came from.

2. FINDINGS.

   2.1 Nearly every rule has a nameable trigger. A stray commit
   landed on the wrong branch because shell state did not persist
   between the agent's tool calls; the same day, a new rule: absolute
   paths in every git command. A deprecated platform API slipped past
   a review; the next rule: external claims are verified against
   official documentation, with URL and date, never from memory.

   2.2 Rules change behavior fast. The risky git pattern ran 15 to 18
   times a day before the rule. On the day the rule was written the
   safe form outnumbered it 73 to 9. The day after: zero.

   2.3 Stable rules get promoted: habit, then written rule, then
   script, then automation. Our ticket-housekeeping scripts went from
   0 to 156 invocations per week in the week after they appeared;
   hand-edited schedule dates disappeared once a scheduler owned
   them.

   2.4 Version 1 of a rule is a draft. The busiest rule file was
   edited six times in one day before it settled. That is not churn;
   that is the fitting cost of a rule that will actually be followed.

   2.5 The rules seeded on day one (run the tests, verify before
   commit) are the only ones that never produced an incident. They
   held at the same rate in every week of the project. Everything
   learned later was paid for in kind first.

   2.6 Discipline did not tax delivery. The human veto rate stayed
   near 1% of the agent's actions while weekly volume grew ninefold,
   and the most rule-governed week was the highest-delivery one:
   eleven work items closed on a single day, a production deployment
   brought up in two.

3. ASSUMPTIONS. One team, seven weeks: correlation, not a controlled
experiment. But the direction is consistent across every phase, and
the two side projects tell the same story - there too, the rule files
read like incident logs. My favorite: a background audio capture left
the desktop's microphone indicator permanently lit, and the rule
"verify everything the system now does differently, not just the
result you asked for" was written the same day.

4. CONCLUSIONS. Rules cost the incident that motivates them, so the
predictable ones - verification, hygiene - are worth writing before
any incident; they were the only free ones. For the rest: write the
rule the same day, and record the incident in the rule, because the
why is what makes it stick. Treat a new rule as a draft and expect
rewrites. When one stabilizes, make it executable; a validator does
not forget. The durable outcome: whatever moves into rules and code
is consistently verifiable and can be applied when needed instead
of re-derived in conversation. That is the out-of-session state
the cost analysis (TM-26-005) calls for, and it is what removes
the churn.

5. ACTION. The day-one list we would seed on the next project: an
orientation map the agent reads first; conduct rules (do not assume,
ask; do not over-engineer, reuse); verification before the first
commit; one agreed home for every kind of decision. Then let the
incidents write the rest - one rule per scar, same day.