Including a regression test is an excellent heuristic. I also like to extend that to testing closely related things where there are test gaps. The benefit is not just that it will catch the exact same bug recurring, but that you get more tests in areas of the code with higher bug density and more test gaps.
It's not a perfect heuristic but it's an easy one to get a team aligned on. IMO the biggest challenge in scaling a team and maintaining code health is setting standards like this that are easy to explain and easy to maintain. There's an unfortunate human tendency to cut corners in the absence of clear rules here (even the best engineers will do this in many circumstances).
You can always exercise judgement on the cost/benefit of adding the test though, it's just a good default.
It's not a perfect heuristic but it's an easy one to get a team aligned on. IMO the biggest challenge in scaling a team and maintaining code health is setting standards like this that are easy to explain and easy to maintain. There's an unfortunate human tendency to cut corners in the absence of clear rules here (even the best engineers will do this in many circumstances).
You can always exercise judgement on the cost/benefit of adding the test though, it's just a good default.