When your coding agent repeats a mistake, move the lesson out of chat.

The placement decision is the real engineering work. I would add an expiration or review owner to every learned rule, because repository constraints can outlive the architecture that justified them and then become invisible drag. A useful mistake record should link the failing example, the positive counterexample, the rule or hook that changed, and the regression test that enforces it. That gives the team a way to remove a safeguard safely when the underlying boundary changes.

Judging the setup by what happens when a mistake recurs, not by one good session, is a sharp way to think about agent reliability. The six-place breakdown is useful precisely because it forces the question of where a correction belongs, since piling every rule into agent config is what makes the important instructions get lost. For the mistake-log-plus-regression-test path, how do you keep that suite from growing into something the agent spends more time satisfying than the task itself?

This is a great perspective on moving from “fixing the same mistake repeatedly” to building systems that actually learn from those corrections.

I like the distinction between fixing the current task and improving the system that produces future tasks. That's a pattern that applies well beyond coding agents. Too many teams keep adding instructions to prompts when the real fix belongs in the harness, a reusable skill, a deterministic check, or a regression test. Treating repeated failures as signals to improve the surrounding system not just the model's immediate output is what makes agent workflows scale instead of accumulating more prompt debt over time.

This is a practical way to think about working with coding agents. Fixing a mistake in chat may solve the immediate task, but documenting the lesson in AGENTS.md, adding a targeted regression test, or improving the review process prevents the same issue from returning in future sessions. I especially like the reminder not to turn one failure into an overly broad rule the best safeguards should block the specific mistake without restricting valid solutions.

The "does every session need this" filter for AGENTS.md is the most transferable rule, a hard line-count ceiling forces real discipline instead of "just one more exception" creeping in forever.

"Don't turn one failure into a universal law" is the sharper insight. Requiring both a regression case (rejects the bad example) and a positive case (still passes valid ones) is what stops an overbroad fix like "never use mocks" from replacing a narrower real problem.

Self-review not being independent, even when the agent inspects its own diff, is worth remembering, it already committed to the assumptions behind the output, so grading its own homework isn't structurally the same as a reviewer with no stake in it.

GGreat insight into the importance of community in our lives.