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.
-
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:
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/
-
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/
-
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/
-
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/
-
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/
-
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/
@inthehands The industry largely stopped caring really about quality ages ago. How many of us who have been here a while used to work on projects with actual quality assurance specialists and tech writers and other roles that were focused on the quality of the result? Instead we mostly said automation & devs can do that stuff and well devs can but not as well.
-
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/
-
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/
-
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:
2/
@inthehands @pluralistic the "one radiologist" example is giving me flashbacks to that Futurama episode where Hermes automates a process so efficiently that it ends up all being done by a single guy, depicted in supreme mind-melting agony.
-
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/
Imho there is another layer.
The question: Who is in control?If AI (or an OS) is established in a workflow / biz the one who owns the tec has taken real control.
It's like the drug scheme. Give someone a drugsample for almost free - and as soon as one is addicted eg not able to change back anymore the dealer is the boss.
Just like Musk is able to change politics or the success of operations in a war. #Ukraine #starlink
...or a judge in The Hague is cut of every digital service. -
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/
-
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
-
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/
@inthehands (weird al voice) your data sourcing is a disaster
-
@inthehands The industry largely stopped caring really about quality ages ago. How many of us who have been here a while used to work on projects with actual quality assurance specialists and tech writers and other roles that were focused on the quality of the result? Instead we mostly said automation & devs can do that stuff and well devs can but not as well.
@r343l
I want to share that romantic feeling for the past, but if I’m honest with myself, I’ve seen that pendulum swing wildly in my many decades of software dev between different companies, different projects, and different days of the week.I give students in one of my classes this podcast episode as a reading (well, listening) assignment, and it’s a story of 1982:
https://99percentinvisible.org/episode/the-worst-video-game-ever/
(Seriously, listen to the developer talk in his own voice about the dev process, and the •astonishing• lack of quality control of any kind!)
-
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/
@inthehands DeepSeek is valued at ~50B. The way China is doing AI is pretty close to sane: valuations that make sense, push for open-weight and local models, developers that don't tweet about the fun they're having bringing about the eschaton, etc.
-
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 very much a “yes, and” sort of response, since I’m sure Paul already knows all this and more)
1. Speed up *what*, exactly, by 10x (or whatever)? AI advocates usually say “creating software”, but current generative “AI” only significantly speeds up one piece of that: writing fairly atomic chunks of code (i. e., bits of code not clearly designed as part of a larger whole, even if the developers understand it to be part of a larger project). Code review isn’t any faster, because the reviewers don’t understand it as well as they did before (and are overwhelmed by the increased volume of review from the faster initial code writing). Code build and deployment isn’t any faster, because modern build+deploy tooling is already highly automated and works well with fairly modest supervision.
2. A *ridiculous* amount of software is, from the standpoint of an end user, buggy, slow, difficult to use, and above all, actively impeding sensible or desired use cases because of deceptive practices — all while being anywhere from expected to required for participation in society. Writing it faster behind the scenes does not address any of that. In fact, just making web sites that didn’t suck, even if the services involved cost a bit more to use, would be a *huge* business differentiator in an unambiguously positive way.
-
@inthehands (weird al voice) your data sourcing is a disaster
@gildilinie @inthehands we're approaching a point where "i got me a hundred gigabytes of ram" will once again be an actual flex
-
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/
@inthehands I think you apprehend the situation correctly. These days, nobody cares about developer experience unless it reaffirms the dominant narrative. I have explicitly asked the VP of Engineering at my employer and was told straight up that velocity is the only true measure of success.
We will not survive this without a reckoning.
-
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/
@inthehands A thought just occurred to me reading this: it’s a bit like white label software. Few devs get excited by it, it’s a business, a commoditised way of application production.
LLMs have expanded and accelerated white label software development to unheard of levels.
Along the way they’re DDOSing people who care.
-
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/
AI is a stagnating force.
It is producing an informational monoculture while killing the broad & diverse knowledge base & expertise that created it.
Ever had to bootstrap something from scratch without the underlying infrastructure or when the underlying infrastructure is unreliable or untrustworthy?
It's a brutal process.
Remember who funds AI initiatives. Billionaire bigots. Anti-democracy wingnuts. The owners of AI are not benign.
Monocultures are vulnerable to the new.
