GitHub ponders a kill switch for pull requests↗ (external link)

This is from February and I keep coming back to it, because the quotes have aged better than the proposals have. GitHub PM Camilla Moraes opened a community discussion on maintainers "dedicating substantial time to reviewing contributions that do not meet project quality standards" — the options on the table included letting maintainers disable pull requests outright, restrict them to collaborators, delete them from the interface, and attach some kind of attribution when a tool wrote the code.

The line worth stealing is Jiaxiao Zhou's:

Review trust model is broken: reviewers can no longer assume authors understand or wrote the code they submit.

That is the actual problem, stated in one sentence, and it is not a spam problem. Code review has always run on an unwritten assumption: whatever else is wrong with this patch, there is a human on the other end who can explain it. Take that away and review stops being a conversation and becomes an inspection. The economics get ugly fast, because inspection does not compress the way conversation does.

Xavier Portilla Edo's estimate — "1 out of 10 PRs created with AI is legitimate" — is the kind of number I would normally push back on, since it is one maintainer's gut feel rather than a measurement. But nobody in that thread disputed the order of magnitude, and the people in that thread do this all day.

GitHub's own Matthew Isabel pushed back on counting AI-generated PRs at all: "A bad or off-topic PR is a bad PR, regardless of where it came from." He is right in principle and wrong in practice. Provenance was never worth tracking when writing a bad patch cost the sender an afternoon. It is worth tracking now that it costs them ninety seconds, because the cost asymmetry between sender and reviewer is the whole ballgame.