This is sort of the great contradiction of software development. Untested legacy software is hard to work with. So should our focus be on how to work with legacy software or how not to create it in the first place? There's really no answer to that.
I understand that this is all just a thought experiment, but there has to be a better way of framing it that isn't so immediately farcical.
This is a thought experiment on how to avoid that tacit knowledge, not how to deal with it. Consider approaching every edit in the same way you'd approach new code: is the function adequately tested, does the function have a single responsibility, is the intent clear, etc.? The idea is that if you do this, then you won't reach the point where you have a 200-line method with tons of hidden business rules.
I agree there's probably a better way of framing this. Still, as a thought experiment, it's worth thinking about when you can and/or should do this.