I have used that (only running a few tests that match the diff) in the past to great success as the first level of testing that would occur on the users compute

I have used that (only running a few tests that match the diff) in the past to great success as the first level of testing that would occur on the users computer before committing code. It reduced the amount of build failures by 99% and test failures by a similarly high amount. On the server we would run those tests first and we would continuously sort the order of tests so tests that failed in the past would be run first to reduce the build+test time and find failures faster. There are lots of tweaks that can be done, but these days having automatic build+test before a commit gets into the main branch feels like it is the norm. Even open source github projects can use something like TravisCI to prevent bad changes from getting into a project.