Stop Watching AI Demos. Read Their Transcripts.
A finished repo teaches you nothing about how it got finished. Since December 2025 you can read a power user's entire Claude Code session — every prompt, every wrong turn, every correction. Here are the five sessions and write-ups worth studying, and exactly what to look for in each.
- #claude-code
- #workflows
- #transcripts
- #learning
Over two days in December 2025, Simon Willison used Claude Code to build a JavaScript engine in pure Python — a lexer, a parser, a bytecode compiler, a VM, and a from-scratch regex engine with ReDoS protection. It ended at 443 passing tests and 71 commits, driven by 37 prompts. And the whole thing is published, page by page, as a readable transcript.
That artifact is the point of this guide. Everyone shares finished repos and highlight-reel demos, which teach you nothing, because the interesting information was destroyed on the way to the result. What actually transfers between practitioners is the correction loop: how they notice the agent went off the rails, and what they do about it. A transcript preserves that. A demo edits it out.
So this is a watchlist, but not of videos. It's five things to read, and what to extract from each.
How to study a session (do this before you open any of them)
Reading a 12-page transcript top to bottom is a waste of an afternoon. Read it like a code review instead:
- Read prompt #1 in full, then skip to the last one. How much did the goal change? Small drift means the opening brief was good. In the mquickjs session, prompt one already fixed the hard constraints: port it "entirely in python, with no dependencies".
- Hunt for the recovery prompts. Search the timeline for the moments where the human interrupts. Those are the lessons. Willison's "Let's get the xfails all working — or come up with a very good explanation for why we can't" is a correction disguised as a task: it refuses "it's hard" without demanding a miracle.
- Find the leash. Every long successful session has one mechanism keeping the agent honest. Here it's TDD, stated explicitly — "Do them all, commit as you go with new passing tests, do TDD" — which is why 71 commits exist instead of one enormous unreviewable diff.
- Count the corrections per hour, not the lines per hour. That's the number that tells you whether someone is actually good at this or just has a fast machine.
The watchlist
The mquickjs-python transcript (Simon Willison). 37 prompts, 71 commits, 12 pages, 443 tests passing with 15 documented as xfail in an open-problems.md the agent wrote itself. It's the best available example of a genuinely hard, non-boilerplate task run to completion with an agent. Best for: seeing how tests function as the steering mechanism on a multi-day build — and how honest failure gets recorded instead of hidden.
claude-code-transcripts (the tool). Willison's Python CLI turns your own ~/.claude/projects sessions into paginated HTML: an index.html timeline of prompts and commits plus page-001.html onward. Run uvx claude-code-transcripts for an interactive picker, add --gist to publish straight to a public Gist via gh, or use the all subcommand to build a browsable archive of everything you've ever run. There's also a web subcommand that pulls sessions from Claude Code on the web. 1.6k stars, and it was built with Claude Code — its own commit history links the transcripts of its development. Best for: studying yourself first. Your last session is the most relevant case study you'll ever read.
howborisusesclaudecode.com. A community-curated collection of 127+ tips from Boris Cherny — who created Claude Code and heads the product — pulled from his public threads between January and June 2026. The single most transferable item is his arithmetic on fixing mistakes: correcting inline leaves your context as "file reads + failed attempt + fix", while /rewind (double-tap Esc) makes it "file reads + informed prompt + fix". The failed attempt never enters the record. His other rule is the compounding one: "Every single time Claude makes a mistake, I don't tell it to do it differently. I tell it to write it to the CLAUDE.md." Best for: the correction loop specifically — this is the densest source on what to do in the exact second you notice it's wrong.
Karpathy on the Dwarkesh Patel podcast. Read this one as the counterweight, because it's the most credible public account of an expert choosing not to delegate. Karpathy's default is autocomplete, not agents — "you point to the code where you want it, you type out the first few pieces, and the model will complete it" — and on his 8,000-line nanochat repo, agents actively fought him: he had hand-rolled his own distributed-training synchronization instead of using PyTorch's DDP container, and the models kept trying to drag him back to the standard pattern. He did reach for agents where the model's knowledge beat his own, like rewriting a tokenizer in Rust. Best for: calibration. The skill isn't maximizing agent usage; it's knowing which code is too idiosyncratic to hand over.
Will Larson — "Sharing Claude transcripts." An engineering leader's take on why this matters at team scale: "adoption depends on easy discovery of what's possible and what's good." He built an indexed archive of his org's sessions on top of Willison's tool, plus an internal imp claude share-session command so anyone can submit a session to a shared repo — total build time, "an hour or two of work." Best for: EMs. This is the highest-leverage AI enablement project available to you right now, and it fits in an afternoon.
Why this compounds for a BR dev going international
Interviews for remote US and EU roles have started asking how you work with agents, and "I use Claude Code" is not an answer — it's the same non-signal as "I know Git". A published transcript is an answer. It's verifiable evidence of how you specify a task, how you build a verification loop, and how you behave when the thing goes wrong, which is precisely what a hiring manager can't test in 45 minutes. Two or three public Gists of real sessions do more for you than another certificate, and they cost you nothing but the --gist flag.
Today: run uvx claude-code-transcripts on your most recent real session, open the generated index.html, and find every point where you had to correct the agent. For each one, write down the single line you should have put in your CLAUDE.md or your opening prompt instead. That list — from your own repo, your own mistakes — beats anything on this watchlist. Then publish the one you're least embarrassed by.
Sources
Keep reading
More guides like this one.
The Claude Code Commands You Skip Are All the Same Command
There are over 60 built-in slash commands. Most people use four. Sort the ones you are missing by what they actually do and a pattern appears — almost all of them exist to manage one resource, and it is the one quietly wrecking your long sessions.
What Anthropic's Own Teams Do Differently in Claude Code
Anthropic published how its internal teams actually run Claude Code — and the loudest wins came from lawyers, marketers, and data scientists, not senior engineers. Here are the five habits worth stealing, with the real numbers behind each one.
A Good Handoff Is Mostly a List of Dead Ends
Compaction and `/resume` both preserve what happened. Neither preserves what you decided against — and the abandoned attempts are the most expensive thing in a long session. Here's the handoff file that fixes it, the prompt that writes it, and the one-liner that generates it from a session you already closed.