Comment by leecommamichael
17 hours ago
> Ignoring outright bad code, in a world where functional code is so abundant that “good” and “bad” are indistinguishable, ultimately, what makes functional AI code slop or non-slop?
I'm sorry, but this is an indicator for me that the author hasn't had a critical eye for quality in some time. There is massive overlap between "bad" and "functional." More than ever. The barrier-to-entry to programming got irresponsibly low for a time there, and it's going to get worse. The toolchains are not in a good way. Windows and macOS are degrading both in performance and usability, LLVM still takes 90% of a compiler's CPU time in unoptimized builds, Notepad has AI (and crashes,) simple social (mobile) apps are >300 MB download/installs when eight years ago they were hovering around a tenth of that, a site like Reddit only works on hardware which is only "cheap" in the top 3 GDP nations in the world... The list goes on. Whatever we're doing, it is not scaling.
This is the "artisanal clothing argument".
I'd think there'll be a dip in code quality (compared to human) initially due to "AI machinery" due to its immaturity. But over-time on a mass-scale - we are going to see an improvement in the quality of software artifacts.
It is easier to 'discipline' the top 5 AI agents in the planet - rather than try to get a million distributed devs ("artisans") to produce high quality results.
It's like in the clothing or manufacturing industry I think. Artisans were able to produce better individual results than the average industry machinery, at least initially. But overtime - industry machinery could match the average artisan or even beat the average, while decisively beating in scale, speed, energy efficiency and so on.
The issue is that code isn't clothing. It's the clothing factory. We aren't artisans sewing clothing. We're production engineers deciding on layouts for robots to make clothes most efficiently.
I see this type error of thinking all the time. Engineers don't make objects of type A, we make functions of type A -> B or higher order.
Go concrete. In FAANG engineering jobs now what % is this factory designer category vs what % is writing some mundane glue code, moving data around in CRUD calls, or putting in a monitoring metric etc?
Once you look at the present engineering org compositions see what's the error in thinking.
There are other analogy issues in your response which I won't nitpick
1 reply →
Artisanal clothing is functionally equivalent to mass-produced clothing, but more expensive.
Much of contemporary software is functionally equivalent but more expensive to run and produce than previous generations. Chat, project management, document editing, online stores… all seem to have gotten more expensive to produce and run with little to no gain in functionality.
Complexity in software production and tooling keeps increasing yet functionally software is more or less the same as 20 years ago (obv. excluding advancements depending on hardware like video, 3D rendering, LLMs, etc.
> industry machinery could match the average artisan or even beat the average
Whether it could is distinct from whether it will. I'm sure you've noticed the decline in the quality of clothing. Markets a mercurial and subject to manipulation through hype (fast fashion is just a marketing scheme to generate revenue, but people bought into the lie).
With code, you have a complicating factor, namely, that LLMs are now consuming their own shit. As LLM use increases, the percentage of code that is generated vs. written by people will increase. That risks creating an echo chamber of sorts.
I don't agree with the limited point about fast fashion/enthittification, etc.
Quick check: Do you want to go back to pre-industrial era then - when according to you, you had better options for clothing?
Personally, I wouldn't want that - because I believe as a customer, I am better served now (cost/benefit wise) than then.
As to the point about recursive quality decline - I don't take it seriously, I believe in human ingenuity, and believe humans will overcome these obstacles and over time deliver higher quality results at bigger scale/lower costs/faster time cycles.
1 reply →
> This is the "artisanal clothing argument".
> it is easier to 'discipline' the top 5 AI agents in the planet - rather than try to get a million distributed devs ("artisans") to produce high quality results.
Your take essentially is "let's live in a shoe box, packaging pipelines produce them cheaply en masse, who needs slow poke construction engineers and architects anymore"
Where have I said engineers/architects aren't necessary? My point is that it is easier to get AI to get better than try to improve a million developers. Isn't that a straightforward point?
What the role of an engineer in the new context - I am not speculating on.
1 reply →
Except I am not talking about clothing. You are guessing when you say "I'd think" based on your comparison to manufacturing clothing. Why guess and compare when you have more context than that? You're in this industry, right? The commodity of clothing is not like the commodity of software at all. Almost nothing is, as it doesn't really have a physical form. That impacts the economics significantly.
To highlight the gaps in your analogy; machinery still fails to match artisan clothing-makers. Despite being relatively fit, I've got wide hips. I cannot buy denim jeans that both; fit my legs, _and_ my waist. I either roll the legs up or have them hemmed. I am not all that odd, either. One size cannot fit all.
One issue is that tooling and internals have been optimized for individual people's tastes currently. Heterogeneous environments make the models spikier. As we shift to building more homogenized systems optimized around agent accessibility, I think we'll see significant improvements
Elegantly, agents finally give us an objective measure of what "good" code is. It's code that maximizes the likelihood that future agents will be able to successfully solve problems in this codebase. If code is "bad" it makes future problems harder.
> Elegantly, agents finally give us an objective measure of what "good" code is. It's code that maximizes the likelihood that future agents will be able to successfully solve problems in this codebase. If code is "bad" it makes future problems harder.
An analogous argument was made in the 90's to advocate for the rising desire for IDEs and OOP languages. "Bad" code came to be seen as 1000+ lines in one file because you could simply conjure up the documentation out-of-context, and so separation of concerns slipped all the way from "one function one purpose" to something not far from "one function one file."
I don't say this as pure refusal, but to beg the question of what we lose when we make these values-changes. At this time, we do not know. We are meekly accepting a new mental prosthesis with insufficient foresight of the consequences.