Why
Two products, weeks apart, converged on the same move: replace the written instruction with a recording of you doing the thing. Anthropic shipped "Record a skill" inside Claude Cowork on 2026-07-21 — record your screen, narrate as you go, and the walkthrough becomes a reusable skill. HeyClicky, a Y Combinator Spring 2026 company, sits beside the cursor, watches what you watch, points at the interface element you need next, and spawns background agents on command. When a startup and a large vendor land on the same interaction model that fast, the interface is not the moat, and the question worth asking is not which one is better but what changed about the instruction itself.
What changed is the format, and the format is worse in a specific way. Writing "pull yesterday's orders, drop the cancelled rows, and email the total to finance" is already an act of separation: you decided what mattered and left everything else out. A recording performs no such separation. The folder you happened to be in, the window position, the order you clicked, the row you scrolled past, the tab that was open behind the one you used — all of it lands in the artifact with equal weight, and something downstream has to guess which parts were load-bearing. A recording is simultaneously over-specified and under-determined: far more detail than the task requires, far less signal about which detail is the point.
The narration requirement is the tell. Anthropic's version asks you to talk through your reasoning while you record, which is an admission that the demonstration alone does not carry intent. So the actual innovation is not show instead of tell — it is tell while showing, with intent and action timestamped against each other. That is a genuinely better artifact than either half, and it is worth naming precisely: it is closer to a test case with commentary than to a program. A test case is evidence that one path works. It is not a statement of what the program is for.
And a demonstration cannot record the day you did not have. Every branch you did not hit — the export that failed, the row that was missing, the login that had expired, the empty result — is absent from the recording, and the agent will meet all of them. Which means recording moves the authoring cost down and leaves the operations cost exactly where it was. agents-computer-use argues that once models cleared the good-enough bar, what buyers actually purchase is verification, escalation and error handling. Recording makes the first ten minutes easier and does nothing for that. Easier to author is not closer to reliable, and conflating the two is the specific mistake this card exists to prevent.
One more thing is being granted, and it is not a credential. Both products need continuous sight of the screen — which is a password manager, someone else's data in a CRM, an unrelated DM that happened to be open behind the window you were using. third-party-blast-radius asks what an authorized component is allowed to do rather than whether it was authorized, and the same question applies here in its sharpest form: the risk is not the credential, it is the field of view.
How it works
The experiment: record it twice, then diff
The whole method fits in three runs and needs no code.
| Run | What changes | What it isolates |
|---|---|---|
| 1 | Nothing — record the task as you normally do it | A baseline skill, incidentals included |
| 2 | Same task, different starting state — another folder, another window layout, another row | The diff between 1 and 2 is the incidental half. What survives both is what you actually meant |
| 3 | Same task, one precondition deliberately broken — expired login, missing file, empty result | Whether failure is visible or arrives as confident wrong output |
Run 2 is the one worth insisting on, because it converts a demonstration into a specification by repetition rather than by writing. Two examples of the same intent bracket that intent from both sides; one example only names a path. This is the same reason a single test that passes tells you less than two tests that disagree about which detail matters.
Run 3 is the one people skip, and it is the one that decides whether the skill is usable. A skill that fails loudly is an inconvenience; a skill that silently produces a plausible wrong number is a liability, and nothing in the recording interface distinguishes the two for you.
What the format can and cannot carry
| A written instruction | A recorded demonstration | |
|---|---|---|
| Separates intent from incident | Yes — the separation is the writing | No. Everything observed is captured at equal weight |
| Covers branches you did not take | Partially — you can state them | No. Only the happy path exists |
| Auditable later | Yes, it is text | Only via whatever the tool generated from it |
| Cost to produce | High — you have to think first | Low, and that is the actual product |
| Carries tacit steps you never notice doing | No — this is its real weakness | Yes, and this is the real gain |
The last row is why the idea is not merely a shortcut. There are steps every expert performs without being able to state them, and those are exactly the steps that go missing from written instructions. Demonstration recovers tacit knowledge and loses intent; writing does the reverse. Narrating while recording is an attempt to have both, and evaluating how well it works is what run 2 measures.
Why two vendors arrived at once
HeyClicky reached roughly three million views in its launch week; Anthropic shipped the same interaction inside an existing product weeks earlier. Simultaneous invention is a statement about the constraint, not about either team. Models became able to interpret a screen recording, and the moment they did, the bottleneck moved to how a non-programmer states a task. Both products solved the stated bottleneck the same obvious way.
Which means the differentiation cannot be the recording. It is whatever happens after the demonstration turns out to be wrong — the verification, the escalation path, the ability to say "this run does not look like the recording" and stop. That is the same conclusion agents-computer-use reaches from the execution end, arrived at here from the authoring end, and the agreement between two independent routes is the reason to trust it.
The permission being granted
Both products require continuous sight of the screen rather than a scoped credential, and screens are not scoped. The control worth prototyping is the same one third-party-blast-radius lands on: not was this authorized but what can it reach — which in practice means recording in a dedicated profile or workspace that contains only what the task needs, and treating "the assistant can see this window" as a privilege to be scoped rather than a setting to be enabled once.