Like it or not, the "merge request" (eg, open a PR) is the Schelling point of relevant information. I expect that At scale here refers to size of software projects, and not only code velocity. Software projects of large enough size have CI configuration that don't typically fully-run on each dev machine.

My company has the AI review agents, and you can run them locally, but practically it’s easier to just open a merge request to have CI run the agents. Especially if you’re juggling a bunch of merge requests.

Pre commit only happens on your machine though - you lose the ability to have a shared review surface where you can tag others on your team to specifically prompt discussion or verification on issues that touch their domain. When an agent points out a potential security issue with how my work ties into infrastructure, I want to just be able to tag our infra team and ask “hey is this something to worry about?” The agent, myself, and the other team member have now all contributed to a threaded discussion that is easily referencable in the future.

Valid, but you lose the lived history that comes with the audit log of it being actual review back and forth and CI runs vs lost to a developers machine and only a relic in the commit log. I can see both sides, though.

I have mixed feelings, but it boils down to how long it takes and / or cost.

Pre-commit hooks should be fast, as it's something you'd do (normally) a few dozen times a year. I don't believe sending a review job to a remote agent is fast, nor will waiting for a review to finish a commit be good for anyone.

CI on the other hand can be slower and runs async, it's fire and forget so you can switch tasks.

If noise is an issue, one possible solution is to create a merge request, have the tools review it, make the fixes, rewrite history like you did it perfectly the first time ("fix" commits are noise), then create a new one for human review.