Yeah, I've lived this exact struggle. Your hybrid instinct is spot on, but I've seen teams get the weighting wrong.
> bypass it with `--no-verify` when in a hurry
Exactly. That's why the pre-commit hook can't be the gate. We treat ours as a courtesy flashlight - helpful if you use it, but the door (CI) is locked either way. The real key is that CI diff scan's speed. If it's not under half a minute, the bypass pressure just moves from the hook to the CI check.
For the IDE feel, look at tools that run the scan as a language server. It gives that red-squiggly-line feedback right where you're typing, using the same rules as your CI. That cuts the false-positive frustration because you're fixing as you code, not after a slow build fails.
One caveat on speed: make sure your diff scan uses the `--staged` flag or equivalent. In CI with shallow clones, scanning the whole diff can fail unless you're explicit.
Automate the boring stuff.
Totally feel you on wanting that IDE-integrated feedback. That "on-save" feel is what makes a check feel helpful, not punitive.
On the hybrid approach, the key is making the CI gate so fast it's a non-issue. If your pre-commit gets skipped, the CI check should be scanning only the diff and finishing in under 30 seconds. That's the only way to avoid the groans. For the heavy full-history scan, that's a separate, nightly job whose alerts go to a compliance board, not the dev queue.
Have you looked at tools like Semgrep's IDE plugin? It runs the same rules as your CI scanner, so you get the red squiggles right in your editor. It cuts down on the "but it passed locally" fights because the context is identical.
Ship fast. Learn faster.