cory doctorow stumbles into the paradox of code

Is code really a liability instead of an asset? Actually, it's more like Schrodinger's cat...

Cory Doctorow is probably the hottest commodity in the tech culture space right now thanks to coining the term enshittification to describe why and how digital monopolies and oligopolies use and abuse their customers and users. Generally, his thesis is that the corporate over-consolidation that killed competition and is leading to a zero click web, is the root of many evils and the best solution is to force big platforms to split up and actually compete with sustainable business models.

On broad things like this, Doctorow is pretty good. But sometimes, when he ventures into the weeds, he can lose the plot a bit. Not enough to undermine his point, but in a way that erases important nuance, especially if you want to apply his ideas to the real world. And that’s the case with one of his latest essays positing that code is a liability, not an asset, therefore, an AI that churns out 10,000 times the code than a human is a machine to produce exponential liabilities, not an asset.

What he goes on to describe in great deal — new code piled on top of old code to fix bugs or add new features in ways that slow the software, or break it at critical times, or make it way more convoluted and harder to maintain — is a well known concept in computer science called the law of leaky abstractions. (I actually did a short video on this subject and how AI generated code can make it exponentially worse.)

“Hold on a moment there Greg, it sounds like you agree with Doctorow. Layers of vibe coded features and abstractions on top of vibe coded features and abstractions, all at the mercy of a questionable base of old code is going to be a disaster. So, what’s the problem here?”

Well, the problem is that Cory is so focused on the effects of bad code, he mixed up three closely related concepts, then extrapolated to the point of hyperbole so he can argue for throwing out the baby with the bathwater. And the bath. And the pipes. And to tear up the tiles on the way out for good measure.

Writing and designing code, code maintenance, and code automation are different in ways that merit distinction. When done right, code is absolutely an asset because it’s what executes to provide the utility people need. It doesn’t have to end up being the pyramid of clusterfucks it so often does.

It just happens because the culture focused on quantity and velocity pushes it to be that way, and incentivizes abstractions not as useful tools, but as shortcuts. Digg’s and Betaworks’ adage of “fuck it, ship it” means that consequences — like polluting the web to the point of uselessness and kneecapping your own flagship tools — are tomorrow you’s problem, and fuck that person. Not in the fun way either.

And therein lies the problem and why AI generated code is a liability, especially when you have profoundly inexperienced vibe coders who don’t actually know how to write real code, churning out feature after feature and patch after patch.

They have no clue how to verify that what was generated is correct, can’t jump in to fix a thorny problem, and no one is going to teach them, using the LLM they use as a handy excuse. So, they’ll end up churning billions of lines of code full of bugs in apps no one asked for, but LLM owners sure seem enthusiastic about.

They’ve convinced themselves we’ll cheer for billions of apps, even though we really just need a thousand or two that work reliably, and are polished with love for the craft and care for the user.

Code for the sake of quantity and metrics is a liability, yes, and the pitch that you will be able to generate thousands of times more code than a human in a matter of a few weeks, is like saying that even though you only have a thousand acres, you’ll generate enough manure to fertilize every arable square millimeter on Earth. Not well, but damn is it gonna be a lot.

But code designed to be easy to maintain, that prizes simplicity and reliability, that’s written with the user in mind and LLMs simply help with the boring, tedious, and rote parts of the process with a professional’s oversight… That’s an asset. That’s what we once again need to strive for as an industry. We need tools built to last not 18 months but 18 years, or better yet, 180, and maybe even beyond.

I can assure you that very few programmers out there have a real passion for working on the same exact kinds of apps, ceding more room to LLMs, and wading through the endless ocean of Jira tickets and Agile jargon. They’d much rather build tools that can last and move on to another challenge. This is why unlike Doctorow, I don’t blame the code. I blame the industry’s decline into mountains of unwanted slopware against the wishes of their users and advice of the experts they hire.