Not sure I follow the analogy, so apologies if I'm reading it backwards, but we do in fact have standards for "good enough" brakes without being brake-maxxers.
Similarly here, I'd argue that a verified implementation with correctness proofs, mechanical translation, and easily auditable theorems seems close to good enough? A lot rides on the Claude-built translator, I suppose, but the trusted code for that project seems to be tiny in comparison to what it would have been 2 years ago!
I suspect you two are using the same words for different terms / connotations.
"Good enough" in colloquial speak usually means the minimum required for some particular requirement.
For security, there is usually no exact threshold that differs between insecure and secure. It's a spectrum that involves costs and tradeoffs, which are subjective value judgements.
A SaaS startup in pre-seed mode with no customers will have VASTLY different value judgements than a bank that handles $trillions in assets. Hence they will make very different security choices and "good enough" will mean very different things in their different sectors.
I don't get the analogy. Brakes that are good enough for a Honda Civic driven at regular speeds are not good enough for a fire truck or a race car, but there are in fact standards that are "good enough" for all of those.
I'd argue that the difference is often just semantics. In general, I can do a better job on a given task in a week than a day. If I only have a day, but AI lets me do in that day what would have otherwise taken a week, then the result is better while my time expenditure remains constant.
Similarly here, I'd argue that a verified implementation with correctness proofs, mechanical translation, and easily auditable theorems seems close to good enough? A lot rides on the Claude-built translator, I suppose, but the trusted code for that project seems to be tiny in comparison to what it would have been 2 years ago!
"Good enough" in colloquial speak usually means the minimum required for some particular requirement.
For security, there is usually no exact threshold that differs between insecure and secure. It's a spectrum that involves costs and tradeoffs, which are subjective value judgements.
A SaaS startup in pre-seed mode with no customers will have VASTLY different value judgements than a bank that handles $trillions in assets. Hence they will make very different security choices and "good enough" will mean very different things in their different sectors.