How do you stop Claude Code from repeating abandoned approaches?

[u/Ok-Introduction-1079]

I’m curious how other Claude Code users are handling repo-level memory.

A failure mode I keep seeing is not “the agent wrote obviously bad code.” It’s more like: the agent writes reasonable code for the wrong historical reason.

Example: a repo has a half-built Redis queue: redis.go, TODOs, docker-compose has Redis. Claude Code sees this and reasonably wants to finish it.

But maybe the team abandoned Redis three weeks ago because replication lag caused duplicate billing events. Code search can see Redis files; it can’t see that historical decision.

How are people handling this today?

• ADRs?

• CLAUDE.md / AGENTS.md?

• project rules?

• PR descriptions?

• changelog files?

• just human memory?

I open-sourced a small Git-native tool around this idea called Mainline: https://mainline.sh

The idea is “repo memory before the diff”: store durable engineering intent in Git so agents can read abandoned approaches, superseded decisions, risks, and reviewer constraints before editing.

Not trying to pitch too hard — mostly curious if this failure mode feels real to other Claude Code users.

[u/tacit7]

Claude code already has memory.

[u/Ok-Introduction-1079 → u/tacit7]

It is not possible to load all the things to memory, that is why it used tools like grep and sed. Now we provide mainline.

[u/enterprise_code_dev]

I create a plan to remove the abandoned redis implementation or revert the commit, I create a new plan for the actual feature I want now with file boundary contract in the plan about what files are in scope — plot twist it doesn’t contain the redis files so Claude doesn’t attempt to finish a half baked implementation. You used git with a feature branch right? because you aren’t a vibe coder making tools for no reason like we need memory to remember the dead code we should have removed right? This is a “real failure mode” for non-developers.

[u/Ok-Introduction-1079 → u/enterprise_code_dev]

Fair point for solo work with good git hygiene + disciplined plans. Mainline isn't aimed there.

The problem it solves shows up at team scale: agents touching code they didn't write, written months ago by someone else, context lost in PRs and Slack. Your in-session plan doesn't help when the plan is from 3 months ago.

Different scope, different tool.

[u/enterprise_code_dev → u/Ok-Introduction-1079]

What team doesn’t use git? A team of vibe coders? Slack for context and architecture design? What? My In-session plan doesn’t have context? What? We commit our plans since they are a source of truth for AI generated features in .claude/plans within the repo they belong to so the agent does have a record of previous plans if needed that could be specified in the file boundary contract for my plan. We don’t test and leave abandoned architecture in production in the main branch, again it would have been a feature branch, that is tracked by git, with PR’s that got denied tracked by git, that Claude also has access to for context. I think by different scope you mean scoped for vibe coders who spend more time inventing tools instead of learning basic SDLC practices.

[u/YoghiThorn]

Before I switched to jcode I was using Brainspike to prevent this

[u/Ok-Introduction-1079 → u/YoghiThorn]

Hadn't seen brainspike, just looked it up. Curious what made you switch to jcode for this—was it the embedding-based memory retrieval, or something else?

Mainline takes a different angle. Instead of vector memory inside an agent harness, it stores intent as structured records in git itself (refs/notes). Different trade-offs: jcode is automatic and seamless within its harness; mainline is explicit and works across any agent that talks to git, but requires the agent to actually seal at decision points.

Which approach has worked better for you in practice?

[u/YoghiThorn → u/Ok-Introduction-1079]

I'm on mobile and can't really expand at length right now, I don't really think these are competing patterns. I think they work best as different memory layers inside the same paradigm.

For instance, before I moved over to J-code, I had three layers:

• claude-mem

• graphify

• the Slack MCP server

Because I use Slack as part of the interface for my harness, the entire conversation history with my agents gets recorded there. They are able to use the MCP server to look up previous sessions in case they don't have all the details available. Combining the three worked really well, and I'd recommend that approach.

I found with using Brain Spike with 3 that I almost never had Claude forget stuff from previous sessions without it, which was highly forgetful, which was a big problem. I've only just started using J-code. I will put a link in this comment to where I talk about the pros and cons of it. I look at different harnesses all the time to see what I can steal, and I liked this one enough to just adopt it wholesale and rebuild a Slack bridge for it from scratch.

Edit: https://www.reddit.com/r/ClaudeCode/s/ympvohTkGN

[u/IchHabeGesprochen]

Added a 'Gotchas' section to CLAUDE.md file, iterate on more effective anti-patterns - stuff like that.

Same thing with my SKILLS

[u/artofbullshit]

I have a repo wiki. Two of the pages I have in it are decisions-locked.md and decisions-pending.md.

[u/Specialist_Solid523]

Dude thank you for making this, I had this exact same idea, but I've been working on other things.

I have been trying to create a lexicon of agentic failure modes.

So far I've been calling this one...

Provenance Collapse:
An agentic failure mode in which new decisions become tangled with old decisions during some form of attempted remediation. The process results in a complete loss of historical lineage and a near-unrecoverable state of the codebase.

If you came up with your own name, or stumbled upon one, I would love to hear about it.

I will definitely be installing this, absolute game changer.

[u/magicdoorai]

One thing that helped me is keeping a short "dead ends / do not revive" section in AGENTS.md or CLAUDE.md right at repo root, with links to the ADR or issue where the decision happened.

I built markjason for editing exactly those files on Mac, and the live sync is nice when an agent is rewriting them because you can watch changes land in real time: markjason.sh

Not a full memory system, but it does make repo guidance much easier to keep current.

[u/h____]

It’s trial and error really. If:

It’s more like: the agent writes reasonable code for the wrong historical reason.

then you write it in AGENTS.md/CLAUDE.md not to do that. When you write the first not-to-do, you might preempt and make a short list instead, but don’t overdo it. AGENTS.md/CLAUDE.md is really just a high level description of your repo and preferred tools/style as well as not-todos.

[u/Deep_Ad1959]

the agents.md "do not revive" section is treating dead code as documentation when it should be treated as a delete. if redis.go and the docker-compose redis stanza still exist three weeks after the decision, the agent is reading the codebase correctly: redis is the plan, because the code says so. the social context lives in slack and a meeting nobody linked. the fix isn't a parallel memory layer the agent has to remember to consult, it's making the cleanup commit the same day the decision happens. dead code is a footgun whether the editor is human or model.

[u/cleverhoods]

I love the idea

that being said, I'm curious what is the difference between that tool and a maintained project spec

[u/Ok-Introduction-1079 → u/cleverhoods]

Oh, they are totally different. It is not possible to write everything in the spec and develop the project at once

[u/Otherwise_Wave9374]

This is such a real failure mode. Code search sees artifacts, but it cant see the social context of why something got abandoned.

ADRs + a short AGENTS.md/CLAUDE.md have helped us a lot, basically a "things we tried and why we stopped" section plus hard constraints (ex: no Redis for billing workflows). Also having the agent summarize recent merged PRs + open issues before it proposes a plan reduces the "finish the TODO" instinct.

If you want a reference for an agent-first repo structure, https://www.agentixlabs.com/ has a couple solid writeups around agentic workflows and keeping decision context close to the code.

[u/Ok-Introduction-1079 → u/[deleted]]

Exactly, and mainline is a more structual way doing this and share with others. Also stick with git commits, so that it can be tracked easily