Cory Doctorow has made a qualified defense of vibe coding, the practice of using automated tools such as large language models to generate software, arguing that its value depends on whether users can peel back the layers and learn what the machine produced.
In a July 3 essay on Pluralistic, Doctorow connects today’s LLM-generated snippets to older forms of semi-automated programming: browser View Source, copied JavaScript, Stack Overflow examples, macro recorders, Minecraft blocks, Scratch mods and BASIC listings typed out of magazines. His argument is not that generated code is production-ready. He says software written for one person’s own task is a different category from code meant to be maintained by others.
Doctorow frames the problem around “legibility,” meaning a user’s ability to understand a system well enough to repair it, improve it or know where to probe when it breaks. His first example is the CARDiac, short for Cardboard Illustrative Aid to Computation, a Turing-complete paper computer created at Bell Labs in 1968 to teach high school students how computers work.
Doctorow writes that his father brought home a CARDiac in the mid-1970s, when Doctorow was a child. Using it meant writing tiny programs on paper and moving tokens through slots representing memory and an accumulator. The exercise exposed the basic loop hidden inside electronic machines: crude operations repeated at speed by transistors. The lesson, in his telling, was not performance. Adding one and one was work. The point was that the mechanism could be seen and felt.
He uses the German term “Fingerspitzengefühl,” or fingertip feeling, for the intuition gained by doing the work at a low level. He says a similar thing happened later with an Apple II Plus. The machine came with schematics, and much of the software he used was written in BASIC. Programs could be listed, inspected and changed. Typing magazine code by hand forced him to find mistakes, deal with BASIC dialect differences and eventually invent crude debugging techniques for himself.
The early web repeated that pattern, Doctorow argues, because View Source put the page’s instructions one click away from the rendered result. A person could copy markup, change it, reload the page and see what happened. That loop made the web easier to learn than systems sealed behind polished interfaces and corporate hand-waving.
Doctorow’s position on vibe coding follows from that history. He says there is nothing wrong with code that solves a private problem, even if the author does not fully understand it, nobody else could maintain it and it breaks later. The risk rises when prefab components fail. The opportunity comes when failure gives users a reason to open the generated code and start tinkering.
His larger claim is a funnel argument. Most people who use automated code will solve a task and leave. Some will follow the code downward, from generated output to high-level language to lower-level machinery. Doctorow argues that putting more people at the top increases the chance that some become skilled enough to improve and repair the systems others depend on.
This story draws on original reporting from Pluralistic.
