Reasons to dislike AI coding
23 points by j11g
23 points by j11g
This post is basically "it's always been this way" four times in a row, as if that means we're not allowed to complain. As if everyone was happy with the state of software, or the world, beforehand. As if highlighting problems afresh is a reasonable excuse to accelerate them. At what point is this kind of post just capitalist propaganda?
Funnily enough, it's coming from a self-described (albeit top-hat-wearing) communist.
Boy, that temptation of personal slaves offloading hard work sure is something, huh.
At what point is this kind of post just capitalist propaganda?
It's not, it's example #387946 of "Your specific X/Y/Z grievance is actually a general anti-capitalist grievance".
Socialists tend to say variants of this a lot because many people never connect the dots between their specific complaint, and the system that caused it. It's an attempt to get people to focus on the disease, and not the particular symptom du jour.
Many, but not all, anti-AI complaints fall into this category.
It's an attempt to get people to focus on the disease, and not the particular symptom du jour.
When the symptom is the focus of the author's consultancy I fear this piece may not be as anti-capitalist as you interpret. If the post is indeed about focusing on capitalism as a whole, if anything it reads more like an attempt to shift focus away from the thing people can potentially make a difference on right now.
It's an odd duck because the author also recently wrote what I consider a very good journal article: https://deprogrammaticaipsum.com/fully-automated-luxury-communistical-software-factories/
I note that none of the "reasons to dislike" relate to the real, documented cognitive atrophy seen by consistent users of the models as they surrender more of their thought processes and self-confidence to the machine.
Perhaps because the author doesn't have a succinct refutation for that?
Absolutely. Most of the arguments made in the post sound weak to me. I'll try to draw a comparison with how wooden furniture artistans got slowly replaced by Ikea-style slop. Woodworking is an art, Ikea killed countless jobs (carpenters, joiners, cabinetmakers, etc.), building an Ikea kit is not particularly challenging (the wood proxy argument), and Ikea is kinda evil because corporate greed and all.
To me, the most compelling arguments against AI are the cognitive atrophy, the lack of interaction with beings who can grow when you can just ask mister mobilek (thus far fewer knowledge transfer between humans), the colossal impact on energy consumption, the price surge for personal computing, and the gigantic non-consensual heist on human-made language elements (art, text, images, music).
None of those points are discussed in the article.
I don't think an analogy with ikea holds up because there has also a major external change at least in Europe (and Ikea is Swedish, that probably works): people moving to cities even more. Many wooden furnitures are heavy. They survive centuries but you cannot move them and, often, you cannot fit them in current living spaces.
Also, Ikea has pretty good engineering. I wouldn't call it slop. It doesn't have the same value and it's sadly common to throw away and buy new when moving, partly because they may not survive the move, but also because you'd buy something that fit your new space better (which is basically my first paragraph). But still, it's not slop and there's definitely quality control, definitely including the manual and documentation.
Looking at IKEA competitors, there is definitely companies that produce furniture slop on the principle of IKEA furniture (assemble at home, cheap manufacturing, lightweight, etc.).
So I think the analogy holds; there is artisan wood working, there is high quality IKEA furniture and there is IKEA slop. A artisan woodworker might call all IKEA furniture slop, regardless of quality, an IKEA customer might enjoy both artisan and IKEA furniture but does not like furniture slop. An IKEA enthusiast might even say there is no reason to buy expensive artisan furniture when you can buy cheap IKEA furniture. And there is people who buy the slop furniture and don't care about quality, robbing any quality furniture makers, artisan or IKEA, out of quality made money.
Moving to large cities is but an incentive to use disposable furniture. We have many modern-day incentives to do programming, and what was holding us back was it required manual labour, just as you had to get bespoke furniture or make do with poor space efficiency back when Ikea did not exist.
Now that it's readily available, people use it.
As with all analogies, with enough poking at them they will start to show why they're analogies and not exact matches, but I think my comparison with how you could convert the same arguments made in the post to what happened to carpenters, joiners and the like holds up. I do point out of few reasons to dislike AI coding that are missing from the post which, in fact, have no equivalent in the woodworking world (e.g. intellectual property theft).
As for the quality of AI-generated code vs. the QA at Ikea, it's only a matter of time (if things continue on their current trend) until slop becomes actually quite good. If you re-read my post, you will find that I have not commented on the quality of the output, and that is deliberate: this argument is probably going to be irrelevant soon. I call what Ikea makes slop because it produces large amounts of soulless, blank furniture with "good enough" QC (and instructions, yes). I'm not saying their engineering is poor, but disposable furniture is definitely not a craft.
Ah, the moving goalposts of anti-AI terminology. First “vibecoding” became “any coding where AI touched any part of the process”, and now we have “slop” that is “actually quite good”?
Not that I can do anything about it, but I’d rather read value judgments of stable concepts rather than infinitely flexible epithets with value judgments built in.
the price surge for personal computing
and for web hosting: https://www.dnalounge.com/backstage/log/2026/10/06.html
I don't like AI coding, but I can't say it's not useful. Most of the arguments in this article can be disarmed by taking the abstraction "one step up". LLM generated modules and software, microservices, whatever your level of abstraction... now need to be composited together. You go and deal with higher order problems, factories, generation, etc.
Is it a way to develop critical bits of code, depths of your business logic? Absolutely not. Can it solve a lot of boilerplate and support logic? Absolutely yes.
Seeing "AI Companies as Bad Actors"... can't fully disagree there. There's far too many far too dodgy things about these businesses, and I trust them as far as I can audit them (not very far). And the missing argument's the cognitive decline of using these things to think for us. I try to keep myself sharp by still manually doing a fair amount of things in my life. I refuse to automate everything - especially the stuff I do for fun. Having an LLM manage hobby-adjacent stuff is a quick trip to burnout land, especially once fixing the thing becomes "the hobby"... and it does.
I see agents as more like a cnc and its effect on manufacturing. You can still make things by hand but for the most part you can achieve the highest quality and scale with automation. Obviously as we become cnc programmers and operators we lose the hand-filing skills we once used, just as our forefathers forgot how to use flint-knapped hand axes.
I think a big part of the angst is that we’ve had to look around and engage with what the things we’re building are actually for, instead of just resting in our craft. There’s lots of good work to be done for things that are good. The question is how do we (or our agent wielding successors) only work on good stuff and not bad stuff.
Not passing comment on the analogy (unless..?) but the categories of machining work it makes sense to be CNC-only are not that broad. It's just that there's a lot of times you'd want 50-10,000 identical widgets. There's always going to be a reason to pick up a file -- and often that's the best way to get the highest quality work. :)
I’d say the closer analogy to CNC is the compiler. The input to CNC is still a precise transformation of the intent of the designer. It does the work faster but it’s the same work. On the other hand, sometimes a human needs to precisely define the lower level, doing some manual filing because the cutting tool won’t fit in the space, or writing some assembly because the compiler doesn’t know how to do indirect threaded code.
As a craftsperson or client you may look at the result and miss the imperfections (the “hand”, it’s called) of the old way: the curvature is implausibly perfect, or the assembly is too clever to have been written by a human. But you can always see the human intent everywhere.
LLMs, on the other hand, take imprecise descriptions and turn them into precise output by making stuff up instead of waiting for the human to fill the gap. It’s the “imprecise description” part that’s really new. I don’t know of a very good analogy for that in any pre-existing tool.
I see the "imprecise description" as a spectrum;
Somewhere there is an optimizing compiler, where you give it intended semantics and it "makes stuff up" for the codegen that satisfies those semantics, hopefully in a way more optimal than the original description translated verbatim. Then somewhere far else on that spectrum is an LLM which does the same thing, but with general purpose tasks, not just codegen for a specified semantic operation set (can do it deterministically as well).
There's always been "imprecise translators". How people use them effectively is by building up and intuition or mental model about how that translator processes their input to help generate the desired output, even if they can't trace by hand what exact decisions it's making.
What would be the new thing in this case (genuine question)? Would it be the "codegen targets" of the translator, it's "acceptable frontend IRs", some other capability entirely?
I agree it's a spectrum, but at some point just saying "it's a spectrum" erases the interesting distinctions. The boundary of impreciseness that can't be crossed by the "compiler" used to be limited to a fairly narrow range. Think of the possible abstracts of a paper in a PLT journal.
But with an LLM you can literally say nothing but "make a website for scheduling a kids' soccer league" and it will do it. That is, even if I had a mental model, I didn't tell the "compiler" what it was. Not only that, while it's working the "compiler" can ask me what my mental model is, rather than just telling me the model I gave it is incomplete or inconsistent and stopping.
And where it really gets into a new category for me is that the output of the compiler isn't even defined. You could just as well say "make a presentation for a soccer league" or "get the accounting in order for my soccer league" or "automatically answer questions about our soccer league". The analogy just seems to completely fall apart at that point.
"Mental model" is an expectation of how the tool works / will translate or react to some given input. It's not something you tell the tool - it's how you reason about what to tell it. We do this for human personalities too.
In this case, the mental model I have for SOTA models when it comes to "make a website" is that it'll write some ugly js & HTML but it can get it done. But the mental model for a older smaller model is that ill need to give it a lot of guidance to achieve that.
For the case of "LLM can ask clarifying questions", this is a harness diff. When you type statically detected UB or compile errors in the compiler example, it technically could interactively ask you want you mean for each instance. The rust compiler does half of this as well. It's just usually inefficient when "IDE is a chat interface" isn't true.
The output of LLMs is defined as much as optimizing compilers is: you give some code and it has infinite ways to achieve some set of behavior. Maybe I'm misunderstanding what you mean by defined?
Sorry, I misread your earlier comment. In my reply when I said "mental model" I meant your mental model of the thing you're trying to build, not of the tool.
The output of LLMs is defined as much as optimizing compilers is
It definitely is not. Compilers perform a very well defined transformation from input to behavior (not 100% defined, but as close as practical politics can get it). A compiler that "optimizes" by violating that definition is a broken compiler. (The 1% that's undefined causes a lot of discussion, which takes place while everyone relies absolutely on the other 99% being correct.)
Whereas in most cases you can't even tell if the output of an LLM did achieve desired behavior, because the input isn't precise enough to determine the desired behavior in the first place. LLMs not backstopped by deterministic tools (compilers, test harnesses, proof engines, even just plain reliable arithmetic) in a loop have a hard time even making artifacts that are functional.
Huh, https://www.destroyallsoftware.com/talks/useing-youre-types-good is gone. Would have liked to see that. Post itself seems kind of light on content.
Looks like the wayback machine saved a copy: https://web.archive.org/web/20200416083233/https://www.destroyallsoftware.com/talks/useing-youre-types-good
You know what doesn't dislike AI coding? All the services and products which work, and which people are paying for and using.
Some questions anyone can feel free to answer, 1) what's the difference between humans synthesizing code and content vs. if an AI does it, and 2) when we express anxiety about lost labor, I am unsure how that's related to technology or engineering discourse. Isn't that more a question about governance? Are we then saying there should basically be something akin to UBI to deal with loss of labor, or provide means in a less-work/post-human-work society? 3) how do people generally feel about post-work societies, and AI/socialist governance frameworks being enablers of that?
Note that I edited this comment to make it more focused on my questions.
Also, humans can learn from mistakes. Currently, LLMs have trouble with that.
[1] A friend of mine is a writer and editor at a web marketing company. He's being forced to use LLMs at his job. When he started it, there were over 50 employees; now there are seven. And it's expected for him to write three to four 2,000 word articles (about law) per day. He can't quit the job due to his needing insurance (cancer treatments, plus some other medical issues he's dealing with) and he's even afraid of taking time off (he has around 200 hours of accumulated time off) for fear of being let go. It's a horrible situation.
The lack of creativity in posts complaining about AI stealing their creativity while regurgitating the same handful of talking points ad nauseam is kind of ironic to be honest.