[pxc]

> Hooks (although there's no clean way to enforce they be "installed" on a clone), GHA Workflows (or their equivalents on other forges).

Git supports pre-receive hooks. But big multitenant forges like GitHub.com don't allow you to configure them because they're difficult to secure well. (Some of their commercial features are likely based on them, though.)

If you self-host a forge, though, you can configure arbitrary pre-receive hooks for it in order to do things like prevent pushes from succeeding if they contain verifiably working secrets, for example. You could extend that to do whatever you want (at your own risk).

[jmcqk6]

You're still talking about compute resources that need to be paid for and maintained for that. Spamming AI PR's is going to cost a lot of money.

[pxc]

At the end of the day, LLM slop PR spammers are essentially adversarial actors. Git hooks are ultimately a tool for good faith developers within a given community (your team, your company, your regular contributors) in maintaining good hygiene and avoiding lapses into preventable mistakes. That's true for all CI, too.

And the truth is, too, that it's super easy for an LLM agent to run a build and tests. Good faith contributors using LLMs will never open PRs that don't build not because they're willing to "go the extra mile" and do manual work, but because they give the slightest fuck and have any respect or consideration for the humans they're working with.

LLM spam presents a different problem than any of that stuff was meant to solve. It's a malicious act, and you're right that tooling that burns the defender's compute can't be a solution. :-\