This reminds me of a Pre-LLM-slop era issue I had with a process that a co-worker had created via a shared script that would automate combining many dependabot PR’s into one consolidated PR.
The script was excellent because it simplified the review process for a single repo (that had many competing dependsbot PR’s) and it also happened to do this across increasingly many many different repo’s simultaneously.
Funny thing is, however, that it also created a team dynamic where who ran the script became almost a race because the effort in creating x pr’s didn’t correspond at all to the effort required to review x pr’s.
The optics were also lopsided since the script would operate on the runner’s local machine and so it would have seemed as if the person who made all these PR’s was highly efficient at producing when in fact it was the reviewer doing the majority of the work.
Also reviewing represented a chunk of a developer’s day so it would affect other actual work the developer was tasked to do anyways.
In an agile workplace points (correctly or not) completed are attributed only to the code creator with no points at all being shared by those who reviewed the work, and rightfully so I’d argue because tangentially reviewers can also tend to just click “approve” (or slap a LGTM) without much effort into critiquing a piece or giving a thoughtful review. Why? It slows down the introduction of the feature (the PM won’t like that, why would you slow down the process eh? You grumpy goose), it messes with team dynamic (you may end up offending those who you review, who also happen to be the one who you need to review your work, who then may be petty or worse, mud slow to review your own PR’s), it takes additional time to provide reviews that seem as if you even read the PR or don’t come off as flippant (did you provide examples or a suggested refactor or detailed reasons), and it takes context because you may be working currently on a totally different project (regardless of your experience/authority in the PR’ed repo), so giving an honest review may sacrifice even more time to first review the purpose of the PR and how that lands in the context of the target repo(s) and then sacrifice the time necessary to reorient yourself to the task you previously had in process. With all this…that “approve” button becomes sooooo tempting.
It’s funny because fast forward some of the ways I battle increasingly prolific AI generated material is through GitHub’s CoPilot bot. I ask it to do the review first and when it gives the review there is none of that dynamic because it wasn’t me who levied the criticism and also it’s not me who is trying to block code integration (so no grumpy goose or team dynamics problems). Having a bot do preliminary checks almost does what git hooks did for team dynamics way back when automation of linting, testing, style, etc was introduced as a common part of the review process. And I say “almost” because a)sometimes the critiques from the bot are wrong and b) the critiques aren’t necessarily deterministic, so just because they are there or not doesn’t mean you are truly relieved of that portion of the review process (for better or worse).