ResearchJuly 9, 20267 min read

Why AI Coding Agents Fail Without Product Memory

Two recent studies looked at tens of thousands of pull requests written by coding agents. The pattern is uncomfortable: agents can produce code quickly, but they still lose context, take on work nobody wanted, and hand reviewers changes that are too broad to trust.

The agent is fast. Review is the bottleneck.

The practical problem I keep running into is not getting an agent to write code. It is deciding whether the code belongs in the product. A convincing diff can still solve the wrong problem, touch too much, or arrive with no useful proof that it works.

One 2026 study of the AIDev dataset found that 46.41% of agent-proposed fixes were rejected. Another study examined roughly 33,000 agent-authored pull requests and found that the unmerged ones tended to change more code, touch more files, and fail CI more often.

Those numbers do not prove that project memory would rescue every rejected pull request. They do show where the cost has moved. Producing a change is cheap. Understanding, reviewing, and trusting it is not.

What RAAV is

What disappears between sessions

PROJECTMEM describes coding agents as largely stateless across sessions. That matches the everyday experience: a new run reopens the same files, reconstructs old decisions, and may retry an approach that already failed.

The pull request studies found duplicate work, unwanted features, weak reviewer engagement, incorrect implementations, CI failures, and low-priority changes. Low priority is especially revealing. The agent may have done competent work, but it was never told what mattered this week.

A repository contains the code. It rarely contains a reliable account of which ideas were declined, which compromise was deliberate, or why one unfinished task matters more than another.

Why agents forget product context

AGENTS.md helps, but it cannot run the project

I use rules files and think they are worth keeping. They are good at conventions: how to test, where not to write, which commands to run. They are poor at live state. A rules file cannot tell me who owns the current task, what another worktree is doing, or whether a founder has accepted a proposed product change.

I want both. The agent should get concise repository instructions, and the founder should get a current record of work, decisions, and evidence.

PROJECTMEM calls a similar idea memory-as-governance: memory that can warn before an agent repeats a failed fix or touches a fragile file. Its evaluation is a small self-study, not proof at product scale. The useful part is the framing. Remembering only matters when it changes the next action.

A run should leave a receipt

In RAAV, an agent begins with `raav context`, reads a compact brief, and chooses a named task. Before editing, it claims the task and checks the files for active conflicts. That gives the run a boundary before the diff starts growing.

At the end, `raav submit` records the summary, files, branch, and verification result. Product changes that need judgment go into a founder review queue rather than quietly becoming fact.

The point is not process theatre. It is to make the next session cheaper to start and the current session easier to inspect. If a run cannot leave a useful receipt, the founder is back to reading chat logs.

Two agents, one repo See the work loop

What I am testing with RAAV

RAAV is my attempt to give founders a readable product record while giving coding agents a stricter starting point. The agent still reasons and writes the code. RAAV keeps the brief, work ownership, decisions, verification, and history together.

The proposition is simple: when every run starts from the same product facts and ends with recorded evidence, less work should be duplicated or thrown away. That still needs to be proven with real founder projects, which is why access is opening in small testing cohorts.

The Trial is priced at €10 per week — upgrade or cancel anytime. Solo and Team add more projects, history, and collaboration. Checkout is still closed while the founder test is running.

Join the founder test See the memory console

Sources

Test RAAV on a real repo

Request access to a controlled founder cohort. Joining creates no subscription or charge.

Join waitlist