Automate the PR review, version the agent memory

Review is the bottleneck, and automation is the fix

An agent can open a PR in minutes. A person still has to read it, and the numbers show where the time goes. Faros AI's AI Productivity Paradox report measured 1,255 teams and more than 10,000 developers. Teams with high AI adoption merged 98% more pull requests, and their PR review time went up 91%. Anthropic reports the same from the inside: code output per engineer grew 200% in a year, and "code review has become a bottleneck".

Reading faster does not close a gap that size. Adding reviewers does not either, because agents can add PRs faster than a team can add people. What scales with machine-written code is machine review. When Anthropic put a team of review agents on every PR, the share of PRs that got substantive review comments went from 16% to 54%, and engineers marked fewer than 1% of the findings as incorrect.

The same holds after the merge. The 2025 DORA report, a survey of nearly 5,000 technology professionals, links AI adoption to higher delivery throughput and to lower delivery stability, and names the remedy: "Without robust control systems, like strong automated testing, mature version control practices, and fast feedback loops, an increase in change volume leads to instability."

Automatic review is not yet automatic approval. Today's review agents leave comments on a PR, and a person still decides whether it merges. Anthropic says of its own tool that approving a PR is "still a human call". The next step is to approve and deploy most PRs automatically as well, so that a person is only needed for the risky ones. Teams are working on that now, as the post in the next section describes.

The prediction: sessions replace PRs

A LinkedIn post by Gabriel Grinberg predicts that we will stop caring about PRs. Its argument: each time a unit of work got cheap (lines of code, then commits, then PRs) we moved up a level, and agents are now making PRs cheap. The next unit is the long-running session, which stays open from the idea until the result is real: a bug fix confirmed in production, an A/B test concluded and the winner merged.

The path there is already visible. Agents first wrote the PR, then fixed the review comments, then verified their own work. The current step is approving most PRs automatically, in a safe way. Each step moves the human handoff later, and the post explains why that matters:

Turns out agents have the same problem human teams have - every handoff loses context.

What delivery looks like then

The steps keep their order and deployment is still from main. What changes is who does each step:

today   PR → human review → merge → deploy from main
        → flag + A/B test → keep or roll back
        a person drives every step

next    PR → automatic review → merge → deploy from main
        → flag + A/B test → next PR → … → keep or roll back
        a person makes a few decisions

Code reaches main, and production behind a flag, before anyone knows whether it worked. The outcome arrives later, often several PRs later, when the flag goes to 100% or the change is rolled back.

Why that raises the stakes for memory

A person reading a PR catches wrong code. They also catch the wrong belief behind it. In an earlier experiment, one saved rule made an agent skip its source check and recommend the opposite of the right answer, in 5 seconds instead of 103. Automatic review checks the diff. It does not check what the agent remembered while writing it. So as review gets automated, memory becomes a direct input to what ships, and three things grow with it:

• More provisional memory. Feature work collects abandoned approaches, the losing side of an A/B test, and conclusions that were half right.
• More writers. Many agents work on many branches at once. One flat memory file shared by all of them is a global variable without a mutex.
• More reach. A merged PR changes one thing. A remembered rule shapes every session after it.

Building on it: keep the context on the feature branch

The post is right. Handoffs lose context, and a task should stay in one piece from idea to impact. One addition makes that easier to run. The task's context does not all have to sit in a single context window, where a very long history costs accuracy and makes every turn more expensive. It can also live in memory that follows the feature.

Features are already developed on code branches, and Memoir keeps a memory branch next to each one. Any session that opens the branch starts from what earlier sessions learned there. The task keeps its continuity, each session can stay short, and other agents, such as the reviewer or the production monitor, can pick up the same context.

A feature ships as several PRs, and each one merges when it passes automatic review. Its memory does not merge with them. It stays on the feature's memory branch until the feature or fix is verified in production:

• Verified. The flag is at 100% or the fix is confirmed, and the memory merges into main.
• Rolled back. The change is removed. Its memory never reached main, so there is nothing to clean up.
• Wrong after all. The memory merge is one commit, so it can be reverted later.

Memory needs the tools code already has

Code got version control when many people started changing it at once. Agent memory is at that point now. Four operations matter:

• Version it. In Memoir every memory is a commit. Work in progress stays apart from main, and parallel branches do not overwrite each other.
• Update it. A correction replaces the old value at the same path instead of piling up next to it, and the old value stays in history. Typed conflict rules stop a low-confidence guess from overwriting a confident fact.
• Revert it. memoir blame traces a belief to the session that wrote it, and memoir checkout brings back the store as it was at an earlier commit.
• Review it. /memoir:sync previews what a branch would add to main before it is promoted. If a person makes one decision per feature, this is a good one to keep.

The less people read the code, the more the memory has to be managed.

What is still manual

Memoir does not wait for production by itself yet. By default it promotes a branch's memory when the code branch merges. To wait for verification, turn that off with MEMOIR_AUTO_PROMOTE_MERGED=0 and run /memoir:sync once the feature is verified. A feature spread over several code branches also has several memory branches to promote, and reviewing a large memory branch is slower than it should be. These matter more as review gets automated, and they are what we want to improve next.

Try Memoir's branched memory

Automatic review clears the queue. Versioned memory keeps what the agents learn under control.