Have your agent record video demos of its work with shot-scraper video
Simon Willison (Simon Willison's Newsletter) ยท email ยท 2026-06-30 source โ Reader ๐ฅ๏ธ
practical ยท Weekly weblog roundup newsletter (announcement + build-log), practical/how-to register โ This is a Simon Willison newsletter roundup: two feature write-ups (shot-scraper video; sqlite-utils 4.0rc2 written by Claude Fable) plus ~10 links, 6 quotations, 4 notes, 3 releases, 1 research report and 1 tool. The opening sponsor blurb (Sonar / Gartner) is advertising and is ignored. The extraction is centered on the primary substantive piece โ the shot-scraper video feature for having a coding agent record video demos of its own work โ with a few strong secondary ideas captured from the sqlite-utils piece and the roundup items (cross-family review, review-docs-first, understand-to-participate, cheaper-model delegation).
Structure
| Part | Role |
|---|---|
| Feature announcement + worked demo | Introduces `shot-scraper video` (shot-scraper 1.10): a `storyboard.yml` routine recorded via Playwright, shown with a full Datasette bulk-insert demo storyboard. |
| 'The agent drove it' reveal | Shows the entire storyboard was written by GPT-5.5 xhigh in Codex Desktop from a 3-line prompt, and names the '--help as embedded SKILL.md' pattern. |
| 'How I built this' | Build log: agent wrote the feature code and its documentation; Pydantic used to define/validate the format; reviewing the docs was how Willison steered the design; activation-cost reflection (issue open since Feb 2024). |
| Secondary piece โ sqlite-utils 4.0rc2 (Claude Fable) | A release-hardening story: Fable found 5 release blockers (incl. a delete_where data-loss bug) via code review, a GPT-5.5 cross-family review found 2 more, cost tracked at $149.25, release notes outsourced. |
| Roundup fragments (links, quotes, notes, releases) | Jon Udell's 'agent in the loop' reframing, Geoffrey Litt's 'understand to participate', a prompt-injection challenge, cheaper-model subagent delegation, 'Better Models: Worse Tools', DSPy prompt evals. |
Key terms
- shot-scraper video / storyboard.yml
A new shot-scraper command that takes a YAML 'storyboard' (server to launch, URL, viewport, scenes of click/fill/wait steps) and uses Playwright's screencast to record a controlled video of a web app being exercised. - agentic self-documentation (agent-recorded demos) Agent Self-Documentation
The practice of having a coding agent produce reviewable artifacts of its own work โ here a video demo โ so a human can see what it built. - '--help as embedded SKILL.md'
The pattern where a command's `--help` output carries enough usage detail that a coding agent can drive the tool from it alone โ functioning 'like bundling a SKILL.md file directly inside the tool.' - cross-family review Multi-Agent Orchestration
Habitually having one lab's best model review another's output (Anthropic's model reviews OpenAI's work and vice versa) because differing blind spots surface real issues. - review-the-documentation-first
Reviewing an agent's documentation edits before its code as the fastest way to build a mental model of what a large agent-produced change actually did.
Propositions
- explicitCoding agents should produce demos โ especially video demos โ of the work they do, as a routine part of agentic development.conf: high
- explicitshot-scraper video records a Playwright video of a web application being exercised through a routine declared in a storyboard.yml file (server, URL, viewport, scenes of click/fill/wait steps).conf: high
- explicitA coding agent can drive the entire demo pipeline from a short natural-language prompt โ reviewing the branch, reading the command's --help, spinning up a dev server, authoring the storyboard, and producing the video โ with no human-written configuration.conf: highsupportsWith Android CLI, Google is Making the Android Toolchain Agent-Friendly ยท p6 โ A coding agent driving a real CLI end-to-end from its --help alone is a concrete instance of the argued need for vendors to design first-class, agent-drivable tool surfaces.
- explicitA command's --help output can carry enough detail for a coding agent to use the tool correctly, functioning like a SKILL.md bundled directly inside the tool and removing the need for a separate agent-instruction file.conf: highextendsWith Android CLI, Google is Making the Android Toolchain Agent-Friendly ยท p3 โ Extends 'SKILL.md files encode workflows better than per-prompt docs' to the tool's own --help output serving as the embedded skill, dropping the separate file entirely.
- explicitHaving the agent write the feature's documentation gives the human the most useful frame for reviewing the design, because much of the design iteration comes from spotting redundant, inconsistent or confusing prose in the generated docs.conf: high
- explicitDefining the config format with Pydantic (to both declare and validate it) was chosen partly to make the agent-generated design easier for the human to review.conf: medium
- explicitCoding-agent support lowers the activation cost of building features enough that ones that would otherwise never get done โ here an issue open since February 2024 โ actually get shipped.conf: high
- implicitestablishedWhen an agent writes the code, the human's residual, non-delegable contribution concentrates in judgment at the design and review layer โ reviewing documentation, demos and edge-case behavior โ rather than in typing code.conf: highsupports โAgentic Code Review ยท p12 โ Both hold that when an agent writes the code the human's residual, non-delegable contribution concentrates in judgment at the design/review layer; this doc sharpens it into 'human in the loop becomes human on the loop'.supports โPodcast: Formal Methods for Every Engineer in an AI-Powered Future ยท p17 โ Both locate the non-delegable human contribution in judging edge-case behaviour rather than typing code; formal methods are Moreira's precise language for that residual work.
- explicitestablishedHaving one model family habitually review another's output ('cross-family review') reliably surfaces real issues and is worth doing as standard practice, despite initially seeming superstitious.conf: highsupportsGitHub Copilot CLI combines model families for a second opinion ยท p5 โ Willison's habitual Anthropic-reviews-OpenAI-and-vice-versa practice is direct practitioner corroboration that cross-family diversity beats same-model self-reflection.supportsProject Glasswing: what Mythos showed us ยท p11 โ Corroborates that a reviewer with a different model (and prompt) is more effective than asking the original agent to check its own work.supports โAgentic Code Review ยท p10 โ Willison's 'cross-family review reliably surfaces real issues and is worth doing as standard practice' gets empirical backing here: four differently-built reviewers over 146 PRs flagged 93.4% of locations by exactly one tool and none by all four, so heterogeneity โ not picking a single best tool โ is the point.supports โHow I write software with LLMs ยท p5 โ Both independently describe cross-family/cross-model review as reliably catching real issues that same-model self-review misses, despite initially sounding superstitious.
- explicitReviewing an agent's documentation edits first is an effective way to build an initial mental model of what changed in a large agent-produced change.conf: high
- explicitSome categories of writing โ such as release notes โ are safe to outsource to agents precisely because they should be boring, predictable and accurate, and the agent's output can be better than the human's hand-written version.conf: medium
- explicitYou must understand agent-produced code to a depth that lets you keep participating creatively in the project; a rich set of concepts in your head is what preserves your ability to move the work forward, and drifting from it is cognitive debt.conf: medium
- explicitRouting implementation work to cheaper, lower-power models in subagents while keeping judgment, review and synthesis on the top model is a practical way to cut the real (unsubsidized) cost of agentic work.conf: medium
Arguments
- shot-scraper video can record a controlled Playwright video of a web app from a declarative storyboard.
- GPT-5.5 xhigh authored the entire storyboard and drove the recording from a three-line prompt, using only the command's --help.
- The --help output worked like a SKILL.md bundled inside the tool.
- The feature itself (code, docs, format) was written by the agent, with the human reviewing the design via its documentation.
- A human can adequately catch design problems by reviewing an agent's documentation and watching a demo video โ this reviewing capacity is the load-bearing assumption of the whole loop.
- A scripted demo that runs to completion is taken as evidence the feature works, even though the storyboard exercises a predetermined happy path (and even stubs navigator.clipboard via injected JS) โ so it demonstrates 'the flow runs as scripted', not 'the feature is correct'.
- The command's --help will stay accurate, complete and token-cheap enough to remain a reliable agent instruction as the tool evolves.
- The recorded artifact reflects real application behavior because Playwright drives the actual app, not a mock (mostly true here, with the clipboard exception).
- From 'an agent drove a real feature build and demo from --help alone' to 'agent-drivable tooling is a generally good pattern' โ an existence proof generalized to a design principle.
- Having Anthropic's model review OpenAI's work and vice versa has turned up valuable results often enough to be worth it.
- In the sqlite-utils RC, a GPT-5.5 review found two genuine P1 transaction bugs after Fable's own passes.
- Fable's earlier code review caught five release blockers, including a data-loss delete_where bug, that no demo would surface.
- Different model families have sufficiently different blind spots that one can catch the other's misses.
- The reviewing model is competent enough to surface real issues without generating so many false positives that the review becomes noise.
- From repeated positive anecdotes to a standing recommendation โ inductive generalization from Willison's own practice.
Narratives
- GPT-5.5 xhigh, running in Codex Desktop, is given a three-line prompt: review the branch, run `shot-scraper video --help`, then record a demo of the new bulk-insert/create-table features against a Datasette dev server it spins up itself. It produces the entire multi-scene storyboard.yml and the finished video with no human-written configuration.
โ The load-bearing existence proof for the whole piece: it demonstrates simultaneously that an agent can drive a demo pipeline end-to-end and that a tool's --help alone can serve as its agent instructions ('--help as embedded SKILL.md'). - Getting sqlite-utils to a stable 4.0: Claude Fable's pre-ship review flags 5 release blockers (worst: delete_where never commits and poisons the connection, causing silent data loss); over 37 prompts / 34 commits / 30 files the issues are worked through; a GPT-5.5 cross-family review then finds 2 more P1 transaction bugs; Willison reviews the docs first, then the PR, occasionally prompting from his phone during the July 4th parade.
โ Complements and quietly qualifies the demo thesis: the release-critical bugs were correctness/edge-case failures invisible to any demo and catchable only by code and cross-family review; also illustrates that hard agent tasks free the human's attention for other things. - Willison runs AgentsView inside his own Claude Code session to compute what the sqlite-utils work would have cost unsubsidized: $149.25 total, dominated by a single $141.02 main session, with sub-agent reviews at $1.40-$2.40 each โ and concludes he should have leaned more on cheaper-model subagents.
โ Grounds the abstract 'agents do the work' story in real unit economics and motivates the cheaper-model-delegation proposition.
Questions addressed
- โ
How can a coding agent show a human what it actually built?
Have it record a video demo of the running application via shot-scraper video, driven by a declarative storyboard the agent itself writes. - โ
How can an agent learn to use a brand-new tool without a separately authored skill file?
Design the tool so its --help output carries enough usage detail to serve as an embedded SKILL.md that the agent reads and follows. - โ
Where does the human add value when the agent writes the code?
In design judgment exercised through review โ reviewing the agent's documentation first to understand the change, watching demos, reviewing the PR, and directing cross-family review โ rather than in producing code. - โ
Is having one AI model review another's work actually useful, or just superstition?
It reliably surfaces real issues; cross-family review (one lab's model checking another's) is worth doing habitually.
Gaps
- incompleteThe piece advocates video demos as the way to show an agent's work, but never addresses that a scripted storyboard exercises a predetermined happy path โ it even stubs navigator.clipboard via injected JavaScript โ so it demonstrates 'the flow runs as scripted', not 'the feature is correct'. The adjacent sqlite-utils story is the counter-example the piece doesn't connect: its release-blocking data-loss bug was invisible to any demo and caught only by code review. Demos verify liveness and UX, not correctness.
Read next: Read on evals and property-based testing as complements to demos, and Geoffrey Litt's 'understand to participate' (quoted later in this same newsletter) on why watching output cannot substitute for conceptual understanding of the change. - incompleteThe '--help as embedded SKILL.md' pattern assumes the --help text stays accurate, complete and token-cheap as the tool grows. The piece does not consider --help drift (help falling out of sync with behavior), how a large tool's full --help fits an agent's context budget, or when the embedded-skill approach should give way to a real SKILL.md or progressive disclosure.
Read next: Agent-native design and progressive-disclosure/token-efficiency literature; compare with SKILL.md ecosystem write-ups on versioning and staleness. - incompleteThe whole reliability argument rests on the human catching design flaws by reviewing agent-written documentation, yet the piece does not examine the case where the agent's prose is as confidently wrong as its code โ doc rot, plausible-but-inaccurate documentation that reads clean. Release notes are declared 'safe to outsource because boring, predictable and accurate', but boring text is also the text least likely to be scrutinized.
Read next: Cognitive-debt and comprehension-debt writing; work on documentation as a review surface and on LLM-generated-text 'tells' and silent inaccuracy. - incompleteCross-family review is recommended from repeated anecdote ('it really does work'), with no false-positive rate, no cost/benefit accounting, and no discussion of when it fails to catch things or produces noise that costs more review time than it saves.
Read next: See the GitHub Copilot 'Rubber Duck' analysis of cross-family review as cost-effective only when invoked sparingly at high-signal moments, and eval methodology for measuring reviewer models.
Related documents
- Project Glasswing: what Mythos showed us
- [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero
- 10 Things Developers Want from their Agentic IDEs in 2025
- Agent Skills: Google-Backed AI Coding Agent Workflow
- Agentic AI and Code Reviews
- Agentic Engine Optimization (AEO)
- Presentation: From AI Agent Demo to Production: Automated Testing and Evaluation
- With Android CLI, Google is Making the Android Toolchain Agent-Friendly
- Android Studio Quail 2 Redesigns Agent Mode, Streamlines AI-Assisted Coding
- Harness engineering for coding agent users