I've been prototyping using LLMs for some borderline use cases, and the cost isn't really the concern, it's the reliability. Using less than the most frontier model seems irresponsible if it could mean the difference between 99.95% reliability and 99% reliability, and that's the threshold where you should've hired a human to do it because you lost more money on that 0.95% error rate than you saved on salaries. (I don't actually have any use cases where this kind of calculation makes sense, but in principle I think it applies to most uses of LLMs, even if you can't quantify the harm.)
Is that really true, though?
First off, you’re ignoring error bars. On average, frontier models might be 99.95% accurate. But for many work streams, there are surely tail cases where a series of questions only produce 99% accuracy (or even less), even in the frontier model case.
The challenge that businesses face is how to integrate these fallible models into reliable and repeatable business processes. That doesn’t sound so different than software engineering of yesteryear.
I suspect that as AI hype continues to level-off, business leaders will come to their senses and realize that it’s more marginally productive to spend on integration practices than squeaking out minor gains on frontier models.
It’s also worth noting that Rust doesn’t prevent integer overflow, and it doesn’t panic on it by default in release builds. Instead, the safety model assumes you’ll catch the overflowed number when you use it to index something (a constant source of bugs in unsafe code).
I’m bullish about Rust in the kernel, but it will not solve all of the kinds of race conditions you see in that kind of context.
But in the listed categories, I’m equally skeptical that none of them would have benefited from Rust even a bit.