In October the Claude Code team published how they review code now that Claude writes about 90% of it. Around the same time, Cursor's Lauren Tan suggested letting agents prove their own work with a video or screenshots for UI changes. Addy Osmani, one of the Claude Code post's co-authors, argued separately that "agents make checking cheap."
They agree on the direction. A pull request should arrive with evidence that it works, so a reviewer looks at the evidence instead of every line. We think that's right, with one condition: the evidence has to come from something other than the agent that wrote the change. That makes a screenshot from the authoring agent a self-report.
What a proof-carrying PR is
A proof-carrying PR is a pull request that ships with evidence the change does what it says, collected by running the software, by something other than the agent that wrote it. Typically that means recordings or screenshots of the changed flows, logs from the run, and a verdict a reviewer can act on.
Jovi De Croock calls a close cousin of the idea "humans approve intent, machines prove conformance". A person signs off on what the change should do. The platform gathers the evidence and routes each change to the cheapest review that's still safe. He's also open about the cost. On his own repository, collecting evidence took 13 to 17 minutes per change, and pre-existing test failures pushed every change into full review. Collecting evidence has to cost little enough to run on every PR, and old failures can't be allowed to drown it.
How the Claude Code team does code review
Their revert share fell by more than 40% from June to September while merged PRs more than doubled, and the agent checking its own work is only the first layer of how they got there. Then come parallel bug-hunting agents, with separate verifier agents voting on each finding. After that, a blocking security review, required CI, human approval scaled by a risk tier the classifier sets from the change itself, and a merge queue with staged release. Rollback sits under all of it. Uber's AutoClean is built along the same lines: fixers are scoped by file type so they can't make a test pass by editing production code, and its CodeCourt reviewer agents each check one property, all of which must pass before a human sees the diff. In both, the agent that made the change is never the last thing that checks it.
Why the agent's own screenshot isn't proof
An agent that attaches a screenshot of its change has shown you the screen it decided to look at, which helps a reviewer but doesn't check that the change works.
At CTO Craft in Amsterdam, our co-founder and Chief AI Officer Vilhelm von Ehrenheim told the room about one of his own agents that shipped a bug. Its post-mortem read: "I had the answer written down twice and shipped the bug anyway." In the Q&A he added: "if they're writing the tasks and the implementation at the same time themselves, there's still a huge risk for bias."
Our co-founder and CEO Daniel Mauno Pettersson puts it shorter: it's very hard for whoever created the work to review it, and "you kind of need like a second pair of eyes."
The author also picks what goes in the picture, and nothing stops it picking the happy path with the new button on the page. The Code described the failure that slips through: "the button it built doesn't do anything, because nobody ever clicked it."
What proof should contain
If a reviewer is going to merge on evidence instead of reading the diff, the evidence has to answer the reviewer's question, which is "does this do what the ticket asked, and did it break anything nearby?" In practice that needs:
- The intent it was checked against. The ticket or PR description, so the check tests what the change was for.
- The changed flows, run in a deployed build. A preview environment before merge, or staging right after it when there isn't one, instead of a mocked component.
- A recording or step screenshots of each run, including the ones that passed. In his Amsterdam talk Vilhelm listed what he looks for: "Do we have screenshots and videos of how it looks and feel? Can we see the difference between what it looked like before and how it looks now?"
- Network and console logs behind each step, so a failure comes with the request that returned a 500.
- A verdict that can report a miss. Pass and fail, plus unable to verify for a check that never reached the change, so a skipped check can't show up green.
None of that needs a human to read every line. Vilhelm made the same case at CTO Craft Bytes in September: "maybe you don't need to look at every line of the code, but you should have enough artifacts and kind of checks and things, and kind of collected evidence."
Who should produce the proof
The author agent can still ask for it. A coding agent can call a separate verifier the way a developer calls CI. It hands over the change, something with no stake in it runs the app, and the agent reads the result back and fixes what failed before a person opens the PR.
Cost is the other reason. Proof that needs a person on every PR won't keep pace with agent volume, while an automatic verifier will. Your branch rules can then merge a low-risk change with clean evidence on the check alone and send a high-risk one to a reviewer, who starts from the recording.
On customer calls Daniel describes how teams drift without this. People used to read all the code, he says, then they start letting go, as long as it compiles and the tests are green. Evidence from a separate verifier lets you stop reading every line and still know the change runs.
How QA.tech produces the proof
Our verifier won't catch everything, and the merge decision stays with you: the verdict posts as a GitHub check you can make required in branch protection. What it removes is the author grading its own work. QA.tech, an AI testing platform that runs inside the GitHub pull request workflow, reviews each PR with dynamic PR testing. Given a PR, it chooses which existing test cases touch the user-facing change, adds test cases where coverage is missing and runs the lot on the PR's preview deployment (with no preview, it runs after merge on staging or production). The result lands on the PR as pass, fail or unable to verify.
Each run keeps the step screenshots, the agent's reasoning and the network and console logs. Need an audit trail? A finished run exports with recordings, raw logs, JUnit XML and a SHA-256 manifest of every file.
Coding agents such as Claude Code, Cursor and Codex can start runs and read the results over MCP. Our command-line tool can open a tunnel to a local build. Either way the agent asks for proof without producing it.
Two earlier posts go deeper on separating checker from author: passing tests are not proof the product works and who gates the merge now that agents review every PR.
FAQ
What is a proof-carrying pull request?
A PR that arrives with evidence the change works, gathered by running the software with a verifier other than the authoring agent: recordings or screenshots of the changed flows, logs from the run and a pass, fail or couldn't-verify verdict. Reviewers check the evidence instead of reading every line.
Can a coding agent verify its own work?
Yes, as a first pass. Its code and its tests come from the same assumptions, so the final check belongs to a verifier that runs the app and wrote neither.
What evidence should an AI-generated pull request include?
The intent it was checked against, the changed flows run in a deployed build, recordings or step screenshots, network and console logs, and a verdict that can say "couldn't verify".
Do screenshots prove a UI change works?
Not on their own. A screenshot proves a screen rendered. It doesn't show that the button does anything, that the data saved, or that the flow next to it still works.
How does Anthropic's Claude Code team review AI-written code?
With six layers of checks and rollback underneath: the agent's self-check and a fresh-context review, parallel bug-hunting agents with separate verifiers, a security review, required CI, human approval scaled by risk tier, and a merge queue with staged release. Risk is graded from the change alone, whoever wrote it, and a bot's sign-off never counts toward a required human approval.