It seems like the lesson of vibecoding et al is that you want to disable pulls for code but you want to keep them for bugs, test-cases, and requirements. Becaus

It seems like the lesson of vibecoding et al is that you want to disable pulls for code but you want to keep them for bugs, test-cases, and requirements. Because that is now what is scarce. You want people to keep contributing things like a unit-test that the current codebase fails on, or a design rationale for a feature, or an unenforced invariant. Then, after the expert human signs off on that, verifying that the new unit-test is in fact correct, then your trusted LLMs can solve any coding from there. So, the ad hoc short-term Github solution is probably something like leaving pull requests enabled, but figuring out how to auto-reject ones which touch any implementation code. Depending on how inconvenient that is (maybe code/doc/tests are too intermingled, like typing declarations), you might try to channel everything through an issue.