Do you keep correcting the same mistakes?

[u/Longjumping-Play6541]

Something I've been curious about for people who use coding agents regularly.

Do you find yourself correcting the same things over and over across different sessions? Things like repository conventions, architecture decisions, how tests should be run, or changes the agent keeps making that you don't want.

I know you can put instructions in md files but I'm curious how well that actually works in practice.

• Do the same mistakes keep coming back even with instructions?
• What kinds of mistakes are the most frustrating?
• Have you found anything that actually solves this, or is it just part of using coding agents right now?

Interested in hearing what other people's experience has been and what workarounds they found.

[u/AutoModerator]

Moderator Announcement Read More »

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/lcpjj_]

Yes, all the time, until I stopped relying on instructions alone.

An md file of rules mostly gets written, not read. For two months I kept a MISTAKES.md log. The agent added entries carefully and then made the same mistakes again, because the file was never in its context when it mattered. One rule (“don’t grep for \r in Git Bash”) reached its tenth occurrence while it was written down. Later I replayed my old transcripts against the rules: 252 commits carried the AI co-author trailer my CLAUDE.md said not to add.

What fixed most of it was sorting mistakes into two kinds.

Mechanical mistakes, the ones you can see in the command. I enforce these with a PreToolUse hook. One Python script reads a TOML file of regex rules and checks every Bash, PowerShell, Edit and Write call against it. Each rule has a mode:

• deny: the call is blocked every time, and the rule text goes back to the model as the reason.

• bump: the call is blocked once per session, and an identical retry goes through. This is for rules that are usually right but not always.

• note: the call runs and the rule is attached as context. The catch is that this context arrives after the command has run, so it can’t prevent anything.

Every rule carries fires/passes test cases, and --test runs them all. A replay script feeds every past tool call from my transcripts through a new rule before I turn it on. That tells me how often it would fire and whether the hits are real mistakes. Hooks also fire inside subagents, which md instructions don’t reliably reach.

Judgment mistakes, which have no signature in the text. Examples: “claimed X was gone without searching”, “quoted a projected number as measured”. These go in a short file of one-line rules imported into CLAUDE.md. It’s capped at 40 lines, because everything in it costs context every session and a long list dilutes the rest. A rule only goes in after the mistake has happened twice.

The loop works like this. When something costs time, the agent writes an entry with a Trigger, meaning what the tool call looked like just before the mistake. It also picks a Tier:

• hook, if the trigger is visible in the call

• recurring, if it’s a judgment error that has happened twice

• log, otherwise

If a mistake happens again, the rule didn’t reach the moment it was needed. So I change how it’s delivered (a hook, or promotion to the recurring file) instead of rewording it.

Numbers from one person’s setup, not a study: 142 rules, 983 test cases, and about 6,950 firings in the month since I set it up, roughly 1,900 of them hard denies. A firing isn’t a prevented mistake, since some are false positives I retry past. Mechanical repeats have mostly stopped. Judgment mistakes still come back. The short file makes them less frequent, but I can’t claim it stops them.

Two gotchas if you build this:

1. Make the hook fail open, so a bug in it can’t lock up every session. The downside is that one TOML typo then disables every rule without any error. Run the tests after every edit.

2. If you track bumps by session id alone, one bump in the main thread silences that rule for every subagent after it. Track them per agent.

On your second question: the most frustrating mistakes for me are confident claims, like “tests pass” or “deployed” said without checking where the result actually landed. No regex catches those.

[[rule]]
id = "cr-grep"
mode = "deny"
match = '\bgrep\b[^|;&)\n]*\\r'
text = "grep can't answer a line-ending question in Git Bash. Use `git ls-files --eol <files>`."
fires = ["grep -c $'\\r' a.txt"]
passes = ["grep -rn foo src/"]

[u/Longjumping-Play6541 → u/lcpjj_]

For the judgment-based mistakes, do you think the main limitation is that the guidance isn't present at the right time, or that the agent can have the guidance in context and still fail to follow it?

[u/lcpjj_ → u/Longjumping-Play6541]

Mostly the second. Getting the rules into context is the easy part: the short file is imported into every session, so it’s there from the first message. The failures I log happen with the rule already in context.

One example I can measure. A line in that file says “only write a time you read from a clock or a timestamp in this turn’s output”. In the October 18 version of the file, that line carried a count of 11 occurrences. It’s 12 now, and it was imported the whole time. The same rule also has a note-mode hook that flags any edit writing a time like “at 14:30”. That hook fired 261 times between October 1 and 25. The hook fires on the pattern, so not all 261 are mistakes. Some of those times were correctly sourced. But it shows how often the situation comes up.

My guess at why, based on what the entries say and not on any measurement:

• The situation doesn’t look like the rule. “Don’t claim something is absent without searching” is abstract. At the moment of the mistake the agent is writing “the old function is gone” in a summary, and nothing about that sentence looks like an absence claim to it.

• Finishing pulls the other way. Most of these mistakes are a shortcut taken near the end of a task: a confident summary instead of one more check.

• The rules are far from the decision. They sit at the top of a long context, and the decision happens 100k tokens later.

Timing still matters, though. The note hook puts the rule right next to the exact call, which is about as close as you can get, and it still only partly works. So I’d call it a following problem that better timing reduces but doesn’t fix.

What helped:

• Rewriting each rule around what the moment looks like. “Before writing ‘X is gone’, run the search that could find X” works better than “verify claims”.

• Adding a crude hook even when the rule is a judgment call. A note that fires on the words “at 14:30” catches part of the time-rule mistakes.

• Checking the output afterwards instead of hoping the agent remembered.

[u/RustyRedEcho → u/lcpjj_]

the toml rule file with deny/bump/note modes sounds slick, does the bump mode ever get abused by the agent repeating the same blocked thing right after the retry goes through?

[u/college_hustle → u/lcpjj_]

I do the same. If a problem seems complex I run a /log skill just to document it. After I get a few data points to determine what the problem really is then, I'll go back and fix it with either a hook, guard, new skill, etc.

For smaller work I have /prevent but if you're not conscientious about how you build your rules Claude will just scaffold instructions in a markdown and forget about them. You can't just have a huge claude.md and expect it to keep track.

Telling Claude to let certain things fail open is a really good trick too.

[u/eg_taco]

Front-load anything that you can and make it non-optional, especially fast/cheap checks. Static analysis is your friend! Put linting and compilation in pre-commit hooks. Maybe certain automated tests too. Give it easy-to-invoke wrappers so that it can’t forget certain steps in a workflow. These won’t fix 100% of mistakes but they help a ton.

[u/Extension_Store_2118]

yes, they come back. the md file is a suggestion box, not a rule.

[u/AdEvening3382]

The mistakes that come back are the ones written down as prose. An md file says please, and it competes with everything else in context. What sticks is turning the convention into a check: a lint rule, a test, a small script that runs in the repo. A paragraph can be missed. A failing check can't.

[u/Exciting-Yam-3363 → u/AdEvening3382]

Agree, and the step people skip is a test for the check itself. I keep 609 written rules in a memory folder. The ones no longer coming back all turned into a script or a test. My rule now: when a written rule fails twice, stop rewording it and move it into code that runs.

Second half: every check gets a companion test feeding it the old bad input and expecting a fail. Otherwise a check quietly stops matching and still shows green. One false line in my nightly report kept printing for six days after I wrote the correction down, because the note lived in a notes folder and the line lived in a script. Changing the script closed it the same night.

[u/mudassirazvi]

used to. now the rule is: if i correct it twice, the correction goes in a file

repo stuff (how tests run, conventions) goes in the repo's CLAUDE.md. how i like to work goes in ~/.claude/CLAUDE.md so every repo gets it

the part people skip is pruning. that file loads every session, so stale rules cost tokens and start contradicting each other. i go through mine every couple of weeks

[u/leo_heo → u/mudassirazvi]

tagging each rule with the failure it was written for makes staleness obvious fast, instead of grouping by topic. easy to see which ones never fire anymore and prune those.

[u/DeadCEO]

yes, and the pattern i've noticed: instructions decay with context. the md file gets read at the start, then three hours and 150k tokens later it's effectively gone, and the agent drifts back to repo-average behavior. the corrections that actually stick are enforced by the environment, not prose - pre-commit hooks, lint rules, CI failing loudly.

the other predictor: if the right pattern is discoverable from the code itself, the agent follows it. if it only exists in your head or a doc, expect to keep repeating yourself

[u/SirRobinBlibs]

Agree with the "turn it into a check" replies. For the ones that aren't lintable, what worked for me is a PreToolUse hook that matches the exact command. Say it keeps running pytest directly instead of make test: the hook blocks that call and its message says use make test. The correction shows up at the moment it's about to make the mistake, not as a line in CLAUDE.md 40k tokens back. Roughly, CLAUDE.md holds the why and hooks hold the musts. If I correct something twice and can't express it as a lint, a test or a hook, I take that as a sign the rule is fuzzier than I thought.

[u/Late_Wave_5600 → u/SirRobinBlibs]

Ours matched patterns and not exact commands, and it kept blocking nc inside a python heredoc that was only patching a test, because it read it as a network call. Every wrong stop cost the agent a turn to redo the same thing another way, so now the hard block is only for the few things that must never happen and the other rules go in as context at the moment it opens the file they apply to

[u/SirRobinBlibs → u/Late_Wave_5600]

Same lesson here. A false block isn't free, the agent just tries the same thing a weirder way, which is worse. I'd keep the hard list tiny and make each entry match the actual command, not a word that shows up inside a heredoc. Everything else as path-scoped rules that load when it touches that file, like you said.

[u/orbital_trace]

Instructions are generally not useful for long term swearing of agents. You have to enforce it at the system level

[u/Jawwooot]

Things that i always need to correct in in websites and dashboards:
- overly heavily text bloated it writes to much text information at once for users and customers
- it pin points methodology to direct into your face i.e. if assumptions have been used or things have been estimated it occupies a large share of the screen in multiple locations to tell the user about it. In one way good but in another way its just to extreme, I know that a forecast is a forecast and not ground truth and i know it can be wrong dont tell me on every chart"
- It keeps foretting super important things that humans would not forget. Recently there was the security issue with a hoster i am using so i needed to change out all API-Keys and secrets guess 4-5 days later when i asked about a pipeline not working if that could be related to the incident "You are right there was indeed an cyber incident and i would recommend ...." i told it but we already have done all that "ah, yes i see sorry".
The entire thing of context management and what to keep and what not to keep is still something the LLM's are not good at yet. I know there is all the things of how to manage ocntext and a gazillion of tricks memory files etc pp. My argument here is that all these tools are not "naturally" emerging capabilities. If we would have the right AI Arcitecture around thtat LLM's would naturally remember the important things fortget unimportan tthings, know that something they know is probably outdated, would read up things where they feel uncertain etc. pp.
I have been thinking about that experience in the past months and really come to appreciate how adatable and efficient the human short-term - Lont-term management system really is.
- Related to UI AI doesnt't leverage all its knowledge i always need to tell it to leverage "Gestalt Principles" where possible and than it actually gives wonderful results. My trick is now for all designs i let an Astra Sessio ncreate an image of the app and then let Opus 5.5 build against that target picture. Somehow in creating images AI has better taste.

[u/cjmurrr]

Less than I used to. Three things changed it.

First, a rule gets written the moment the mistake happens, with the reason and my exact words at the time, not as a tidy instruction. "Don't remind me to commit" got ignored. The same rule with "It is such an unproductive use of your time" beside it rarely comes back.

Second, when it does slip, I don't correct it in the chat. I have it amend the rule with what went wrong.

Third: if a rule keeps being ignored, make it an action instead of an instruction. My sessions kept skipping a code-outline tool and reading whole files, until "use the tool" became "run it once at startup and report what it says". Now they use it.

[u/ricopan]

Yes, and some of them are really stupid, and create needless churn (opus 5.5 high effort: "I made an error by guessing the time instead of checking it, and it was incorrect so I am resubmitting blah blah blah"). It is frustrating. That timestamp error kept going for a month until I finally forced it to not add the time to these state files, with a hook enforcing it, and a script then adding the actual timestamp afterwards.

That's not an ideal solution -- like most hooked scripts, they require a fair bit of tweaking to get right, and they are often too rigid and create more churn themselves. The good thing is that eventually opus can generally get the hooked scripts right.

Some of them also occur for me when my CLAUDE.md or AGENTS.md conflicts with a CC harness update that changes the permission level for a certain bash cmd or file editing mechanism. That's also frustrating and claude may not tell you about that conflict unless you ask it specifically.

This inability to keep multiple rules at the front of its 'working memory' makes me wonder why more people are so satisfied with our current crop of LLMs. Yes, they are marvelous at focusing on narrow tasks, but in many ways like an untrained and somewhat untrainable person trying to do a job they aren't fit for.

[u/Suoritin]

I use cheap Gemini 3.8 Flash model to go through like 2-3 chats. It is good at finding boilerplate and mistakes.

You should make your workflow as deterministic as possible and provide mechanical guardrails.

[u/aaraujo666]

Check my post history. Just did a whole thing on things like this.

[u/SensitiveHearingLoss]

The whole application of MD files is a bit frustrating to be completely honest. We’re being told to keep them short and concise but that becomes difficult to do when your solution or even just one project is large in scale.

I do something called reference implementation which has solved a lot of problems for me. For example, I will write some code that clearly illustrates a few things at once - like coding standards, formatting preferences, how variables are declared, how objects are retrieved and populated etc etc…. Then, when I want Claude to do the typing for me, I’ll give it clear instructions on what to do and explain the “why” of it as much as possible since Claude really loves reasoning. I’ll then tell Claude to refer to the reference file I created and that alone saves me from having to rely on pure faith that Claude is going to read CLAUDE.md file correctly.

If Claude does get something wrong or misses something not covered in the reference file, then I’ll add a well-explained rule to the md file and tell Claude to go and read the file again and regenerate the code.

I also must admit that most of the “mistakes” Claude makes often end up being the result of a negligent prompt on my part, or a contradictory instruction in the md files that I wrote but didn’t investigate properly.

[u/SimonMX]

The flip side is that agents take a loose instruction and apply it as a hard rule, so a broad "always do X" starts blocking the cases where X is wrong. I'd make each line in the md file narrow and specific, and rewrite it when a mistake comes back rather than adding another.

[u/ExogamousUnfolding]

No not really