[saghm]

Producing code that does what's intended. The metric is fuzzy and based on the usage of the software, not the scale of lines of code. The extent of the importance of the code itself is that I'm practice software tends not to be "one and done", so you need to be able to go back and modify it to fix bugs, add features, etc., and it turns out that's usually hard when the code is sloppy. Those needs still should stem from the sandal actual user experience though, or else we've lost the plot by treating the mechanism as the goal itself

[shepherdjerred]

Would my user rather have a program that works 100% in 2 weeks, or a program that works 80% in one day?

When the user needs a change made, would they prefer I spend another two weeks extending my perfect program, or throw a few LLMs at their sloppy code and have it done in a day?

[g-b-r]

You're really asking if a user would want a program that fails a fifth of the times?

In some cases it might be better to have some crap right away and more cheaply, but even you would probably not like a 20% failure rate in most of the software you use.