Your agent has to prove it before it opens a pull request
It's more than just passing checks.
Most teams reviewing agent-written code are running the exact same checks they ran before agents existed. Real foundational stuff like: do the tests pass, does the diff look reasonable, is there an obvious security problem? And those checks are still useful, they catch real problems and they should stay exactly where they are in the review flow. But they were designed for a world where a person had already decided the change was worth making, and that is the assumption agents break. (Sometimes, the people break things, too. But that’s neither here nor there.)
Your agent can very quickly produce code that compiles, passes every test, satisfies the linter, looks good in Storybook… and also implements a requirement that was superseded three weeks ago. That’s because there is nothing in the standard pipeline that notices anything other than the code being correct. Where we go wrong sits a level above the code. As it turns out, validating implementation is the tractable half of the problem, and the harder question is whether the work rests on a premise that still holds.
Your agent should answer 5 questions
Before it opens a pull request, your agent should be able to answer five things:
What’s the problem being solved?
Which requirement or decision is being implemented?
Is the decision current, and as of when?
What acceptance criteria does the change satisfy?
What things could not be verified?
Just like we wouldn’t expect engineers to write a beautiful paragraph of prose to impress the reviewer, we expect the same from agents. Short and inspectable is the whole point. Something closer to:
This PR implements the current onboarding requirement for self-serve users. It relies on the authentication decision ratified on May 12 and the updated activation metric defined on June 3. It covers criteria A, B, and C. I could not verify whether the new flow should support SSO users.
Compare that level of detail to something like “Added onboarding flow.” The first version gives a reviewer something to do, not just click Approve (or scroll through lines of diffs). The reviewer can inspect the premise directly rather than having to reconstruct it from the diff and whatever documentation or memory of what the team decided in the spring.
But the last line is the one that matters most. Your agent that names what it couldn’t check is infinitely more useful than one that reports clean, because that is the gap is where a human should be looking.
Expensive failures start above implementation
Right now, a lot of AI review tooling is aimed at style issues, naming, dead code, and the class of bug a careful reader would probably catch on a second pass. That work has value, but it also operates entirely inside the diff. The costly mistakes happen where the diff can’t see:
A feature that was deprioritized in June and still has an open ticket.
A constraint that changed when the security review landed.
An interface contract that two teams renegotiated in a meeting nobody wrote down.
A reviewer should not have to open five tabs, search Slack, read a ticket from March, and ask a PM whether the feature is still a priority in order to understand what an agent did. People already do this, and it works at the speed of human throughput. (It’s also not particularly enjoyable.) This janky workflow stops working altogether when agents produce more changes per day than anyone can contextualize.
Self-reporting is necessary… and insufficient
Here is the objection worth taking seriously. Your agent that misread the requirement will also write a confident, well-formatted statement about the requirement it misread. Asking a system to declare its own premise does not verify the premise. It moves the error somewhere more legible, which is progress, but not proof.
So the declaration needs.. something to be checked against. When your agent says it relies on a decision approved on May 12, something outside of the agent should confirm that 1) a decision by that name exists, 2) it says what the agent claims, and 3) that nothing has superseded it since. When the agent cites acceptance criteria, those criteria should trace to evidence (requirements, etc.) that a person actually wrote.
That evidence turns the pull request description into a set of claims that have references that can be checked, rather than a summary in prose. Claims can be wrong, but they’re surfacing in ways a reviewer can find. A summary can really only be read and believed. The record this checks against has to be the organization’s own: the tickets, the decisions, the strategy documents, whatever documents the team already maintains.
An agent cannot bootstrap that context from the repository, because the repository is the output rather than the reasoning.
We expect this from humans, why not agents?
Software teams ask engineers to explain their reasoning whenever the stakes justify the overhead, or sometimes just for fun. It’s pretty typical to have some assortment of design docs, architecture proposals, incident reviews, and test plans ready and available to point to. The reason is the same in every case: “it seemed right at the time” is useless after something goes wrong.
Why do we allow our agents to pass a lower standard than traditional engineers right now? Is this the last dying vestiges of “move fast, break things?” (If so, be still, my heart.) I’d argue that, yes, the speed of agents and the volume of code they produce makes the old process feel expensive, in terms of time and attention.
But speed is a poor argument for a lower bar.
The faster a system produces changes, the less time anyone has to reconstruct why each one exists, and the more the written record has to carry. Any agent that can show its work, and be checked on the showing, is one a team can actually run at volume.