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.

Why saying "AI will take our jobs" helps the salesman 15:47–17:11

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.

The radiologist sales pitch: two versions 1:01:07–1:02:43

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.

The wait test 1:22–2:41

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.

The infinite loop that burned thousands in tokens 11:22–11:45

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.

Why the doorway matters more than seniority 7:52–9:14

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.

The last 2% of trust is worth trillions 14:34–15:57

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.

How the map cuts search turns out of every prompt 7:07–7:57

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.

Real build test: 39 vs 47 minutes, and the edit that took 2 minutes 11:09–11:42

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.

Felienne Hermans, creator of the Hedy programming language, uses her own disillusionment with computer science to argue that the field systematically values difficulty over usefulness. She traces this from dismissals of spreadsheets as "not real programming," to Python and nine other top languages rejecting Arabic-Indic numerals as invalid characters, to a feminist-epistemology reading (via the "Glaciers, Gender and Science" paper) that hard-to-reach problems get studied because they make the researcher a hero. She then connects this to the field's unexamined history (von Neumann and the atom bomb, IBM's punch cards for Nazi Germany) and to the LLM hype, arguing that AI inherited its benchmark-everything methodology from decades of chess research. Her closing point: chess computers exist but are barred from human competition, and we could choose the same for programming, writing and art.

• Hermans built Hedy, a localised, open-source teaching language now supporting 71 languages, after being told for years that her spreadsheet research was "not real programming" despite demonstrating spreadsheet formulas are Turing complete.
• Arabic-Indic numerals, used by roughly 300 million people, fail in the entire TIOBE top 10 — Python calls them an invalid character, Java an "illegal non-ASCII digit," C# just "build failed" — and only SQL accepted them.
• At the SPLASH conference she was asked "why don't they just learn English?", and "why was that hard?" — questions that revealed the community cares about technical difficulty, not who gets included.
• The 2016 paper "Glaciers, Gender and Science" gave her the frame: high mountain glaciers are over-sampled relative to accessible rural ones because climbing the mountain makes you the hero of the story — the same dynamic that makes Haskell and C++ prestigious and spreadsheets, PHP and JavaScript disposable.
• In this frame, making something easier is seen as taking away value, and simple activities have to be dressed up as complex systems to be acceptable — "asking people what they need" becomes requirements engineering, and, she argues uncomfortably to a DDD audience, event storming and ubiquitous language.
• A 2017 paper found the strongest predictor of *not* studying computer science is caring about social change, which she says leaves a field populated almost entirely by people who love complexity — hence "programming is to make programmers happy and proud."
• The field suppresses its own history: von Neumann calculated the detonation height for maximum civilian casualties and still has an IEEE medal named after him; IBM's Thomas J. Watson was decorated by Nazi Germany in 1937 for selling 1.5 billion punch cards a year used to catalogue Jewish ancestry.
• Citing Nathan Ensmenger, chess was the "Drosophila of AI" — an easily formalised true/false problem whose benchmarking methodology was later transplanted onto art and language, where good and bad can't be measured that way.
• Invoking Peter Naur's 1984 theory-building paper, she argues we may have artificial intelligence but not artificial intellectual activity: an LLM cannot hold a consistent model and defend why it implemented something a particular way.
• When she asked the audience to raise hands if their software makes the world better, only a fraction did — so even if LLMs speed up software production, they are only accelerating an unimproved end.

Why glaciers explain everything about programming culture 15:27–16:53

The single analogy the whole talk turns on — how prestige, not usefulness, decides which data gets collected and which programming work gets respected.

You know what you can do after you climb the high mountain? You can climb down the high mountain and then you can go to the pub with your friends... 'I climbed the high mountain, and it was so cold and high, but I did it for science.' And your friends are like, 'Yay, hero.'

Chess computers exist. We just don't let them play. 32:24–33:18

A concrete, disarming counterexample to AI inevitability that reframes the whole LLM debate as a choice rather than a fate.

Still today, if you are playing chess with a friend and they go to the bathroom and you take your phone to look up the next move, this will destroy your friendship... That is an interesting notion, right? That something can exist, but we can still choose not to use it.

Having walked around in this field for 25 years, I think the sad answer is that programming is to make programmers happy, and programming is to make programmers proud.

Maybe we have artificial intelligence, but certainly I would say we don't have artificial intellectual activity.

The ultimate hidden truth of the world is that it is something that we make... we could just as easily make it different.

A hands-on review of the Oh My Pi coding harness, tested against a local llama.cpp server through a logging proxy and compared to Pi and Open Code. The reviewer's main complaint is weight: a single "hello" burns roughly 19,000 of 128,000 context tokens (4.5k system prompt, 11k tool descriptions), the built-in system prompt is long and highly opinionated, and defaults like 32 concurrent sub-agent workers and OS-level notifications are wrong for local hardware. He likes the built-in sub-agent scouts and the UI, and notes most of the bloat can be trimmed via config, but would personally pick Pi (and Open Code above that) because he'd rather build up a minimal tool than strip down a heavy one.

• Oh My Pi is a fork of Pi, not just Pi with extensions bundled — the tool that fits that description is Lazy Pi, which the reviewer plans to cover separately.
• Setup friction: the provider list isn't sorted in any order, choosing llama.cpp pops open an unrequested browser tab, it asks for an API key on a local network, and it hardcodes 127.0.0.1 so pointing at a LAN server requires an environment variable or a custom provider in the config file.
• Through a man-in-the-middle proxy, Oh My Pi alone throws a getpeername stack trace — it appears to kill the connection the instant a response arrives; Pi and Open Code on the same proxy don't do this, and the error is harmless (suppressible by sending stderr to /dev/null).
• By default it fires an OS-level system notification after every prompt; you turn it off with a PI notifications environment variable.
• Out of the box a single "hello" consumes about 19,000 of 128,000 tokens — 4.5k for the system prompt and 11k for tool descriptions across read, bash, edit, ask, eval, glob, grep, task, hub, todo, web search and write.
• The default system prompt cites RFC 2119 and contains debatable engineering rules (e.g. delete an existing test that fails its bar), reminding him of Open Code's old bloated prompt; it can be replaced with system.md or extended with append_system.md.
• Sub-agents ("scouts") run in parallel automatically with no setup and are viewable with Alt+A, but the default max concurrency of 32 workers is data-center sized — on his server a real task spawned four agents, pushed memory from 4GB to 16GB, hit a "context size exceeded" server error, crashed the server once, and was still running after an hour.
• Tools like web search, ask and eval can be disabled via config to shrink what's sent to the model; task and hub can only be denied, not removed. Compaction triggered correctly at the configured threshold, though with an artificially small 32k window it reported that compaction freed too little context to continue.

19,000 tokens just to say hello 12:26–13:15

The concrete token accounting — 4.5k system prompt plus 11k of tool descriptions — is the review's central evidence and the number viewers will want to see for themselves.

I have literally just said hello, a single prompt out to the LLM and a response back, and I'm using 15% of my 128,000 tokens of context. That seems wrong to me.

Pi helps you, Oh My Pi helps your LLM 21:38–22:45

The sharpest framing in the video, backed by the vim-versus-VS-Code and C-versus-Java analogies, and the closest thing to a thesis about when each harness fits.

Oh My Pi feels like it's designed to help your LLM. Pi feels like it's designed to help you. And that's the different philosophies.

Oh My Pi by default will give you an OS level system notification every time it finishes a prompt. That is a ridiculous default.

Max concurrency, the default is 32 concurrently running workers. That seems like a default that is intended to use against enterprise-grade hardware in a data center.

I would rather start with a minimal tool and build it up rather than start with a heavy tool and try to strip down the things that I don't like about it.