[thih9]

> Today, when an engineer at Cloudflare opens a merge request, it gets an initial pass from a coordinated smörgåsbord of AI agents.

I’d prefer to have that happen as some sort of pre commit hook, before a merge request is sent. The feedback loop might be a bit faster and the process might produce less noise this way.

[derwiki]

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.

[rhgraysonii]

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.

[Zanfa]

Can you elaborate about the practical value of having the history of back and forth, in a PR or even in the commit log? In my 20ish years of experience, I can’t recall a single instance where I’ve solved something thanks to having this work-in-progress state persisted in the repo history.

It’s exclusively been the other way around where having a smaller number of larger squished commits (post merge) that’s made the project be more maintainable.

[SpicyLemonZest]

It's not about having it in the commit history. I've seen a few cases where the back and forth revealed that the AI reviewer was offering bad advice (and a few others where I suspect bad local AI advice is why people keep sending me the same category of mistake).

[cush]

People usually squash merge anyways

[krzyk]

Actually not, it is similar debate like rebase or merge.

e.g. I don't squash, I prefer to see full history, not redacted one.

[mock-possum]

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.

[krzyk]

It is easier to view code review results in a tool and not in a text during commit.

There is no universal standard which IDEs support for code review results (there is SARIF, but it is not supported that widely). A review result on a web page with comments from humans, is valuable.

[NiloCK]

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.

[esafak]

You can and should run your reviews beforehand but the same reviews should run in CI too (just like with commit hooks) because reviews are nondeterministic and for verification (even if they were deterministic).

[Cthulhu_]

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.

[nullbio]

Few dozen times a year?

[trollbridge]

You must have some pretty monster commits.