A lot of the concerns when proving something by exhaustion (or by cases) are the same concerns when designing algorithms. By "algorithms", I specifically mean non-ML (or rule-based) algorithms.
A lot of the times when I'm solving a LeetCode problem, I rely too much on problem solving heuristics, instead of thinking what my algorithm does in each specific case, which is ultimately how your algorithm runs (case by case, and not because your intuition says its right). One productive technique is to consider the worst input that your algorithm can face i.e. edge cases, and observe what happens there. It's important to know that your algorithm does not work if it is not correct on all cases. So, to start, consider what the "worst" case could be and reason from there.