I don't think there's any particular reason to apply the label of "bug" to erroneous reasoning that cannot result in erroneous behavior. If you can't in actual

I don't think there's any particular reason to apply the label of "bug" to erroneous reasoning that cannot result in erroneous behavior. If you can't in actuality cause a flaw in a program despite the presence of unsafe operations or faulty reasoning, then I would say that by definition there is no bug. Rather I might say that the code is brittle and perhaps unmaintainable, with risks for people who modify it later. Which is of course bad, but thinking pragmatically there's not much different between a latent pitfall like this and some poorly documented or gnarly spaghetti code that is equivalently difficult to maintain. Fixing what the author calls "Level 1" and "Level 2" problems is sort of a mandatory imperative, as you can't realistically ship software with prominent issues at these levels. But shipping software with latent "Level 3" problems is something that happens every day, and it might be entirely correct to do the hacky and expedient thing rather than the "correct" thing at this level -- this is not a luxury you can afford at other levels, which makes this level fundamentally not a "bug". That doesn't mean it's not worth thinking about erroneous reasoning. Erroneous reasoning is often the source of actual bugs that slip through a test suite. And if you're using loose reasoning and relying on assumptions holding true in the future, this is the sort of thing you should be documenting next to the code for the benefit of future maintainers. And indeed we should be working to write more maintainable, safer software, but not under the guise of a "bugfix" -- this is just good software engineering practice. Thinking about "Level 3" problems is good. But be pragmatic. The reason you're doing it is because they make software difficult to reason about, and hence maintain. Investing time into fixing these problems helps future maintenance, but there are probably a lot of things you can do to improve software maintainability and you do need to actually ship the software at some point.