Cory Doctorow used a July 2 post on Pluralistic to sharpen a distinction that keeps getting flattened in AI coding debates: software written to solve a one-off personal problem is a different beast from code that other people must run, maintain and extend.
Doctorow’s target is the lazy argument that AI-generated code is either liberation or rot. He says both outcomes can be real, depending on who controls the tool and what kind of work the code is expected to do. That sounds obvious until a manager starts treating a chatbot transcript as a staffing plan.
Doctorow connects the point to his earlier “centaur” and “reverse centaur” framing. In his terms, centaurs are workers who decide how and when to use automation. Reverse centaurs are workers forced to serve the automation system, checking its output, carrying its risk and taking blame when it fails. He says that difference explains why some experienced programmers report doing excellent work with AI while others describe accumulating dangerous technical debt.
The same split, Doctorow argues, applies to vibe coding. He says AI-assisted coding can help people make small tools for their own use, in the same tradition as shell scripts, Applescript, Hypercard and Visual Basic. These systems let non-specialists adapt computers to their own needs without waiting for a professional programmer or paying for every tweak.
That use case changes once the output becomes production code. Doctorow describes production code as a liability for technology companies: once software is depended on by others, somebody must understand it, operate it, fix it and improve it. “It runs” is not the same as “the team can live with it.”
The canonization problem
Doctorow builds on an essay by Kellan Elliott-McCrea about AI and mathematical theorem proving. Elliott-McCrea cites mathematician Alex Kontorovich’s idea of “canonization,” the process of turning a local proof or formalization into reusable library mathematics that fits with existing definitions, abstractions and interfaces.
Applied to software, Doctorow says, canonization is the work that turns a working hack into something future engineers can build on. Elliott-McCrea describes the goal as code produced in a social setting that leaves a team ready to operate, iterate and improve it. Doctorow contrasts that with disposable software that exists only to complete today’s task.
Doctorow does not dismiss disposable code. He says one-off software can have value even when a trained engineer would call it bad code. The problem starts when companies pretend those quick outputs are accretive work, meaning work that adds to a shared base of knowledge rather than draining it.
Elliott-McCrea, as summarized by Doctorow, treats free and open source software as a major part of that canon: decades of public, understandable work that others can build on. Doctorow says AI systems consume that stock of human-made software while the AI industry undervalues the cleanup, integration and documentation needed to replenish it.
Doctorow’s broader claim is economic as much as technical. He argues that the money poured into AI pushes companies toward reverse-centaur labor: fewer workers, more chatbot output and remaining staff forced to review machine-generated work at high speed. That is a claim about incentives, not a benchmark result, but it lands on a practical warning for software teams: generated code still needs humans to make it legible, safe and worth keeping.
This story draws on original reporting from Pluralistic.
