I don't really have any opinion about PRs versus trunk-based development, but I do have a small insight that I think is useful when you're thinking about which

I don't really have any opinion about PRs versus trunk-based development, but I do have a small insight that I think is useful when you're thinking about which one to choose. The main advantage of trunk-based dev is speed. You don't have to wait for a review of work. You're trusting the team to merge things that won't break stuff. That's awesome, but if that's the case then you should also be able to trust them to review PRs quickly enough that they don't block work. Equally the converse is true - if you can trust your team is motivated enough to review PRs quickly they you can probably trust them to do work together well enough not to really need PRs. If you can trust the team with one and not the other then something is wrong. There shouldn't be any "this way is better than this other way" argument. Your team should be capable of doing both. If it isn't then neither will work very well. You're going to have problems, conflicts, bugs, etc no matter what you do. Believing that the team should stop PRs because they're too slow, or they should stop trunk-based dev because pairing takes too much effort, are both red flags. They're both saying that the team has a problem to address.