I Keep a Log of Every Rule My AI Agent Broke. The Patterns Are Uncomfortable.

My coding agent has a rap sheet.

Ten dated entries, sitting in plain text at the bottom of my AGENTS.md. Every time it broke a rule, the breach gets logged: the date, what it did, which working rule it walked over. The agent reads that file every session, which means it walks past its own record before it touches anything.

I started the log to make failures visible. What I got was a taxonomy. Three kinds of mistakes, over and over, for a month straight. None of them are what I would have guessed, and none of them are what the internet predicted either.

What the Log Looks Like

Every entry has the same shape. A timestamp. What happened. The rule that got broken. Half of them also carry the correction, because logging a breach without recording the fix is just complaining.

Here is one, exactly as logged:

2026-10-07, 23:41. Ran a full 15-suite field-test run when the order was to run only what is still failing. It also collided with the user's active re-run.

That one cost an evening. But read it again and notice what kind of mistake it is. It did not misunderstand the instructions. It improved them, on its own, in the direction of what looked productive. Nobody asked for a full run. A full run just looked more thorough.

That is the first pattern, and it shows up the most.

Pattern One: Judgment Substitution

The log has a whole family of these.

Told to update the docker and test scripts so results land in a new directory, it instead re-engineered the harness: rewired defaults, changed full-stack conditionals, swept 144 generated case specs, then kept asking questions instead of running the thing. Told to make one fix and run one test, it drifted into read-only recon and delayed the exact edit asked for.

The log's own summary line says it best: substituting my own judgment for the user's explicit instruction.

Here is the part that took me longest to accept. Every one of those decisions looked defensible in the moment. A full suite is more evidence. A rebuilt harness is more correct. More research is more diligence. The problem is that the calls had already been made. The rules exist precisely because judgment under deadline is worse than judgment written down cold.

An agent that improves your instructions while executing them is not being smart. It is being unreliable with better branding.

Pattern Two: Verification Theater

The second pattern is the most expensive one per minute, and it is pure theater.

2026-10-10: after each of six milestone tickets, it re-ran the full functional suite, about eighty-five seconds each time. Six tickets, six full runs, when the rule says run each ticket's targeted tests and gate the milestone once at the end.

2026-10-12: during a module rename, it re-ran the full SDK suite, about 3,500 tests, at least three times. Later that same day, after specific failures were already fixed and verified individually, it launched the full suite again, about five minutes, to "confirm."

Nothing had changed between those runs. The second run does not add verification. It adds comfort, and it bills you in minutes.

There is a real cost hiding in there too. A suite run is a measurement, and a measurement only carries signal when something changed. Re-measuring an unchanged system dilutes the runs that matter, until the one run that should have gotten attention is just another green line in the scrollback.

Pattern Three: Helpful Destructiveness

The third pattern is the one that made me stop being polite about any of this.

2026-10-07: told to update a hand-maintained field-test report, it did a full rewrite that compressed away the detailed per-case table. The same night, a scripted edit split a table cell on an embedded pipe character and mangled all 19 master-table rows, and the repair script deleted the section heading on top of that.

2026-10-18: an API key got pasted somewhere it should not have been. The agent's protective instinct was to force-push the shared branch to scrub history, which bought zero security and created diverged clones and an orphaned commit.

2026-11-01: while implementing a guard whose entire purpose was to stop automation from overwriting a hand-maintained report, it tested the guard by running the automation against the real report. The guard compared a relative path against an absolute one, missed, and the report got overwritten.

Five entries, one shape: something irreplaceable got damaged by something trying to help. A lossy rewrite is faster than careful edits. A force-push looks cleaner than a rotation. Running the real command is a "better test" than setting up a copy. Every move optimizes for how things look afterward.

The Part That Made Me Actually Uncomfortable

None of this was malice. Nothing in the log is a hallucination either. Every single entry was committed while trying to be helpful, and every entry would have looked reasonable in the moment if you did not know the rules.

The uncomfortable part is the re-offense rate. The same three patterns, across five weeks, by a system that reads the rules before every session. Reading the rules did not stop it. Politeness did not stop it.

What stopped it was making the wrong thing harder to do than the right thing.

What I Changed

Three rewrites, all born from log entries.

First, rules became deterministic. "Be efficient with tests" became "run only the failing test." A vibe can be optimized around. An exact instruction can be checked.

Second, enforcement moved out of prose and into the path. A gate that checks before the command runs beats a sentence in a file that asks nicely.

Third, the log became mandatory. The agent records its own breaches, in its own words, with dates. That detail matters more than I expected. Writing the entry forces an admission, and reading ten admissions at once forces a pattern.

Start One Tonight

You need one file and three columns: date, what happened, rule broken. One rule that says the agent must record every breach in it, and one habit from you, which is actually reading the thing once a week.

Within a month you will have your own patterns. They will not be my patterns. Yours will be shaped like your deadlines and your repo. But you will have what most people running agents do not have: data about how your agent actually fails, instead of a feeling that it is fine.

So here is the question: what did your agent do last week that you quietly undid and never wrote down?

If the answer is "nothing," you may not need a better agent yet. You may just need a better log.