At the beginning of the year I wrote that the PR is the last one standing for keeping a shared understanding of a codebase when agents do the coding work. The final call is with the human, and that was the idea I built Forge around. Time passed, and now my agent is allowed to merge pull requests on its own. I changed my mind because I caught less and less that the agent and the system around it hadn’t caught first. Don’t get me wrong, I’m still in the loop and I’m still in control. I just spend less time reading diffs and more time at both ends: defining the problem before the agent starts, and shaping the system it works in.
The system around the agent constrains it. I like to think of the guardrails as a boundary that funnels the agent in the right direction. That system has two parts: the repository the agent works in, and Forge, the skills that tell it how to work. I’ve been shaping both, across all my projects.
My Reviews Stopped Paying Off
In January I left 126 inline review comments on 25 Colorburst PRs. That was the collaborative loop I described in February. In September and October I left none, across 159 PRs. Tandler, my newest project, has three handwritten review comments in total, all on one of its first PRs.
The agent still makes mistakes, but now something other than me catches them before anything is merged. On a Colorburst quota change, two fresh-context reviewers noticed that the test fixtures used a pricing tier that doesn’t exist, so the tests passed without ever testing the free tier. On a dependency update, an adversarial review attacked the SVG sanitizer with 30 crafted payloads and found three ways around it. Both were fixed in the same PR, before I even looked at it.
An Experiment With a Friend
My own projects have one weakness as evidence: I know how to guide an agent. So I started an experiment with my friend Andreas, who shares our office space. He is a civil engineer and had an idea from his field for a very long time. When I showed him Claude, exploring it became feasible for him for the first time, and he built a prototype with Claude Cowork.
The prototype was functional and visually impressive, and a potential customer he showed it to was very excited. Underneath, it was a typical vibe coding disaster by someone who didn’t know anything about software engineering: no git at first, no CI, one big index.html full of inline JavaScript, and almost a gigabyte of data read on every lookup, because nobody had told him to use PostGIS for geodata.
For me it was very exciting to see how far he got. I wanted to help him get it off the ground, and to see how far a domain expert who only describes functionality can get with a setup that gives agents solid engineering guidance. It’s a win-win: I get my insights, and he gets a shot at turning his domain knowledge into software that can scale as a business. We restarted from the prototype with the structure of my own projects: linting, dead and duplicated code detection, import boundaries, migration checks, high coverage requirements, and a pipeline that deploys every commit to main on a VPS. Then I handed it over to him, together with the Forge skills. I taught him how to shape a problem and let the agent build it and run the app for him, so he can try what he’s creating and refine it on the spot. He doesn’t look at the code, because he doesn’t even know what it means.
He opened 85 PRs in his first five weeks, around a thousand lines each. My job in the experiment was to spot problems in the setup, so I reviewed with a narrow focus: did the agent put the pieces together correctly? Whether the domain logic was right, I couldn’t judge. I’m not deep enough into his field, and understanding everything in a thousand-line PR was too much cognitive load anyway. In September I approved 45 of his 48 PRs. For the details I often leaned on Claude’s /code-review, posted its findings under my name and opened fix PRs myself. Simon Willison would call that meat proxy review. It fixed the PR in front of me and left the setup as it was. What helped was looking for patterns across his PRs and agent sessions and turning them into guardrails.
Structure Is What Makes Trust Possible
In February I wrote that structure amplifies capability. I’d go further now: structure is what makes trust possible. An agent that can prove its change works gives you something to rely on besides your own reading of the diff. Thorsten Ball asks his agent to “give me irrefutable proof that this works now”, and reviews only what he calls “load-bearing code” (his words, for once not Opus’s). When a PR comes with a test matrix and screenshots, he says, you go into the review completely differently.
Sometimes the proof is wrong. After an image model swap, every new Colorburst template shipped without a title or tags for about five weeks, CI green, because the tests hardcoded the model’s response. Reading those PRs wouldn’t have caught it either, so the fix was another guardrail: a live contract test against the real model.
Everyone Is Converging
What finally made me change Forge was watching others arrive at the same place within a few weeks. The Claude Code team at Anthropic optimizes for “the minimum amount of human review time that doesn’t raise reverts or incidents”. Low-risk changes need no human approval once the checks are green, because “the change sets the tier, not the author.” At Imprint, Will Larson’s team built the small-change. CI decides whether a PR qualifies, a review skill can only approve or ignore it, and every error it lets through counts as a failure of the system. Gergely Orosz calls much of what is left elsewhere “zombie code reviews” (his deep dive covers the whole range), and the Amp team dropped PRs altogether.
All of them, with very different risk profiles, take the human off the default path and spend human attention where the risk is.
Forge, Reforged
Every finding in one of my projects ends up in one of two places. Some only make sense in that repository, like the seeded database in Colorburst’s CI. Others are about how an agent should work anywhere, and those go into Forge. In Colorburst and Tandler, agents had been running the app end to end and writing it up in the PR for a while. That became Forge’s exercise step. A day of bringing Andreas’s stacked PRs up to date with main became a guard that keeps the branch mergeable. And his review load, together with the Anthropic post, became land.
/forge-setup-project # once per repo: AGENTS.md and the docs agents work from
/forge-ship 42 # implement Issue #42, exercise it, review it in fresh context, open the PR
/forge-ship --guard 42 # and keep going: CI, review feedback, then a risk verdictShip implements the Issue, then exercises it: it runs the app, uses the changed path once, and writes what it saw into the PR’s ## Exercised section. A fresh-context reviewer, not the session that wrote the code, reviews the diff.
Guard drives the PR to review-ready without anyone watching, through CI, review feedback and a mergeable branch. It never merges, because a loop that fixes its own PR shouldn’t also approve it.
Land is the newest. It judges a green PR’s risk in fresh context, on the head commit. Mechanical checks come first, such as size, migrations, CI changes, security-sensitive paths and weakened tests. If none of them hit, the verdict is low risk only if the reviewer can name what the checks would miss. Otherwise the PR gets a short “where to look” list, each item a file and a question. With Auto-merge: low-risk in AGENTS.md, land merges a low-risk PR itself, and only the commit it judged.
I turned auto-merge on in Colorburst, Tandler and Andreas’s project a few days ago, so it’s too early to say how often land is right. Of its first six verdicts on Andreas’s PRs, two were low risk. One of the four that need review asks whether the code reads a clause of the building regulations correctly, which only Andreas can answer.
/plugin install forge --marketplace mgratzer/forge # Claude Code, with a live lens beside the session
npx skills add mgratzer/forge # any other agentWhat Doesn’t Transfer Yet
Forge stays PR-based, unlike Amp. The PR is where the evidence lives, and it’s the unit the teams I work with already understand. Accountability is still there: I decide whether a repository’s guardrails are good enough, and I fix them when something slips through. As the Claude Code team puts it: “Whoever prompted the change is on the hook for it.”
And these are my own projects, built for production but by one person, without a team or compliance around them. Gergely found that the other cases of fully automated review were side projects, single-person businesses and very early startups. At work there is compliance, and there is knowledge sharing: if nobody reads what shipped, nobody understands what shipped. That’s what we’re working on now, figuring out what these learnings mean for our software development lifecycle.
Where the Human Goes
Andreas wants to move fast, not only when building but also when getting his PRs out the door. I was the bottleneck, reviewing in the evenings, and this week we both decided to find a better way.
Stopping my reviews wasn’t a leap of faith. Review is one control among many, and right now the risk is low: the project has no users yet, land still sends migrations and risky paths to a person, and the models and coding agent harnesses keep getting better. My evening reviews added delay, not much safety. So he moves on, and I spot check and improve the system without blocking him. When real users arrive, the goal is to keep his pace while the system gets safer, the way the Amp team does with feature flags and agents watching production. He brings the domain knowledge, and I keep shaping the system around him.
That’s the part I care about most, in his project and in mine: finding where an agent drifts, asking where it could have been avoided, and fixing it there. That can be in how I shape the issue, in the repository, like a rule about building regulations, or in Forge, like running the app before opening a PR, so every project gets it. The shaping happens before the agent starts, and I spend a lot of time on it. It’s sparring, not dictating: dumb questions, poking holes in the agent’s assumptions and in mine, until we’ve covered everything relevant. In February I called planning the step where the human adds the most value, and that hasn’t changed. No human in the middle, a human at both ends: a well-shaped issue going in, and a system that funnels the agent around it.
How that holds up might be worth another update in a few months.