The difference between "today's task" and "accretive work"

Today's links

• The difference between "today's task" and "accretive work": Sometimes, "I got it working" is fine, but sometimes it isn't.
• Hey look at this: Delights to delectate.
• Object permanence: Series of tubes; Paralyzed teen beaten bloody by TSA; "Ultra unreal" Chinese lit; London property prices v Brexit; Biden v surprise billing; "Feeding Ghosts."
• Upcoming appearances: London, Edinburgh, Sydney, Melbourne, Brighton, London, South Bend.
• Recent appearances: Where I've been.
• Latest books: You keep readin' em, I'll keep writin' 'em.
• Upcoming books: Like I said, I'll keep writin' 'em.
• Colophon: All the rest.

The difference between "today's task" and "accretive work" (permalink)

One thing I've learned about paradoxes: often the answer to the riddle of "how can this one thing have such a contradictory set of features and effects?" is "it's not one thing, it's two things*."

That's the idea that set me on the path to writing about "reverse centaurs" and AI. I was hearing from experienced programmers whom I knew to be reliable narrators of their own experience who described how AI was letting them write the best code of their lives; and from equally experienced and reliable coders who described a nightmare of tech debt: "I work in aviation, and I just don't think anyone should ever fly again, those things are now unsafe at any altitude, thanks to the code I had to sign off on":

For so long as I thought of both of these groups as doing the same thing and getting wildly different outcomes, this was a paradox. But as soon as I realized that the former group were "centaurs" (workers who get to decide and direct their adoption of automation) and the latter were reverse centaurs (workers who were conscripted to serve as peripherals for automation systems), it all snapped into place. It only looked like they were doing the same thing – they were actually engaged in fundamentally different activities, which is why they were having such different experiences.

The same goes for vibe coding. Plenty of people I knew had gotten real value out of vibe coding personal utilities that made things better for them in a way that I instantly recognized from a life spent around people who'd been able to adapt and customize the systems they used to make their lives better:

Vibe coding can be seen as part of a lineage that includes shell scripting, Applescript, Hypercard and Visual Basic: ways for technical novices to directly create personal software, without having to ask a programmer to interpret their needs (and without having to pay every time they wanted to do something new with their computers):

But if that's so, how to make sense of the seeming paradox of all that tech debt? For a tech company, code is a liability, not an asset:

AI's pitch to bosses is that they can fire most of their workers in order to terrorize the remainder into tolerating a working life wherein they are made to mark the AI's homework, at superhuman speed, and to assume the blame when it goes wrong. This is obviously a terrible way to write code:

But it's also obviously going to produce terrible code:

So is vibe code a way of empowering people to have the personal, vernacular tools that they design and adapt as they see fit? Or is it a way to shovel technological asbestos into the walls at scale, filling up our high-tech society with ghastly, lethal technical debt we'll be digging our way out of for generations?

Again: the paradox falls away once you realize that personal software you write for yourself is fundamentally different from "production code" that other people have to use, maintain and improve.

In an essay inspired by some thoughts on AI and mathematical theorem proving, Kellan Elliott-McCrea crystallizes this distinction in a really sharp way, bringing in Alex Kontorovich's idea of mathematical "canonization":

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… Canonization often changes the picture itself: the definitions, the abstractions, the API, and sometimes even the statement…

Elliott-McCrea posits that making code that is "socially constructed in a way that leaves the team prepared to operate on it, iterate it, and improve it" is the difference between "I got it working" and "something the future can build on."

He's not claiming that "I got it working" is worthless. 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."

Canonization is accretive. To canonize code is to make it "legible to systems of humans and non-humans operating on it." Free/open source software is the backbone of the canon: "decades of…intelligible, build-on-able work, sitting in public repos."

My "reverse centaurs" thesis isn't just a way to understand how programmers who seem to be doing the same thing can have such different effects. It's also about how the way that 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 with defective chatbots backstopped by the jobspocalypse's terrorized survivors, who can be made to endlessly toil away at marking the AI's homework because there are so many other workers who'll take their jobs if they refuse.

The point being that while centaurs are good and reverse centaurs are bad, the AI bubble requires the production of reverse centaurs, to the exclusion of centaurs.

In a similar vein, Elliott-McCrea describes how the imperatives of the AI industry are devouring its seed-corn – consuming the canon without putting anything new back in it. In the same way that AI can do endless theorem-proving but is essentially useless for creating "library mathematics: general, reusable, coherent, efficient, and compatible with the rest," AI can write a lot of running code, but the AI industry is further devaluing the already undervalued work of cleanup and canonization. As Elliott-McCrea writes, "the social production of knowledge [is] the seed corn."