I think your examples agree with my point: You found minimal-time solutions that haven't caused continuous suffering afterwards, and can be easily removed when the root cause is fixed. That's a good result.
I'm still trying to challenge your assumptions. Why does a different solution necessarily require expanding the scope of work? Like you said, that's where experience helps to have those skills in your toolbox. Doing things better doesn't have to be harder.
My whole point is that you don't, because there aren't always just two options. That's the false dilemma logical fallacy.
I'm saying you can fix problems without dropping everything and redoing work. You're allowed to problem solve and work with people to create a third option. And you can prevent new ones by learning and strategizing.
The choice between refactoring and money-generating work is a false dilemma. There are other options, and the developer doesn't have to make that decision or carry out the work all on their own.
As the article below explains, it's a combination of structured qualitative analysis and a review process. That process builds on top of all the other application-specific or discipline-specific processes, like a hierarchy. The higher up you go, the more generic it gets. The lower down you go, the more you critique the exact math or test or whatever.
I'm trying to explain how articles often conflate "intuition" with "breaking physics", and you're making your argument by conflating them. We're having different conversations.
Why would you use a classical model to describe a quantum system? That's the kind of wordplay that those articles do, and almost identical to my example about materials. It's entertaining, but meaningless.
I assume you're referring to how some popular science articles report things. That's just wordplay. Nothing is being bent, broken, or bypassed.
Usually it just means they did something an ordinary homogeneous material couldn't do, for example. Which is genuinely interesting, even if it's not actually breaking physics.
> It should catch the issue and exit cleanly with an error message.
Probably not. As the author describes, LLVM has to tool to check for invalid IR, which they used to investigate the issue and generate an explanatory error message.