There’s a classic thought experiment about quality vs efficiency for machine learning in medical diagnosis. I can’t remember where I first heard it, but @pluralistic laid it out in a blog post:

https://pluralistic.net/2025/03/18/asbestos-in-the-walls/

2/

Consider those two different versions of the radiologist’s role: one as a valued human augmented by a machine, doing a job they believe in better than they’ve ever done it — and the other as a cog in a corporate process whose job is to perpetually deal with the machine’s mistakes.

Consider the parallels in software development. All vibe coding and “agentic” stuff points to the second: developers as slop wranglers, as accountability sinks, as exhausted and expendable workers on a code assembly line.

3/

I can image a developer parallel to the first, too: the human still using all their skills and experience, but with the machine catching mistakes, providing context and validation and vigilance that is •orthogonal to• testing and type checking and code crafting and — the big one! — actually •thinking• about the problem.

That’s a regime I imagine developers would feel a lot better about. And I know there are people out there pursuing it! But they’re not the ones dominating the conversation.

4/

The trouble is, as Doctorow points out, that this vision makes AI a multi-billion dollar industry, not a multi-trillion dollar industry.

Even if you can claim that your ML / LLM thinger can reduce software bug rates or failure rates by 10x — which would be •wild• — demand for that is simply not going to fund data centers the size of Manhattan.

But make the claim of •speeding up• by 10x — an even wilder claim, but one some people are desperate to believe! — and all the money in the world will beat a path to your door.

5/

This is, if I understand it correctly, the same contrast that the OP’s distinction between MTBF and MTTR points to:

MTBF = quality (It rarely breaks)

MTTR = efficiency (It breaks all the time but we recover so fast!)

6/

I can’t think of another time when software devs had to be •forced• en masse to use a new technology that was supposed to help them. Usually we’re kind of stupid for the shiny new things: jamming them in when they solve nothing, doing unnecessary rewrites just to use the new hotness because it’s so cool and fun. Usually we’re the one trying to shove it down mgmt’s throat (or sneak it by them) rather than the reverse.

But not this time.

7/

Why? The common explanation is that software devs are worried about job security and don’t want to be replaced. And…maybe? But again: past technologies promising greatly improved dev speed we’ve embraced headlong with no regard to large-scale employment effects.

I wonder if this quality vs efficiency thing upthread isn’t a big part of the explanation here.

8/

The “efficiency” pitch I’m describing upthread isn’t really “go faster;” it feels more like “making good things doesn’t matter, what you cared all along about doesn’t really matter, and we don’t think •you• matter.

We always just wanted to built absolute shit, and you always tried to stop us. But now at long last we can.”

9/

I’m kind of speculating here. I get off the LLM coding bus at several earlier stops:

⁃ The energy and water usage are an environmental disaster (so I mostly avoid it for the same reasons I try to reduce my driving).

⁃ The data sourcing is an ethical disaster (so I prefer to avoid it for the same reasons I try to buy fair trade products).

⁃ The people who profit from it at the top are largely horrible (so I’m about as interesting in debating its pros and cons at length as am I debating the work capacity of a Cybertruck).

10/