If you don't trust your devs, CI is rarely going to protect you (at least in most setups)
Your dev could just replace all the tests with a "return true" to bypass traditional CI, too,
This makes an explicit step where you are vouching that you have run tests. If it turns out you didn't, it is going to be found out when someone actually DOES run tests and they fail... at that point you can discipline the developer for lying.
It isn't a matter of trust, its a matter of developers are humans. Humans make mistakes, and continuous integration helps catch mistakes.
I've been coding for 25+ years, and I sometimes I forget to remove debug output, or I forget to update an explicit exception I threw somewhere, or I forget to make sure dependencies build across all the platforms we need.
Running your build a second machine helps to catch a lot of those mistakes. It also helps enforce automation and good configuration practices and lint/formatting standards and all that, but fundamentally its helps us because humans make mistakes.
CI doesn't have to mean setting up a 12 step pipeline in GH actions with 3k lines of yaml and crazy triggers and workflows. It can just be an old dev machine (https://www.jamesshore.com/v2/blog/2006/continuous-integrati...) that pulls the latest code, runs `script/build`, and POSTs results somewhere.
Maybe local signoff works for 37signals, if so, thats great. But it isn't continuous integration.
If you don't run anything different on the CI machine than locally, then how is your post an argument against signoffs? Why is it not continuous integration if the step is run on a different computer?
Humans are easily confused though. I've been 100% sure I've run the tests and haven't many times. It's quite easy to do: make a change, run the tests, fix it, run again, everything works. Make some trivial refactor that "shouldn't change anything". Your brain says "it's fine, I ran the tests, remember?" and you push. But you didn't run the tests.
"First you must not fool yourself, and you are the easiest to fool"
The most common mistake you'll get here is people running tests, then making a small change later, then having tests fail unexpectedly. Even accidentally. This has happened to me before with regular CI, and often hit me during an automerge I fully expected to pass.
That and having local changes to either uncommitted files, or something external like a library version that works here but will fail on deployment.
Dev replacing all tests with return true would should up in the PR review right? I mean a dev that malignant needs to be fired yesterday and someone approving that PR can be shown the door right alongside them.
Most of this signoff stuff isn't about actual trust. It's about demonstrating controls for audits.
You do it on a shared server because you can pull it up and show your auditor "see, we follow our SDLC process".