Are they gatekeeping to protect against AI "slop" or are they gatekeeping to protect an inefficient and non-scalable review process against velocity?

I've seen policies like this in various places and they do not generally seem to be based quantitative measures of code functionality, security, and efficiency.

There are other approaches to take to deal with large numbers of incoming PRs: improved CI, AI-readable standards for AI code, better static testing, AI first-pass review, etc.

It's fine to enshrine hobbyism into your code review policy to keep things fun and human-scale. On the other hand, where projects actually matter, it is necessary to think about code review as part of an industrial process with inputs and outputs, one where this sort of thing has no place.

▲

anang 5 hours ago | parent [-]

In my experience success in a project isn't about the amount of code that can be produced, it's more about the thoughtfulness behind features and fixes. A lot of the work going into reviewing pull requests is understanding it in the context of the project's broader goals.

This gets a lot harder when there is a giant wall of text that the pull requester doesn't understand and can't really discuss outside of asking AI (and probably getting "The reviewer is right to push back - I was too aggressive in my blah blah blah" as an answer).

A lot of (but maybe not all) pull requests are fundamentally a human to human task, even if there is a lot of technical details involved.

	▲	romaaeterna 2 hours ago \| parent [-]
		Part of this is an argument for size limits on PRs. Another part is "how do we communicate project goals and ideals and standards?" The answer to that, I'd argue, is not simple, and will inherently run into scale issues. It's something that needs to be tackled as you move from a bespoke craft project to an industrial project. Now, maybe you never move. It's okay and good for hobby projects to exist. But let's be clear about the choice there.