"There's plenty of space for "disposable and single use software." Sure, to a trained software engineer, this might be "bad code" but doing today's task has value, even if the code that performs that task isn't "accretive.""
Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.
That quote also resonated with me. It reminded me of "Perl, the write-only language"-meme of yore.
And I think there is a place for perl, just like there is a place for bash one-liners.
The authors example is personal software. The things we write to scratch our own little itches, that do not need to be shared or developed together with other people.
Isn’t this a question of how much the “terrorised survivors” spend on tokens to make the output “canonised”?
I think the main argument that the billions spent are not going to be recouped is accurate, but I strongly suspect the cost of producing high quality code will remain the same -just being produced faster (speed, cost, quality - you still only get to pick two)
If one Steve Yegge can burn tokens in “Gas Town” that cost as much as me and ten others then you have saved my salary but spent it on Steve’s token use for roughly the same code quality as me steve and ten others would have produced in three months - just it took steve three days
Same price, faster delivery. Is that a win ? I suspect that facebooks recent announcement (“we cannot think of enough things to do with software so who wants our GPUs?” Might suggest that it’s a business model problem more than a software probkem
Good analysis. Infact, there's collaboration cost in AI when it comes to quality, but a much smaller team can put out same quality things in a shorter time. As such it's same quality for cheaper, for sure.
What products are you talking about? Because I see smaller teams or one man bands putting out low quality prototypes, but not teams of 10 delivering a years work in a sprint.
I'm seeing that a tech lead is preferring to work with 1 other engineer on a large project, and they're thinking through and presenting the architecture to others. But in prior time, this project would have been the lead + 2 seniors + 4 entry to mid level engineers to do it.
Everyone else in the team is now just aware of what's happening, and understand the architecture from the meeting to review / discuss it. But implementation and rollout is fast and just by the 2 of them.
The lead told me maintaining the quality was so much easier for the 2 of them with the right AGENTS.md lines, as he didn't have to spend time fixing guiding many people to do the right thing in PR reviews.
There's a 'joke' that goes around occasionally that has some truth to it: "Excel is the world's most popular programming language." Occasionally it's 'Excel macros' or 'VBA' instead of just Excel.[1]
The core truth of it is that a massive amount, possibly most, of the world's software is not a carefully hand-crafted application in that lives in Github written by expert software developers. It's a heap of Excel functions in an XSLX file, with no tests, no source control, no PRs, and no real planning behind it. And it works for that one specific task that the person who built it needed at the time.
AI vibe-coding is probably filling in the middle-ground between that stuff and 'real' code - it does more than just building somehting to complete today's task, and it is accretive in the sense that someone can build on top of it, but it doesn't really look that way to someone used to working on 'proper' software.
> AI vibe-coding is probably filling in the middle-ground [..] and it is accretive in the sense that someone can build on top of it
To me 'accretive work' means something you do at a lower level than your task at hand which by itself doesn't count progress, but rather lay the groundwork for it so it's compounding from there on. AI has nothing to do with this.
I could write more, but I think it actually is different. The addictive nature and the way it makes you more and more dependent on it is quite different from other tools. I've never met a builder who is addicted to their circular saw.
These AI companies have stumbled upon the new cigarette. Did you know athletes in the 1920s would smoke cigarettes because they thought it improved performance? Cigarettes are just a tool, right? Of course, we could never be as stupid as they were...
> the capital was raised for AI requires that it produce as many reverse centaurs as possible, because the only way to recoup the farcical sums associated with AI production is to fire millions of workers and replace them
I'm not sure that this is the only way, just the way that selfish, sloppy, or impatient actors within business often work. If more wealth is created, more efficiencies found, more problems fixed, new jobs created, these would also bring the returns desired.
Realistically speaking, most programs, no, 90% of them are terrible. Including mine. I write terrible code too, so I'm in no position to judge.
The programs I've taken apart and looked at, even ones running in real industrial settings and large corporate factories, 90% of them are terrible.
Most code is just 'Today's Task.' The people who deny this are probably those working at IT service companies, because they build around maintainability and scalability.
But as you go down into hardware, there's an additional pressure: 'We don't know when this hardware will reach end-of-life.' The centaur metaphor is a simplified dichotomy. 'Centaur is good, reverse-centaur is bad.' But in reality, the vast majority of programs end up as disposable one-off code.
These days, AI related articles just seem to amplify whatever values people want to believe, turning into tribal warfare posts. Realistically speaking, you can write maintainable code with AI too. In fact, the 'Canonization' mentioned in this post is essentially pattern-templating, which AI does better.
The fundamental problem with AI code is that as the input prompt gets deeper, it introduces enterprise level complexity rather than the depth the program actually needs. I don't think that's the core issue here.
The advantage of human written code is that it can be complex when it needs to be and simple when it doesn't, but AI code tries to apply the same level of complexity everywhere. Honestly, the most widely used things in the world are CRUD, and I don't think they require that much complexity.
A good programmer applies the right level of complexity to the situation.
Even human written code leaks abstractions depending on requirements.
Take ORM as an example. Can you see the query count? Is there a rule to prevent N+1? Conditions like these keep getting added. It's just a matter of explicitly adding a layer to handle them.
These days, I see a lot of AI articles filled with nostalgia about how things were different in the past, and it catches me off guard. I'm not sure if that's really how Western programming culture was, or if where I am, the vast majority of work has always been just 'get it done.'
In my opinion, good programming is about choosing the right level of complexity based on the code's expected lifespan, likelihood of change, cost of failure, and transferability. I don't think everything needs to be maintainable.
So many of the articles I've read are like this—some of them feel as though AI gets mentioned out of the blue. I think you need to separate the wheat from the chaff. The ideas are still good, the author is just distracted.
I don't think it has something "profound" to say, but it also is a good article worth the read.
It's mostly about why some people enjoy working with AI ("I get to build things I can use, that I couldn't build otherwise!)" and others don't ("This code is all slop and nobody understands it, and it makes me sad")
It touches a little bit about those two perspectives in general, which he calls centaurs (in charge of the work) and reverse centaurs (the work is in charge of them)
There might be some relevance to the term reverse centaurs. I dont know if I buy it but it might take off as useful terminology.
A blog post loosely summarized as "HEY REMEMBER WHEN I COINED THAT TERM HERE ARE THE LINKS TO ALL THE TIMES I USED THE TERM AND HERES A NEW ANECODOTE ABOUT THE TERM" screams that its trying to force the use, and therefore the posters relevance.
Grant me the serenity to accept the bad code i shouldn't fix, the courage to change the code I can, and the wisdom to know the difference.
And I think there is a place for perl, just like there is a place for bash one-liners.
The authors example is personal software. The things we write to scratch our own little itches, that do not need to be shared or developed together with other people.
Fantastic
I think the main argument that the billions spent are not going to be recouped is accurate, but I strongly suspect the cost of producing high quality code will remain the same -just being produced faster (speed, cost, quality - you still only get to pick two)
If one Steve Yegge can burn tokens in “Gas Town” that cost as much as me and ten others then you have saved my salary but spent it on Steve’s token use for roughly the same code quality as me steve and ten others would have produced in three months - just it took steve three days
Same price, faster delivery. Is that a win ? I suspect that facebooks recent announcement (“we cannot think of enough things to do with software so who wants our GPUs?” Might suggest that it’s a business model problem more than a software probkem
What products are you talking about? Because I see smaller teams or one man bands putting out low quality prototypes, but not teams of 10 delivering a years work in a sprint.
Everyone else in the team is now just aware of what's happening, and understand the architecture from the meeting to review / discuss it. But implementation and rollout is fast and just by the 2 of them.
The lead told me maintaining the quality was so much easier for the 2 of them with the right AGENTS.md lines, as he didn't have to spend time fixing guiding many people to do the right thing in PR reviews.
The closest I can explain this phenomenon to thos who are surpised was by the LLM variance section in this recent blog post:
https://danluu.com/ai-coding/#llm-variance
The core truth of it is that a massive amount, possibly most, of the world's software is not a carefully hand-crafted application in that lives in Github written by expert software developers. It's a heap of Excel functions in an XSLX file, with no tests, no source control, no PRs, and no real planning behind it. And it works for that one specific task that the person who built it needed at the time.
AI vibe-coding is probably filling in the middle-ground between that stuff and 'real' code - it does more than just building somehting to complete today's task, and it is accretive in the sense that someone can build on top of it, but it doesn't really look that way to someone used to working on 'proper' software.
[1] Further reading if you're interested - https://news.ycombinator.com/item?id=27048672
To me 'accretive work' means something you do at a lower level than your task at hand which by itself doesn't count progress, but rather lay the groundwork for it so it's compounding from there on. AI has nothing to do with this.
The value you can extract from a tool depends on your skill in using it, and knowing when not using it.
These AI companies have stumbled upon the new cigarette. Did you know athletes in the 1920s would smoke cigarettes because they thought it improved performance? Cigarettes are just a tool, right? Of course, we could never be as stupid as they were...
I'm not sure that this is the only way, just the way that selfish, sloppy, or impatient actors within business often work. If more wealth is created, more efficiencies found, more problems fixed, new jobs created, these would also bring the returns desired.
The programs I've taken apart and looked at, even ones running in real industrial settings and large corporate factories, 90% of them are terrible.
Most code is just 'Today's Task.' The people who deny this are probably those working at IT service companies, because they build around maintainability and scalability.
But as you go down into hardware, there's an additional pressure: 'We don't know when this hardware will reach end-of-life.' The centaur metaphor is a simplified dichotomy. 'Centaur is good, reverse-centaur is bad.' But in reality, the vast majority of programs end up as disposable one-off code.
These days, AI related articles just seem to amplify whatever values people want to believe, turning into tribal warfare posts. Realistically speaking, you can write maintainable code with AI too. In fact, the 'Canonization' mentioned in this post is essentially pattern-templating, which AI does better.
The fundamental problem with AI code is that as the input prompt gets deeper, it introduces enterprise level complexity rather than the depth the program actually needs. I don't think that's the core issue here.
The advantage of human written code is that it can be complex when it needs to be and simple when it doesn't, but AI code tries to apply the same level of complexity everywhere. Honestly, the most widely used things in the world are CRUD, and I don't think they require that much complexity.
A good programmer applies the right level of complexity to the situation.
Even human written code leaks abstractions depending on requirements.
Take ORM as an example. Can you see the query count? Is there a rule to prevent N+1? Conditions like these keep getting added. It's just a matter of explicitly adding a layer to handle them.
These days, I see a lot of AI articles filled with nostalgia about how things were different in the past, and it catches me off guard. I'm not sure if that's really how Western programming culture was, or if where I am, the vast majority of work has always been just 'get it done.'
In my opinion, good programming is about choosing the right level of complexity based on the code's expected lifespan, likelihood of change, cost of failure, and transferability. I don't think everything needs to be maintainable.
It's mostly about why some people enjoy working with AI ("I get to build things I can use, that I couldn't build otherwise!)" and others don't ("This code is all slop and nobody understands it, and it makes me sad")
It touches a little bit about those two perspectives in general, which he calls centaurs (in charge of the work) and reverse centaurs (the work is in charge of them)
Some commentators are unknown for good reason, or otherwise not worth the effort to get to know. Cory Doctorow is not one of those.
A blog post loosely summarized as "HEY REMEMBER WHEN I COINED THAT TERM HERE ARE THE LINKS TO ALL THE TIMES I USED THE TERM AND HERES A NEW ANECODOTE ABOUT THE TERM" screams that its trying to force the use, and therefore the posters relevance.