"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.
I'm imagining the Silicon Valley scene where the character Gilfoyle has set up a loud death-metal automated noise that plays whenever the price of Bitcoin meets certain conditions... except the trigger is some kind of code-quality metric, the effect is my machine shouting at me to become serene.
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.
I also think there are areas where automating things is clumsy.
My pet peeve is that macos is really unfriendly to people solving their own problems.
It is really hard to script anything.
I know that there are shell scripts. I know that there is applescript and automator.
In my experience, if you want to do some script-level task to make your life easier - the effort required is high and the chances of success are uncertain.
Is this by design? Do they want you to buy your tools and scripts instead of easily creating them yourself?
If you have the perseverance to automate things, you have to dig deep into the apple-invented compiled languages objective-c or swift.
Now with ai, I suspect people will be able to leapfrog over the no-scripting canyon and do the things they want.
I found an excellent way to avoid premature abstraction and optimization and to write better software in general was to explicitly consider v1.x a throw-away.
Build something expedient that works well enough to deploy in the field, get actual user feedback and system metrics (e.g., where are the actual bottlenecks). Do a few iterations on user feedback and system metrics. NOW, you are much further down the road to a true final spec, and you can use that real information to design the real system to scale up on.
One Test Is Worth A Thousand Opinions.
This plan first tests your ideas against the real world of users, hardware, and data flows, and keeps a lot of technical debt out of the scaling system.
I discovered it a bit by accident, having previously been really big on early abstraction and planning, but sort of having to do this in one startup, and it was a real eye-opener how well it worked.
Over many years I've tried to (unsuccessfully) coin the phrase "Design for deletion."
The code in front of you works today, but will become unfit for purpose and un-salvageable, and we want to ensure that when that inevitable end happens, there is a sane and safe way to systematically chop it out and replace it with something else, something you are not capable of predicting.
There's substantial overlap with general principles like loose-coupling and modularity, but the framing changes how people apply them: Instead of trying to create durable Amazing-Thing which will be used for many years by people amazed at your foresight making it "flexible" and "modular" and "customizable", you focus on creating Inoffensive-Thing which can be easily killed off or dismantled for useful parts.
This is one of the pragmatic reasons that microservices can be a useful tool in a complex system. The enforced boundaries at every level - build, deployment, API, and team responsibility - make it easier to swap out, deprecate, or eliminate microservices than tends to be the case when the code is embedded in some larger context.
Part of why I like "tech debt" as a term. Much like actual financial debts, some tech debt has a low enough interest rate or is easy enough to declare bankruptcy on that it's not worth paying off.
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.
I cannot overstate just how much I love working on stuff in Excel and Google Sheets. It's the most popular programming language because it's incredibly intuitive to people at all levels of programming experience (especially the "none" level), it offers instant feedback, and in many cases, the results are trivially verifiable.
It does have its flaws, that you've pointed out - there's no good way to write tests, I'm not aware of any good way to have any sort of source control, and modularity is basically non-existent.
But, damn - if I have a bunch of data I need to go through and/or present, Sheets is usually my go-to. I genuinely love it when my spouse asks me to troubleshoot some Sheets stuff for her.
> 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.
>Spreadsheet certainly are visual programming languages: by any measure, by far one of the most common most widely used types of visual programming languages in the world.
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
That’s a good point. I am torn between two competing strains of thought, though:
- on the one hand, time-to-market is super important. Getting to the right place faster is obviously better.
- on the other hand, figuring out right product/right fit is hard, and if a business spends that much cost every 3 days chasing every idea (most of which may be bad ideas), they’ve probably wasted a lot of money.
Obviously token costs are cheaper than developers, and local models would reduce costs still further. But the thought I keep coming to is: maybe there’s a benefit to slowing down and not jumping to implement?
I usually hear the opposite side (better to implement 10 things and throw out 9 of them, easier to react to prototypes, etc.). But I also think the infinity of possible ideas doesn’t get smaller when you throw more engineers or compute at it. You just end up exploring more, possibly bad ideas. This works out if exploring more of the space builds a greater understanding of the problem and increases the likelihood that one of your choices pans out. But the cost of exploring the space isn’t $0 and 0 time.
Replace "plenty" with "all". At that cost, there is not a single business out there that won't benefit from a tool somewhere in their operations that they couldn't have invested in before.
It would be a real win if you could get it. However I don't see it happening. AI has been around long enough that if it was we would see it in new features by now.
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.
In my previous job I was working much and doing few meetings. Then USA management decided we should have 10x more meetings, because they need to know the progress hour by hour and see that green bar progress, but also somehow expected the same pace.
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.
AI makes it cheaper to create working fragments. It does not automatically make those fragments part of a maintainable system. In practice it may make the canonization step more important not less
This article ended waaaay too abruptly. Reverse Centaurs and Canonization would seem to be orthogonal dynamics, and there was synthesis to be had between them.
Centaur + no Canonization -> personal infrastructure, MVPs. probably ever-accruing tech debt, but the scale is limited so it probably doesn't matter
Centaur + Canonization -> libre software, companies with empowered employees. The Canonization process is going to have some differences now that the goal now includes consumption by an LLM.
Reverse Centaur + no Canonization -> Ever accruing tech debt, eventually leading to a situation where nobody understands how the "magic box" works and everyone is powerless to fix it when it breaks down (tech debt accrues to a level where an LLM can no longer achieve the desired results)
Reverse Centaur + Canonization -> It's certainly possible to have an automated process that distills and compresses knowledge at one stage into a succinct representation that can be used down the line. The open question is whether a company could arrive at this with disempowered reverse centaurs, or whether they're doomed to the previous option
Enumerating those 4 quadrants, I don't think I'm even doing a good job capturing where I had thought the article was going to go. But I'm having a hard time getting it back now.
> By canonization, I mean the process of taking a local, one-off formalization and turning it into library mathematics: general, reusable, coherent, efficient, and compatible with the rest
I think this kind of work is constantly misunderstood and undervalued. I don't really see it as a binary thing, more like a complex skill that most people are terrible at, some are good at, and a handful of giants use to be just ridiculously productive in their field.
It reminds me of hedgehogs and foxes - foxes tend to be bad at making one off progress on their own, but are critical for accretive work.
Also I was reading a textbook the other day and thinking wow, it is absurd how much more valuable these things can be than other resources, and it's exactly because they canonize. It would be a massive loss if they stop getting written.
Corey laid out this line of thinking on a July 1 episode of the Galaxy Brain podcast. It was a good listen and I generally think he has some interesting points, but I also can't help but think that he does himself a disservice by having such a consistently negative bias toward AI and tech in general.
Most of the time he comes off as an objective thinker, but those are really discounted by moments where his own dogma leads him down a path of making weakly supported points that seem like they come more from a place of anger.
He doesn't have a negative bias towards tech if you pay attention. He often talks about how he personally uses AI.
He has a negative take on a lot of the business practices around AI and tech. While he is consistently harsh on that front, I don't find it to be weakly supported at all, especially when you realize his criticism is focused on business and implementation, not the tech.
> 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.
When one cannot determine right or wrong its easy to ride the fence and try to please everyone and rationalize motivations and outcomes.
If vibe code is not production code than you are just "reading" your fathers playboy magazines "for the articles" and creating tech debt you or nobody else can maintain.
If you read between the lines there I think vibe coding is a very "generous gesture" towards the folks "doing this"
Also the article bugs me referring to programming paradigms like visual basic as "equivalent to" vibe coding. That is factually incorrect and should be stricken from the record.
Yes, the way the URLs are interspersed between short passages makes reading it difficult. It's like reading an article on a news site without an adblocker.
No mention of chikenized reverse-centaurs in this piece?
I find these neologisms helpful as they quite precisely capture the intended meaning and are easy to remember. Doctorow is an impressive and entertaining communicator, and being an author he needs to market himself and his work, so fair play to him for trying to score a hit follow up to "enshittification".
The earliest use of "centaur" in this sort of context I know of is Kasparov's advanced chess idea from the late 1990s: "a bad (chess) player with a good computer program will always beat a good player with a bad program". How far we travelled since then...
There's a third case between "today's task" and "accretive work" that I lived through on The Sims, and it's the one that scares managers the most: a system that IS accretive work, but looks exactly like a pile of disposable hacks for most of its life.
Chris Trottier, one of the designers of The Sims and The Sims Online, called the method "Design by Accretion" and "Tuned Emergence" in an interview with the Armchair Empire that I republished on my old blog.
Her description: The Sims and SimCity were incrementally assembled out of "a mass of separate components", like a planet forming out of a cloud of dust -- they had to reach critical mass before tuning could even begin.
Before it was tuned, The Sims was known inside the company, not very affectionately, as "the toilet game", because there wasn't much else to do. SimCity 2000 wasn't fun until six weeks before it shipped.
The Sims didn't come together until a couple of months before ship. In her words: "Being involved in that tuning process, and seeing the game take shape from what had previously been a mass of separate components, was one of the most powerful experiences of my career."
The hard part wasn't the code -- it was explaining to EA not to panic. By every rule in EA's playbook the toilet game would never work, and it took Will Wright's tremendous stamina to keep it from being cancelled. Here's a screen recording of the actual June 1998 "Sims Steering Committee" build we showed EA to buy another year and a half -- bathtubs placeable on hills, placeholder pie menus, Archie Bunker permanently holding a burning cigar:
The distinction Kontorovich/Elliott-McCrea call "canonization" is what Chris called tuned emergence: the late, undervalued pass that turns an accreted mass into a coherent system.
What made The Sims accretive rather than disposable wasn't visible in the code mid-accretion -- it was that the tuning pass was a committed part of the method, held by people with the authority and stamina to protect it.
Which suggests the real question to ask about any AI-generated pile of working fragments isn't "is this slop?" but "who is signed up to tune it, and will management hold its nerve until they do?"
A toilet game with a Will Wright becomes the best-selling PC game of all time. A toilet game without one stays a toilet.
I've had the good fortune to meet Cory many times over the past twenty years. I don't agree with everything he writes, but he's earned the right to be on of those authors I keep reading because he may end up changing my thinking.
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)
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...
I use AI a lot but am not addicted to it. I know it seems something every addict would say, but simply it makes things faster. You can't really take responsibility for something it makes that you don't already know how it operates, or how should operate. That's the line between what you can sell to your client, or your boss, without it blowing up in your face when things go wrong. In theory everything I build with AI I can build by hand, but in many more days.
A builder is not addicted to their tools, but he won't certainly start a project without them, if they are available. Yet, he could work without some of them. Give a circular saw to someone that can't use it, and nothing good comes out of it. Give AI to a non coder, and nothing good (that lasts) will come out of it.
I've been telling myself these lies too. The truth is it sometimes gets it right, but you can't predict it. Yet you still try, every time. It nags at you to try another spin if you try to quit it. I know what addiction feels like and I've never felt it before from a tool.
Don't get me wrong, I totally understand being in love with tools, because I love tools too. I fell in love with Emacs some 15 years ago and it's still going strong. I also love my santoku knife and if I had a tracksaw I'd definitely relish cutting boards. But those tools still need to prove their worth. Nobody is using the tracksaw for crosscuts because they can't imagine using a mitre saw any more. That's not how it works. But despite LLMs getting it wrong about as often as they get it right it's just try again, tweak prompt, try again, without ever questioning whether this is really the right tool for the job, because, unlike normal tools, it's hitting those dopamine spots again and again, for very little input. It's an absolute classic recipe for addiction.
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.
"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.
> 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.
Well, It's really early in the morning and I've got the quote of the day already
This is a slightly modified version of the serenity prayer of AA fame.
Yes, I know, but I substituted that one in daily usage for just shouting "SERENITY NOW" at maximum volume.
That seems similar to the "God give me patience, but I need it RIGHT NOW" prayer.
> shouting "SERENITY NOW" at maximum volume.
I'm imagining the Silicon Valley scene where the character Gilfoyle has set up a loud death-metal automated noise that plays whenever the price of Bitcoin meets certain conditions... except the trigger is some kind of code-quality metric, the effect is my machine shouting at me to become serene.
live, laugh, cruft
Though I walk through the valley of technical debt I shall fear no eval
Ye who enter this cursed codebase, shall abandon all hope of fixing it.
Nor the CI test that fails each day
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.
I also think there are areas where automating things is clumsy.
My pet peeve is that macos is really unfriendly to people solving their own problems.
It is really hard to script anything.
I know that there are shell scripts. I know that there is applescript and automator.
In my experience, if you want to do some script-level task to make your life easier - the effort required is high and the chances of success are uncertain.
Is this by design? Do they want you to buy your tools and scripts instead of easily creating them yourself?
If you have the perseverance to automate things, you have to dig deep into the apple-invented compiled languages objective-c or swift.
Now with ai, I suspect people will be able to leapfrog over the no-scripting canyon and do the things they want.
The real trick is recognizing when "disposable" code has quietly become infrastructure
Exactly THIS!
I found an excellent way to avoid premature abstraction and optimization and to write better software in general was to explicitly consider v1.x a throw-away.
Build something expedient that works well enough to deploy in the field, get actual user feedback and system metrics (e.g., where are the actual bottlenecks). Do a few iterations on user feedback and system metrics. NOW, you are much further down the road to a true final spec, and you can use that real information to design the real system to scale up on.
One Test Is Worth A Thousand Opinions.
This plan first tests your ideas against the real world of users, hardware, and data flows, and keeps a lot of technical debt out of the scaling system.
I discovered it a bit by accident, having previously been really big on early abstraction and planning, but sort of having to do this in one startup, and it was a real eye-opener how well it worked.
So you rediscovered "build one to throw away", popularized in The mythical man-month, afaik?
Over many years I've tried to (unsuccessfully) coin the phrase "Design for deletion."
The code in front of you works today, but will become unfit for purpose and un-salvageable, and we want to ensure that when that inevitable end happens, there is a sane and safe way to systematically chop it out and replace it with something else, something you are not capable of predicting.
There's substantial overlap with general principles like loose-coupling and modularity, but the framing changes how people apply them: Instead of trying to create durable Amazing-Thing which will be used for many years by people amazed at your foresight making it "flexible" and "modular" and "customizable", you focus on creating Inoffensive-Thing which can be easily killed off or dismantled for useful parts.
This is one of the pragmatic reasons that microservices can be a useful tool in a complex system. The enforced boundaries at every level - build, deployment, API, and team responsibility - make it easier to swap out, deprecate, or eliminate microservices than tends to be the case when the code is embedded in some larger context.
Love this framing, thank you.
Law of disposable infrastructure: The more temporary a fix is intended to be, the more likely it is to become load-bearing permanent infrastructure
General rule: temporary lasts longer than you think.
(in today's context: especially if you upload temporary Thing to GitHub & co)
>>> 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.
Fantastic
Part of why I like "tech debt" as a term. Much like actual financial debts, some tech debt has a low enough interest rate or is easy enough to declare bankruptcy on that it's not worth paying off.
We used to keep it in it's own separate thing: Microsoft Excel.
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.
[1] Further reading if you're interested - https://news.ycombinator.com/item?id=27048672
I cannot overstate just how much I love working on stuff in Excel and Google Sheets. It's the most popular programming language because it's incredibly intuitive to people at all levels of programming experience (especially the "none" level), it offers instant feedback, and in many cases, the results are trivially verifiable.
It does have its flaws, that you've pointed out - there's no good way to write tests, I'm not aware of any good way to have any sort of source control, and modularity is basically non-existent.
But, damn - if I have a bunch of data I need to go through and/or present, Sheets is usually my go-to. I genuinely love it when my spouse asks me to troubleshoot some Sheets stuff for her.
Yeah Google sheets is my go-to assistant these days Can't believe I used to ignore it before.
Have even gotten better with add-on like AppScript and the rest.
Even got a new tool called RowSink that helps me dump data easily into my sheets. So I'm kinda a maxed out Google sheets overlord right now.
> 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 think the argument is that AI changes the cost of creating that groundwork, not the definition of it
I mean a groundwork you can rely on for the rest of your code.
I'll take that one step further and claim that Excel is the world's most popular VISUAL programming language.
https://news.ycombinator.com/item?id=26668885
>Spreadsheet certainly are visual programming languages: by any measure, by far one of the most common most widely used types of visual programming languages in the world.
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
I suspect "same price, three days instead of three months" is a very real win for plenty of businesses
That’s a good point. I am torn between two competing strains of thought, though:
- on the one hand, time-to-market is super important. Getting to the right place faster is obviously better.
- on the other hand, figuring out right product/right fit is hard, and if a business spends that much cost every 3 days chasing every idea (most of which may be bad ideas), they’ve probably wasted a lot of money.
Obviously token costs are cheaper than developers, and local models would reduce costs still further. But the thought I keep coming to is: maybe there’s a benefit to slowing down and not jumping to implement?
I usually hear the opposite side (better to implement 10 things and throw out 9 of them, easier to react to prototypes, etc.). But I also think the infinity of possible ideas doesn’t get smaller when you throw more engineers or compute at it. You just end up exploring more, possibly bad ideas. This works out if exploring more of the space builds a greater understanding of the problem and increases the likelihood that one of your choices pans out. But the cost of exploring the space isn’t $0 and 0 time.
Replace "plenty" with "all". At that cost, there is not a single business out there that won't benefit from a tool somewhere in their operations that they couldn't have invested in before.
And it's certainly not the same price!
It would be a real win if you could get it. However I don't see it happening. AI has been around long enough that if it was we would see it in new features by now.
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.
Can they?
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.
But does what they present work for production or they present a demo and leave it to someone else to figure out how to make it work for real?
This is a running production service. The team was reduced to just these 2, per the lead's instuction.
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
It could be that the team was oversized and wasting time in meetings and AI has nothing to do with that.
Welcome to majority of the teams in our industry.
In my previous job I was working much and doing few meetings. Then USA management decided we should have 10x more meetings, because they need to know the progress hour by hour and see that green bar progress, but also somehow expected the same pace.
Exactly what I've found. It passes the sniff test, but it's now _more work_ to get it from there to actually working.
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.
AI makes it cheaper to create working fragments. It does not automatically make those fragments part of a maintainable system. In practice it may make the canonization step more important not less
This article ended waaaay too abruptly. Reverse Centaurs and Canonization would seem to be orthogonal dynamics, and there was synthesis to be had between them.
Centaur + no Canonization -> personal infrastructure, MVPs. probably ever-accruing tech debt, but the scale is limited so it probably doesn't matter
Centaur + Canonization -> libre software, companies with empowered employees. The Canonization process is going to have some differences now that the goal now includes consumption by an LLM.
Reverse Centaur + no Canonization -> Ever accruing tech debt, eventually leading to a situation where nobody understands how the "magic box" works and everyone is powerless to fix it when it breaks down (tech debt accrues to a level where an LLM can no longer achieve the desired results)
Reverse Centaur + Canonization -> It's certainly possible to have an automated process that distills and compresses knowledge at one stage into a succinct representation that can be used down the line. The open question is whether a company could arrive at this with disempowered reverse centaurs, or whether they're doomed to the previous option
Enumerating those 4 quadrants, I don't think I'm even doing a good job capturing where I had thought the article was going to go. But I'm having a hard time getting it back now.
> By canonization, I mean the process of taking a local, one-off formalization and turning it into library mathematics: general, reusable, coherent, efficient, and compatible with the rest
I think this kind of work is constantly misunderstood and undervalued. I don't really see it as a binary thing, more like a complex skill that most people are terrible at, some are good at, and a handful of giants use to be just ridiculously productive in their field.
It reminds me of hedgehogs and foxes - foxes tend to be bad at making one off progress on their own, but are critical for accretive work.
Also I was reading a textbook the other day and thinking wow, it is absurd how much more valuable these things can be than other resources, and it's exactly because they canonize. It would be a massive loss if they stop getting written.
Corey laid out this line of thinking on a July 1 episode of the Galaxy Brain podcast. It was a good listen and I generally think he has some interesting points, but I also can't help but think that he does himself a disservice by having such a consistently negative bias toward AI and tech in general.
Most of the time he comes off as an objective thinker, but those are really discounted by moments where his own dogma leads him down a path of making weakly supported points that seem like they come more from a place of anger.
He doesn't have a negative bias towards tech if you pay attention. He often talks about how he personally uses AI.
He has a negative take on a lot of the business practices around AI and tech. While he is consistently harsh on that front, I don't find it to be weakly supported at all, especially when you realize his criticism is focused on business and implementation, not the tech.
> 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.
When one cannot determine right or wrong its easy to ride the fence and try to please everyone and rationalize motivations and outcomes.
If vibe code is not production code than you are just "reading" your fathers playboy magazines "for the articles" and creating tech debt you or nobody else can maintain.
If you read between the lines there I think vibe coding is a very "generous gesture" towards the folks "doing this"
Also the article bugs me referring to programming paradigms like visual basic as "equivalent to" vibe coding. That is factually incorrect and should be stricken from the record.
Does this read a bit incoherent and hard to follow for anyone else? This pluralistic website itself seems a bit chaotic..
Yes, the way the URLs are interspersed between short passages makes reading it difficult. It's like reading an article on a news site without an adblocker.
It's a bit jarring, but after reading a couple of articles from the site (it gets posted here often) you adapt to its rythm
No mention of chikenized reverse-centaurs in this piece?
I find these neologisms helpful as they quite precisely capture the intended meaning and are easy to remember. Doctorow is an impressive and entertaining communicator, and being an author he needs to market himself and his work, so fair play to him for trying to score a hit follow up to "enshittification".
The earliest use of "centaur" in this sort of context I know of is Kasparov's advanced chess idea from the late 1990s: "a bad (chess) player with a good computer program will always beat a good player with a bad program". How far we travelled since then...
There's a third case between "today's task" and "accretive work" that I lived through on The Sims, and it's the one that scares managers the most: a system that IS accretive work, but looks exactly like a pile of disposable hacks for most of its life.
Chris Trottier, one of the designers of The Sims and The Sims Online, called the method "Design by Accretion" and "Tuned Emergence" in an interview with the Armchair Empire that I republished on my old blog.
Her description: The Sims and SimCity were incrementally assembled out of "a mass of separate components", like a planet forming out of a cloud of dust -- they had to reach critical mass before tuning could even begin.
Before it was tuned, The Sims was known inside the company, not very affectionately, as "the toilet game", because there wasn't much else to do. SimCity 2000 wasn't fun until six weeks before it shipped.
The Sims didn't come together until a couple of months before ship. In her words: "Being involved in that tuning process, and seeing the game take shape from what had previously been a mass of separate components, was one of the most powerful experiences of my career."
https://web.archive.org/web/20110408034710/https://www.donho...
Original interview:
https://web.archive.org/web/20111211182436/http://www.armcha...
The hard part wasn't the code -- it was explaining to EA not to panic. By every rule in EA's playbook the toilet game would never work, and it took Will Wright's tremendous stamina to keep it from being cancelled. Here's a screen recording of the actual June 1998 "Sims Steering Committee" build we showed EA to buy another year and a half -- bathtubs placeable on hills, placeholder pie menus, Archie Bunker permanently holding a burning cigar:
https://www.youtube.com/watch?v=zC52jE60KjY
The distinction Kontorovich/Elliott-McCrea call "canonization" is what Chris called tuned emergence: the late, undervalued pass that turns an accreted mass into a coherent system.
What made The Sims accretive rather than disposable wasn't visible in the code mid-accretion -- it was that the tuning pass was a committed part of the method, held by people with the authority and stamina to protect it.
Which suggests the real question to ask about any AI-generated pile of working fragments isn't "is this slop?" but "who is signed up to tune it, and will management hold its nerve until they do?"
A toilet game with a Will Wright becomes the best-selling PC game of all time. A toilet game without one stays a toilet.
It could be that this person has something profound to say, but ... it's about AI. Sigh and swipe left.
> It could be that this person has something profound to say
Some commentators are unknown for good reason, or otherwise not worth the effort to get to know. Cory Doctorow is not one of those.
I've had the good fortune to meet Cory many times over the past twenty years. I don't agree with everything he writes, but he's earned the right to be on of those authors I keep reading because he may end up changing my thinking.
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)
That feels overly reductive
Even if they're saying something bad about it?
AI is a tool. Stop treating it as something different.
The value you can extract from a tool depends on your skill in using it, and knowing when not using it.
A lot of the article is about who controls the tool, who is forced to use it and who absorbs the cost when it produces bad output
Yes, I was mostly agreeing with the article ;)
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...
A certain Calvin and Hobbes strip comes to mind https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg...
I use AI a lot but am not addicted to it. I know it seems something every addict would say, but simply it makes things faster. You can't really take responsibility for something it makes that you don't already know how it operates, or how should operate. That's the line between what you can sell to your client, or your boss, without it blowing up in your face when things go wrong. In theory everything I build with AI I can build by hand, but in many more days.
A builder is not addicted to their tools, but he won't certainly start a project without them, if they are available. Yet, he could work without some of them. Give a circular saw to someone that can't use it, and nothing good comes out of it. Give AI to a non coder, and nothing good (that lasts) will come out of it.
I've been telling myself these lies too. The truth is it sometimes gets it right, but you can't predict it. Yet you still try, every time. It nags at you to try another spin if you try to quit it. I know what addiction feels like and I've never felt it before from a tool.
You haven't met a builder with a really top-notch tracksaw.
Don't get me wrong, I totally understand being in love with tools, because I love tools too. I fell in love with Emacs some 15 years ago and it's still going strong. I also love my santoku knife and if I had a tracksaw I'd definitely relish cutting boards. But those tools still need to prove their worth. Nobody is using the tracksaw for crosscuts because they can't imagine using a mitre saw any more. That's not how it works. But despite LLMs getting it wrong about as often as they get it right it's just try again, tweak prompt, try again, without ever questioning whether this is really the right tool for the job, because, unlike normal tools, it's hitting those dopamine spots again and again, for very little input. It's an absolute classic recipe for addiction.
Guys really pushing to remain relevant with the reverse centaurs shtick.
First time I’ve heard it as a phrase, and it seems to be a useful label. What’s annoying you about it?
Since when did the distinction between use-cases stop being relevant?
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.
I pictured some perverse sexual act, involving a reverse mermaid.
[flagged]
Are you saying he's become ... enshitified?
Who would have ever predicted that??!