RE: https://hachyderm.io/@mitchellh/116580433508108130

Hearing the feelings in this rant, which does touch a nerve, I can’t help think about how different the developer community reaction to the LLM push might be if the focus were on quality instead of efficiency.

1/

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/

But that’s me; I don’t think my ethical concerns are shared widely enough for companies to have to be ramming AI down developers’ throats the way they are. The token quotas etc are a symptom of something large and deep.

Maybe that post about MTBF vs MTTR helps explain it.

/end

@inthehands This, but applied to translation, is why en masse translators are not grabbing at LLMs either. They produce something almost, but not entirely, quite unlike an actual translation. They can't remember context, they don't do consistency even inside a single sentence, let alone an entire article, their "suggestions" pollute the human brain the instant you see them so you can no longer imagine how you'd have approached that sentence... And the bias inherent in their corpuses is horrific.

I could go on and on, but I'm so tired of the whole thing, and particularly of being the canary in the coal mine for an entire world still blithely going "well it's fine for translation" when we've been dead on the floor of the cage for YEARS at this point.

@janeishly @inthehands good quality translators I know have moved on to other work in stead of following the race to the bottom on the payment/word rate that all intermediaries use.

@wiert @janeishly @inthehands I used to be a professional translator with two university degrees in the field. I quit my 15-year translation career a few years ago because idiots think "AI" translations are good enough and just need a low-cost pass by a "translator".

I saw quality drop considerably across the board, and can guarantee you: this is going to get people hurt and killed. A bad translation in a TV manual is annoying. A bad translation in medicine (my speciality at the time) or complex machinery docs can be deadly.

People are going to find out the hard way.