Nobody has to be present when the pull request is approved

A decade of code review research already told us the approval on a pull request is worth less than everyone treats it as worth. Reviewers skim. Approvals arrive in seconds. LGTM is a social move at least as often as a technical one. All of that was true back when every approval came from a person who could, in principle, have read the diff.

Where Accountability Lives, posted to arXiv on 16 August 2026 by Sabry E. Farrag, makes the point that changes the picture. That weakness used to be a fact about how people behave. It is becoming a fact about what a product does. One of the tools in the study documents an agent that approves pull requests below a configured risk threshold, and that can dismiss existing reviews. The approval event fires. The artifact lands in the timeline, identical to the one a human would have produced. Nothing in the pipeline requires that a party capable of forming a judgement was present.

What the study actually is

It reads documents. Four agentic coding tools, eighteen governing policy documents from seven providers, with 118 archived source documents and 12 processing scripts deposited publicly on Zenodo. For every workflow event that leaves an artifact, it records five things: who holds authority, who executed and under which identity, who must verify, who bears the consequence, and which artifact survives. Then it checks whether the layers agree with each other.

They do not. One provider bars the developer who assigned a task from approving the resulting pull request. Another ships the review-approving agent described above. Same event, opposite rule. Neither document refers to the other, because the platform controls that gate what an agent may do and the provider terms that allocate responsibility for what it produces are written by different people for different reasons.

The contribution worth stealing

The most useful thing here is smaller than the headline and more portable than the specific findings, which will be stale in a quarter.

Verification usually gets described three ways: enforced, advisory, absent. Farrag replaces that with a grid separating two questions the three-way version collapses into one. Does a mechanism compel the check? And who performs it?

Split those apart and a category appears that the old labels cannot express: compelled, but performed by something that cannot be accountable. That is exactly where a required review satisfied by a bot sits. Under the old vocabulary it reads as "enforced", which is the most reassuring available word and the least accurate one.

If you run agents that open pull requests, that box is probably occupied in your repo right now, and your settings page will describe it in the reassuring word.

Your commit history is being written by disagreeing conventions

Attribution, the paper finds, runs in opposite directions across providers, and no trailer is defined for agent authorship. One provider repurposes the co-authorship trailer for it.

Anyone who has looked closely at commit metadata lately has seen this. Some tools record the human as author and the agent as co-author. Some invert it. The Co-authored-by trailer was built for pair programming, was never a claim about responsibility, and is now carrying that load in at least one shipping product.

This is the boring finding that will cost people real time. Your git history is the record you will actually reach for in eighteen months when a regression needs a source, and it is currently being written by conventions that contradict each other across the tools in one repository.

Three things to do this week

Decide what "approved" means in your repository and write it where the rule is enforced, not where the policy is documented. If a required check can be satisfied without a person, it is measuring something, and that something is not review.

Pick one authorship convention and apply it across every agent you run, before the history becomes a mix nobody can query.

If an agent operates under a human identity, every artifact it produces carries that human's name. That is a decision about who is accountable, and it stays a decision even when nobody consciously made it.

What this paper does not show

It is a documentary study. It measures what vendors write down and what platforms expose. It does not measure what happens inside repositories, how often an agent-satisfied approval precedes a defect, or whether any of this has cost anyone anything yet. The paper is explicit about that: it makes no claim that the gap harms anyone.

The methodological care is better than most policy-mapping work. The selection rule is equalised across the four tools, every reported absence is re-tested against a doubled page set with the survival rate published, and the whole source collection is deposited rather than described. It is still a study of documents, by a single author, at thirty pages and five tables, with no peer review yet.

Four tools and seven providers is also a narrow slice of what people are running. And policy documents change monthly, so any specific finding here has a shelf life measured in product releases rather than years.

Why read it anyway

Because it names the failure precisely, and the precision is the useful part.

The problem is not agents writing code without oversight. It is that the oversight events still fire, still emit the same artifact, and no longer carry the meaning that artifact was invented to carry. Compliance evidence reads that artifact. Incident review reads it. Blame allocation reads it. None of them can tell the difference between an approval that involved a judgement and one that did not, because at the level of the recorded event, there is no difference to see.

Source: Sabry E. Farrag, Where Accountability Lives: Mapping Human Responsibility to Workflow Artifacts in Agentic Software Development, arXiv:2608.15678, 16 August 2026.

---

Source: https://arxiv.org/abs/2608.15678