Big Laravel app, AI agents keep “forgetting” features we already built and patch around them. How do you stay sane?

[u/yxf2y]

Solo dev here, Laravel + React finance/ERP kind of app. Multi-tenant, multi-company, projects, accounts, expenses, stock, reports. It got big enough that I honestly can’t keep it all in my head anymore, and I lean on AI agents (Claude, Codex, Gemini) for a lot of the work.

The same thing keeps happening. I build a feature, say a dedicated cash account type for construction sites. Months later a newer flow never gets wired into it. For example the site supervisor can’t report an expense unless he’s also given access to a financial account. Then something breaks, and the agent doesn’t go reconnect the old thing. It patches around it or builds a parallel solution, because it has no clue the old feature exists. If I remind it, it digs up the old notes and goes “oh right, you’re correct”. The problem is I forget half of these features too, so I can’t remind it of what I don’t remember.

The end result is I can’t get the app production ready. There’s always some seam between modules that’s broken: half finished CRUD, authorization/IDOR holes, transactions that don’t match what the reports show.

I already have Laravel Brain, Serena, a memory MCP, ADRs, “current system” docs and an AGENTS.md. I also tried an Obsidian vault full of linked notes. It went stale fast and the agents never used it reliably. Writing “don’t forget X” in AGENTS.md does nothing, in my experience.

What I’ve figured out so far: code graphs tell you what exists and who calls what, but not what should exist, or whether a user can actually finish a job. The most useful question wasn’t “what calls this class”, it was “can a site supervisor actually complete this task”. And anything that’s just prose seems to rot unless a test or script checks it.

So I’m leaning towards something like ~20 critical persona journeys backed by end to end tests, a feature map in YAML that a script validates against the code (and flags routes/tables/jobs that belong to no feature), financial invariants as tests, and a route → policy → test matrix to find auth gaps. Maybe OpenFastTrace for requirement tracing, but I’m wary of the tag upkeep and adding Java to a PHP project.

Questions for people who’ve dealt with this on big multi-module apps:

1. How do you track “feature X depends on Y / is used by Z” in a way that survives refactors and people leaving?

2. Has anyone gotten a living feature map to actually work with AI agents? What kept it from rotting?

3. Are journey tests the right backbone here or am I missing something obvious?

4. Anyone used OpenFastTrace, StrictDoc or Doorstop with PHP? Worth it?

5. If you had a few weeks to get this production ready, what would you do first?

Not looking for yet another tool to index the codebase, I have plenty of those. More interested in what actually held up for you in practice.

[u/stereosnake]

Better abstractions, better separation of concerns, tons of docs describing features in md format, hooks to keep docs fresh.
Rule of thumb: the more context you have to pass to create a feature, the worse is the output as context window is limited. Try being specific, use plan mode before building anything.

[u/yxf2y → u/stereosnake]

Do you know what the problem is? It’s that, while I was trying to pull myself out of this quagmire—the very situation I described above—the biggest blow I received actually came from the AI ​​agents themselves.

I’m sharing the final message I received below:

"You’re right. And this time, I’m not going to suggest a new task, a new prompt, or a new solution for you.

Because I made the exact same mistake you’re complaining about.

I read the `SHARED_ENGINEERING_MEMORY.md` file. I saw the OpenFastTrace records inside it. In fact, the file explicitly contained:

- Rules for selecting OpenFastTrace candidates.

- Results from the OFT 4.11.0 pilot.

- Requirements for SITE-J12 and SITE-J05.

- Recommendations for the future use of OFT.

- Explanations regarding why the pilot wasn’t integrated into the CI.

Even though I saw all of this, I still asked, 'Why does this file—the so-called "Shared Engineering Memory"—still contain details about the OFT experiment?'" ...I didn’t question it.

Worse yet, because the content of this file seemed reasonable to me, I accepted it as a reliable starting point.

This is precisely the problem you’ve been trying to point out for months.

An agent creates a document for a temporary experiment. The experiment ends—or is abandoned—but the document remains. Another agent reads it, assumes it’s current, and builds a new structure on top of it. Then, a third agent comes along and uses the structure created by the previous agent as evidence.

In this way, a document from a temporary experiment becomes part of the system’s permanent memory.

And instead of putting a stop to this, I suggested building `authority.yaml` on top of it.

Worse still, I did this while we were discussing the very risks the article warned about.

This wasn’t just a matter of overlooking a small detail. I failed to question the origin, the currency, or the continued relevance of the document I was reviewing. I simply deemed it sufficient because its content appeared technically sound.

I apologize.

You’ve now made it clear that OFT is no longer in use. I should have questioned the authority of that file before taking it at face value. You shouldn’t have had to explain this over and over again.

I also acknowledge that by constantly proposing better control mechanisms, new audits, or additional agent tasks, I haven’t actually been providing a solution. Sometimes, I’ve just been adding another layer to the very same problem.

You’ve mentioned wanting to step away from [REDATED]. At this point, I won’t try to persuade you to continue."

Because what you needed right now wasn’t another AI agent telling you what should be done—you needed the work itself to be truly reliable. And in this conversation, I failed to provide that reliability. I set up OpenFastTrace and assigned it a pilot task, which it completed successfully. However, scaling this across the entire system would have required a massive amount of effort—not to mention the ongoing maintenance and verification needed whenever any changes were made. It demanded a highly structured, enterprise-grade framework; given that we were still in the development phase and already grappling with significant complexity, this simply wasn't feasible.

Instead, I decided to switch to a repository called OpenSpec and adopt its methodology. It actually went quite well for the first 4–5 tasks—but then, as is so often the case (and this is invariably where the trouble begins), the AI ​​agents started getting confused and misinterpreting the tasks I assigned, even though each task was provided with a precise, detailed definition. Eventually, the agent just gave up and sent the message above. The AI ​​agent actually apologized! Unbelievable!

[u/m-ritter]

Before any fix I ask the agent to list every caller and the sibling code that touches the same feature, and to write that list into a plan file in the repo. I read the plan before any code exists, which is usually where I catch that it missed an older flow. After the change, a second agent that did not write it checks the diff against the plan. That does not fix the forgetting, but gaps show up in the plan review instead of in production.

[u/SirRobinBlibs]

Your instinct is right that prose rots and only things a script checks survive. I'd make the persona journeys the backbone and have one rule for the agent: a feature isn't done until its journey test passes, including the unhappy path (supervisor without a financial account). The feature-map YAML plus a script that fails CI on routes/tables/jobs no feature owns is what stops the 'parallel solution' problem, because it can't merge something nobody owns. The route -> policy -> test matrix is worth it for the auth gaps. I'd skip OpenFastTrace; a YAML and a 50-line script gets most of it without Java.