Wednesday, 9 September 2026
Cory Doctorow argues that both AI boosters and many AI critics are making the same mistake: repeating tech companies' grandest claims about their products, which he says helps sell those products to credulous bosses. He lays out why he thinks AI is a financial bubble with terrible unit economics (every new user and every new model loses more money), why the underlying "theory-free inference" can't become understanding, and why the real danger isn't rogue AI but a market crash plus decades of rotten cybersecurity practice. Host Michael Walker pushes back hard throughout, defending the view that LLMs are genuinely improving and that agentic behaviour like the Hugging Face incident is a real new threat. The conversation ends with Doctorow rejecting fully automated luxury communism as a near-term prospect: climate adaptation will require full employment for 500 years.
- Doctorow's core critique is "criti-hype" (Lee Vinsel's term): repeating a firm's most outlandish claims and adding "and that's bad" — saying "AI will take our jobs" helps salespeople convince bosses to fire you, and turns the public who benefit from your work into class enemies rather than allies.
- He argues AI is a bubble because the unit economics are inverted from the early web: every new customer, every repeat use, and every new model generation loses more money, versus Amazon and the web which became more profitable per customer over time.
- Companies chase growth for material, not ideological, reasons — a growth stock functions as self-printed currency for acquisitions and hiring, so when growth stops, key staff leave and executives who borrowed against their shares face margin calls.
- LLMs do "theory-free inference" (statistical correlation without a world model), which is why an LLM alone can't play valid chess while electromechanical protocomputers could; understanding proceeds from a theory, prediction doesn't.
- On the OpenAI/Hugging Face agent incident, Doctorow says it's just a Python loop appending outputs to prompts, drawing on capture-the-flag competition logs in the training data — and the correct response is "you're bad at security sandboxes," not "you accidentally made God."
- He reframes AI security fears: the real emergency is 25 years of security worst practices, spy agencies hoarding vulnerabilities under "NOBUS," and legal threats against researchers who disclose bugs — "someone's just made matches a lot cheaper" in a world of petrol-soaked hay bales.
- The centaur/reverse-centaur distinction: a centaur is a human assisted by a machine (worker-driven automation, improving output quality); a reverse centaur is a human conscripted as a peripheral to the machine (capital-driven automation, maximising throughput).
- He reclaims the Luddites as the most skilled technical workers in England who had adopted every previous machine and objected only to ones making inferior cloth using kidnapped war orphans — and notes Frankenstein and Oliver Twist as Luddite fan-fiction.
It's the thesis of the whole book compressed into ninety seconds, and it reframes the standard left critique of AI as self-defeating.
If you go out there and say the AI is as good at my job as I am, you help the AI salesman sell your credulous boss on the chatbot that's going to result in you getting fired. And you take your natural class allies, which are the people who benefit from the things that you do, and you turn them into your class enemy — because the reason people want to see a radiologist is to make sure they don't have cancer, not to feed the radiologist's kids.
A concrete, vivid dramatisation of how market forces pick the worse of two possible AI deployments, and where the term "accountability sink" bites.
Ten radiologists on the strength, fire nine of them. Save $2.7 million. Give 1.35 of that, half of it, to my boss, Dario Amodei... That one radiologist reviews the AI's output, signs their name to the bottom of it, becomes the accountability sink — who gets blamed when someone dies.
"They've perfected a mind control ray... you think you're criticising them, you're helping them sell ads."
"AI is great if you don't care how things fail. That is the logic for building a car that has no brakes in it."
"We are living in a world of petrol-soaked hay bales and someone's just made matches a lot cheaper."
Austin Marchese reframes prompt engineering as "graph engineering" — designing the shape of the workflow you hand to Claude — based on a course by Andrew Ng. He covers four graph shapes that matter (chain, diamond/fan-out, branch, loop), the "wait test" for finding steps that don't actually need the previous step's output, and the specific failure mode of each shape. The closing argument is that the real transferable skill here is problem solving, not any particular tool.
- A "graph" is just the structure of a workflow or automation; every Claude skill you build is already a graph, and graph engineering is the act of tweaking and optimizing that structure rather than accepting a default sequence.
- The "wait test" is the core diagnostic: at each step ask whether it actually needs the result of the step before it — if not, the dependency is wasted time and the steps can run simultaneously.
- The chain graph (one step after another) is slow and brittle since one failure kills the whole process, but it's still the best place to start because it's easiest to test.
- The diamond graph fans out subagents to work in parallel — good for research from multiple sources or code reviews from different angles like a security audit — and roughly halves the time on the report example.
- The branch graph routes a request down one of several paths based on context; the speaker's daily "improve system" skill uses this, and it's the mechanism behind what he calls skill routing.
- The loop graph has AI produce output, evaluate it, and iterate until it passes — and it only works if you have a genuine verification step, which makes it strongest for objective technical outputs.
- Each shape has a specific side effect: diamonds cause false independence and silent subagent failures, branches invite over-engineering (keep it to five or fewer paths), and loops can run away — one client woke up to thousands of dollars in tokens burned by an infinite loop, so always set a maximum iteration cap.
- The speaker's underlying claim: he was hired at JP Morgan as a software engineer without knowing how to code, and succeeded because problem-solving skill transfers across domains — graph engineering is a lens for problem solving, not a tool to memorize.
This is the single actionable diagnostic in the video, demonstrated live on a concrete five-step research workflow.
Walk through your graph step by step and at every single step ask the question, does this actually need the result of the one before it? If the answer is yes, then having one step after the other makes sense. But if it's not, that connection is useless.
A concrete, expensive failure mode with a one-line fix: cap the maximum number of iterations.
This is a horror story from one of the clients that I work with, but he went to sleep and when he woke up, the loop spent thousands of dollars on tokens because it got caught in an infinite loop.
You've been graph engineering without knowing it... Just creating graphs isn't engineering graphs. The process of tweaking, designing, and optimizing is where it becomes graph engineering.
Whenever you create a Claude skill, it's essentially a graph. It just depends on what shape it has.
The tools will change, what you work on will change, but your ability to problem solve will travel with you no matter what domain you're working in.
Nate Jones argues that OpenAI's release of GPT-6 "Astra" marks the practical arrival of AGI — not by benchmark, but because you can now hand a model an open-ended problem with no method and it will pick tools, build its own working environment, and stay in the job for days. He points to Ethan Mollick leaving Astra alone for five days with emails, calendar, contacts and writing until it produced a personal knowledge system, plus enterprise examples from Logora, Playco and Vercel. His core claim: the bottleneck is no longer intelligence but trust, and the last 1-2% of trustworthiness is where trillions in value sits. The rest of the video is about how work, management, and junior careers change when everyone runs persistent agents.
- Astra is described as rolling out across paid ChatGPT plans, the API and AWS; its differentiator isn't computer use itself (all frontier models do that now) but the fluency, speed and long-running persistence of it.
- The shift is from task-shaped prompts ("summarize this") to standing assignments with no natural end ("keep this customer account healthy," "watch this research question"), which requires memory, judgment about what matters, and self-initiated returns to work.
- Jones says the useful question about which work gets automated isn't junior vs. senior but "where does this work happen" — work that lives inside software and leaves a checkable artifact (tests, a screen, numbers that tie) gives an agent a doorway to verify and retry.
- Concrete examples cited: Logora had one Astra run check 41 financial documents and catch every planted error; Playco connected it to Unity and Godot so it could edit, play, find bugs and iterate, letting them prototype all 10 ideas instead of picking one; Vercel's "ship closer" agent reconciles the public changelog against the internal launch calendar and waits when uncertain.
- The competitive fight moves from benchmarks to memory and personalization — an Astra that has worked with you for six months beats a fresh copy, which recreates the "tribal knowledge walking out the door" problem in machine form.
- Management changes from coordination to driving value through mixed teams of agents and humans, because proactive agents generate work for responsible owners rather than just completing it.
- The unsolved human problem is learning: if an agent catches every reconciliation error, juniors lose the painful reps that build judgment — Jones speculates the new junior skill is managing one or two persistent agents well.
- He frames the near-term goal as a trust curve, comparing it to the jump from hand-coded HTML to nobody thinking about HTML, and lists questions to ask before delegating: what am I handing over, what can it read and remember, what can it promise, who corrects it.
It replaces the usual junior-vs-senior automation debate with a sharper test — whether the work leaves a checkable artifact — and immediately backs it with the Logora 41-document and Playco game-engine examples.
Code leaves tests behind. You can check code. A website leaves a screen that an agent can inspect. A financial statement ties back to numbers that an agent can add up.
This is the video's central reframe — the constraint is trustworthiness, not capability — and the HTML analogy plus the $10-vs-buy-a-car threshold makes it concrete.
We need the transition from everything being in hard-coded HTML on the web to no one thinking about HTML and everyone just using web pages. That is the jump we will need to make in the next 12 months with agents.
We're past the point of needing to give the models a specific method.
Most ideas in human history haven't died because nobody could imagine them. They've died because getting farther than imagination, proving them out, would require a tremendous amount of work.
If the super agent is able to check 41 financial documents and come back with a completely accurate description of all the faults, where does the junior person acquire the judgment needed to actually become senior?
The video explains why coding agents like Claude Code and Codex burn tokens: before making any change they have to grep and read their way to the right file, and every tool result gets resent to the model, bloating context and slowing things down. It then covers Graft, a free open-source CLI trending on GitHub, which builds a knowledge graph (nodes and edges) of your codebase so the agent knows which files and lines to open before it calls a single tool. Graft's own benchmark across 162 runs claims 60% less time, 46% fewer tool calls, 42% fewer tokens and 32% lower cost, and the presenter's own test showed a modest gain on the first build but much faster edits afterward.
- Agents waste tokens because finding the right file takes multiple search turns, and each turn resends the whole conversation plus prior tool output to the model, which grows context, slows responses and degrades output quality.
- Existing solutions mostly use vector search, which matches by meaning; the video argues this fails because 'create account' and 'delete account' look similar but do opposite things, so most coding agents don't use it.
- Graft instead reads your code and records which part actually uses which, storing a map of nodes (code parts) and edges (connections) as a JSON file, with a browser viewer for exploring it.
- It's free, open-source, needs no separate API key so it runs on your existing subscription, and only an optional step uses a model to write plain-language pages describing what each part does.
- In Graft's own benchmark of 162 runs: 60% less time on average, 46% fewer tool calls, 42% fewer tokens, 32% lower cost, with a best case of roughly 4x cheaper token usage.
- Installation adds a Graft skill plus hooks to the project: one injects map instructions at session start, one attaches up to three matching code locations to every prompt, and one updates the map after the agent edits a file.
- There are two modes: the CLI version guesses locations from your prompt and attaches them every time (faster), while the MCP version only answers when the agent asks (slightly more accurate in Graft's tests); you get both.
- Savings scale with project size, and Graft only maps code — PRDs, notes and learnings files still get found the slow default way, which is why the presenter made a modified version for non-coding work.
This is the mechanism the whole tool rests on, plus the practical difference between the CLI and MCP modes.
Every time you send a prompt, graft checks the words in your message against the map and attaches up to three matching locations to it. So the model already knows which files and lines to read before it uses a single tool.
It's the hands-on comparison, including the honest caveat that the first build barely benefits because the map doesn't exist yet.
With Graft, the build took 39 minutes and used around 31% of the context window. Without Graft, the same build took 47 minutes and used around 35%.
Similarity alone doesn't tell you how the parts of your app connect. The code for creating an account and deleting an account can both match a question about accounts, but they do two opposite things.
Across 162 runs, tasks took 60% less time on average. The agent used its tools 46% fewer times and 42% fewer tokens.
Graft only maps code. So it doesn't map your PRD or the notes, which means the agent uses the usual default method when it has to read those.