[aakresearch]

In my opinion review will always be a bottleneck, in OS as well as in commercial development.

To my understanding Code Review is first and foremost a trust-building exercise, seeking to establish common understanding behind the piece of code which is to be delivered. That it also may lead to improvements or "catch some bugs" is a distant tertiary side-effect, not the primary goal. At least this is the vantage point I reviewed any code from in the last two decades, and found that team morale and overall quality of teamwork - and delivered software, and customer satisfaction, as a result - responds very well to such interpretation. Regardless of the side you are on and competency level of your vis-a-vis. I would put "elevating competency level of both partners" as a secondary goal of Code Review, and very closely connected to the primary.

With current crop of LLMs there simply nothing on their side to which words "trust" and "understanding" can be meaningfully applied. Hence the "review" takes drastically different shape and implies very different goals. As both the primary and secondary goals described above cannot apply too. The only remaining goal of "improving and bug-catching", in absence of trust, understanding and learning, now requires much more work, which is also much more exhausting.

[aakresearch]

And a follow-up to my comment above, as wanted to reply to "create an issue before filing a PR" remark too.

I find it actually extremely useful practice. We engineers tend to center our thoughts around "code" and with such code-centric mindset to accumulate knowledge as "code-adjacent" - in repo's commits, PRs, markdown files of all sorts. But in reality most if not all projects extends past the code, and it makes much more sense to have a "project-centered" mindset. As such, an external "issue" captures much more context and provides more useful insight about project impact than PR description alone. Love or hate JIRA, beyond microscopic solo-projects it makes full sense to use broader-scope external tools for project management.

As a nice cosmetic effect it also removes (some) bickering about whether to put "type" or "scope" first in the commit message :). Simply provide a reference to the ticket! (No, really, I hate JIRA, honestly!)