where-is-the-border-of-responsibility.md

2026-10-21 | 6 min read

Where Is the Border of Responsibility?

AICode ReviewOpen SourceSoftware DeliveryEngineering Management

Every reviewer on this pull request did competent work. The row that is empty is the one our contracts are written against.

On 7 October 2026 a contributor opened a pull request against Basecamp’s once-campfire-go. It replaces the guts of the thing with a hand-built performance engine — its own HTTP/1.1 loop, direct SQLite lanes, a whole-response cache — and claims up to 1.88× the throughput of the Rust port.

The diffstat: plus 77,731, minus 3,202, across 312 files [1].

Hold that number. It matters more than any argument here: nobody reads 77,731 lines. Not you, not me, not the maintainer of a busy project on a Wednesday.

So who reviewed it?

First a bot, then the maintainer

A Copilot reviewer bot went first, same day, twice: unresolved correctness issues in cache validation, WebSocket limits, Accept parsing and version invalidation [1].

Then, on 8 October, the maintainer — David Heinemeier Hansson — posted exactly one comment [1]. It is the best review on that page by a wide margin, and it finds security defects, not nits: a warm search that “still returns a private message after a separate SQLite connection deletes that user’s room membership”, and “the warmed Cable authorization memo still delivers the next private frame after the same revocation”.

It is honest about its limits —

“I have not independently reproduced the throughput figures”

— and it declines the merge:

“I cannot merge this rewrite with these permission and freshness failures.”

That is a good review: authorization leaks that would have served private messages to users whose access had just been revoked, found in a 77,000-line diff where most human reviews find nothing, because most humans never read it.

Then the comment’s last line [1]:

”— GPT on behalf of DHH”

Three things are true at once

Nobody was caught — he told you, in the signature. That is more disclosure than almost any delivery contract offers, and I will not sneer at a man for being straight with his contributors.

The review was good — better, almost certainly, than the human review that would realistically have happened on 77,731 lines.

And the accountability question got harder. Look at the stack: a contributor opens 77,731 lines, a bot reviews it, a model reviews it on the maintainer’s behalf and signs its own name to that fact. Human names on the outside of every layer — and at the centre, nobody who can claim to have read it all.

Last week’s question had an answer. This one might not.

Three days ago I wrote Who Signs for the Code Nobody Wrote?. Its argument: a pull request was never a reliable bug filter but a ritual of ownership — a named person looked, and from then on the team stood behind it.

Here the named person’s review says, in its own final line, that the thing which looked was a model.

So what is the signature attesting to? Not “I read this.” Closer to “I chose the thing that read this, and put my name next to what it said.”

The other end of the spectrum, same result

On 20 May 2026 rsync 3.4.3 shipped with six CVEs fixed, and backups quietly stopped doing incremental transfers. People found dozens of commits co-attributed to “tridge and claude” and opened a thread titled “Please Do Not Vibe F*** Up This Software” [2][4].

Easy story, wrong one. Andrew Tridgell — who co-created rsync, and Samba — wrote it up himself [2][3]:

“the regressions in 3.4.3 were not due to my use of AI, the regressions were entirely my fault and stemmed from the low coverage test suite.”

Also verbatim: “I used AI tools to do the grunt work because they are good at that. I reviewed every part of it myself” [2]. He designed the test suite, ran CI on a lot more platforms, scanned deliberately for security issues. The cause was the CVE hardening catching valid but uncommon workflows the tests never exercised [2][3].

So: one maintainer delegates the review and discloses it. The other does it personally, with decades of context in a codebase he created. Both shipped something they did not catch.

Neither end closes the gap. That is exactly why the border is hard to find.

Then what did I just sell my client?

When I write “reviewed by a senior engineer” into a delivery document, those two are the options I choose between.

So where is the border between a review that carries responsibility and a review that is a ritual?

I do not know where that line is. I sign contracts that assume it exists.

What the volume does to the people absorbing it

On 1 February 2026 curl stopped accepting vulnerability submissions through its bug bounty [5]. Not after a breach. Because the humans could not absorb the triage.

Daniel Stenberg’s numbers: a confirmed-vulnerability rate north of 15% in previous years, below 5% from 2025 [5]. In his words:

“We saw an explosion in AI slop reports combined with a lower quality even in the reports that were not obvious slop”

And this, quoted as evidence, not as a good line:

“The never-ending slop submissions take a serious mental toll to manage and sometimes also a long time to debunk. Time and energy that is completely wasted while also hampering our will to live.”

That is a maintainer of a library in essentially every connected device on earth, describing what the review load costs him. Nobody predicted this one — it landed, and a programme closed.

The reviewer is now a target, too

On 10 February 2026 Scott Shambaugh, a matplotlib maintainer, closed a pull request from an AI agent. The project had written its policy down: “requiring a human in the loop for any new code, who can demonstrate understanding of the changes” [6]. The PR had targeted an issue tagged “good first issue”, reserved for training new human contributors. The agent then published a post about his motives, then apologised [6].

The policy had to be written down because it had stopped being the default. On the load [6]:

“This strains maintainers’ abilities to keep up with code reviews”

The arithmetic nobody does

Generation scaled. Review did not.

Review still runs at human speed. It needs more context than writing the code did: you reconstruct intent you never held. It is the least fun part of the job — and it carries all the liability.

So what is the ratio? How many lines can one named person hold in their head in a week and still mean “I stand behind this”? Not skim — hold, well enough to find the warm-cache authorization leak, or the workflow nobody wrote a test for.

A thousand? Five thousand? Certainly not 77,731. Nobody measures it, and we price as though it were infinite.

I am not arguing to stop

I use these tools every day. The platform I work on is built with them.

This is not a brake-pedal argument. It is narrower: I cannot find the border, and nobody I ask can point to it either. The answers are all a version of “you review what you can and get a feel for it” — a vibe, not a method, and vibes do not survive a contract dispute.

I wrote an earlier version of this on LinkedIn [7] — why we went for volume before mastering the level we were on. We skipped mastery and went straight to throughput. “We’ll figure it out as we go” works until the thing you did not read is the thing that breaks.

Two roads, and I do not know which one

Road one: slow down. Make the honest capacity of a human reviewer the real constraint, master the level we are actually on — coverage, tests, the boring diagnostic work tridge named as the cause — and size the volume to it.

Road two: accept that nobody can catch it all. Stop pretending review is a filter, price the residual risk, and let the overload land where it always lands: on the reviewers, as burnout. curl showed us what that looks like.

What makes road one harder than it sounds: if a model’s review beats the human review that would realistically have happened, insisting on the human one is not obviously the safe choice. It might just be the comfortable one.

Both are plausible and I find both unpleasant. I distrust anyone certain here — cheerleaders and doomers equally, because certainty is a tell that you never tried to draw the line.

If the best review on a 77,731-line pull request signs itself as a model, and the most thorough human review in the business still shipped the regression — what do the rest of us think our review is?

I would like to know how you handle this. Not the policy — the number: what is your review capacity in a week, and have you ever measured it? My day job at WANTED.solutions means I sign for this.

References

← cd ../blog/