Another word of caution: bisection will have a rough time navigating around merge commits, because those introduce nonlinear "forks in the road" that also tend to be introducing large, possibly-breaking, non-trivial changes. But if your workflow is already avoiding merge commits except when necessary, then the drawbacks are minimized.
Yet another reason to prefer linear history in Git whenever possible, because bisect will work more predictably.
That said, if you're needing to use automatic bisection very often, this may point to a lack of a CI pipeline to validate commits automatically. After all, if a broken change is flagged before you notice, then you wouldn't need to bisect because the system has identified the faulty commit.