The pull request was built for a world where a person wrote the diff and another person read it. Agents broke the first half. Now the second half is a queue nobody wants to read.
Jovi De Croock wrote one of the clearest proposals I’ve seen for what replaces it. The rule fits on a sticky note: “Humans approve intent. Machines prove conformance.”
Where it came from
On October 1, Cloudflare published “We want you to build the next Git platform on Cloudflare” , asking how agents should coordinate, review and record why a change was made. De Croock spent the next week building gittifacts , an agent-native git platform, and wrote up the idea on October 11. It’s open source under MIT and runs locally without a Cloudflare account.
His framing of the problem is the part I keep repeating to people. When an agent writes 500 lines in a few minutes, the old assumption “turns into a queue of diffs nobody wants to read. Either we read them all and become the bottleneck, or we skim them and rubber stamp the change.”
That’s the attention problem I wrote about in human attention is the spec , showing up in code review.
How it works
The unit of work is a Change, not a pull request. A Change is intent plus diff plus evidence.
A plan comes first. An agent drafts a Plan: intent, acceptance criteria, what’s out of scope and which paths it expects to touch. A human approves it. Reading a paragraph of intent is a lot cheaper than reading a diff.
Each Change is a fork. The agent gets its own fork with a push token scoped to that fork only. No agent can push to main.
Evidence runs on every push. On top of CI: red/green proof for fixes (the new test fails on the base commit and passes on the head), coverage and mutation score on changed lines, a public API diff, a dependency diff, hits on sensitive paths and a preview deploy. The platform signs the result and stores it as a git note on the commit.
A pure function picks the lane. Auto-merge when everything is proven and nothing is risky. Quick review for things like additive API changes. Full review for breaking APIs, auth, migrations, new dependencies, scope drift or a fix without proof.
Merged changes ship behind their own flag. If errors go up, the platform switches the flag off, rolls back and opens a revert Change.
The parts I’d steal today
Even if you never run anything like this, a few of the rules are worth copying into whatever you have now.
Unknown means escalate. A missing or errored signal can only raise the lane, never lower it. A model’s judgment can push a change toward stricter review, never the other way. That one rule closes a lot of quiet failure paths.
The agent’s claim is an input. “Just a small bug fix” means nothing without evidence.
Trust is earned per repo. Auto-merge starts off. People review everything while the platform records whether they agreed with the lane it picked. You turn auto-merge on when your own review history says the classifier is good.
Nobody approves their own work. No human or agent approves their own Plan or Change, and agents can’t approve anything at all.
Reversibility is what makes auto-merge acceptable. He says it directly: without per-change flags and the ability to tie a regression to a single change, he’d keep auto-merge off.
The catch, in his words
What I like most is that the post includes the catch. Auto-merge “still trusts the author’s test environment for parts of the evidence: test runs, red/green, coverage and mutation.” On the gittifacts repo itself, evidence took 13 to 17 minutes per Change, and pre-existing test failures pushed every Change into full review.
That’s the whole game. “Machines prove conformance” is only as good as the machine doing the proving. I wrote about this in your tests are lying to your agent : a suite that passes doesn’t mean the behavior is right. It means the tests didn’t notice. If those same tests are the evidence, a weak suite becomes an auto-merge button.
Here’s an evidence note that would look fine at a glance and shouldn’t:
change: fix retry on timeout
red/green: pass
coverage: 92% of changed lines
api diff: none
deps diff: none
mutation score: 0.00 (skipped, Friday)
lane: ?
By the rule, a skipped signal should push that change up a lane, not let it through. The interesting test of any platform like this is whether it actually does.
What I’d add from the test side
Treat the evidence pipeline as production. Who changed the test config? Who can mark a step optional? Those changes deserve the strictest lane, because they change the rules every other change is judged by. De Croock covers part of this: policy is read from the default branch, so a change can’t loosen the rules it’s judged by.
Run the evidence somewhere the author doesn’t control. That’s the residual risk he names. Moving test runs to an isolated environment the agent can’t touch closes a lot of it.
Audit the lanes, not just the merges. Sample auto-merged changes every week and have a person review them after the fact. If people keep disagreeing with the lane, turn auto-merge back off.
Where I land
I think the rule is right. People should spend their attention on deciding what we want, and machines should do the checking they’re good at. As he puts it, “If the intent is wrong, proving conformance to it gets you the wrong thing faster.”
The work now is making the proof trustworthy. That’s a testing problem, and testing problems are solvable.