Copy English

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 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

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.

Where it lands in Jayverse

• Rabbit: session-key mandates as scoped permission, not a one-time recording. A 7702/7715 mandate should list exactly which contracts and actions it covers, with an expiry, matching the "field of view" problem raised for screen-recording agents rather than a broad grant approved once.
• Auditor: require the two-run diff and the broken-precondition run before a skill or workflow ships. Record the same task twice from different starting states to separate intent from incident, then break one precondition on purpose to check whether failure is visible or silently wrong.
• CI/gitboard: add a "fails loudly" check, not just a happy-path test. Before marking an agent skill or automation done, run it against a missing file, expired session, or empty result and confirm the failure is visible rather than a confident wrong output.

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

보여주는 것은 말하는 것이 아니다 — 시연은 명세가 아니라 예시다

스타트업과 대형 벤더가 몇 주 간격으로 같은 상호작용을 내놨습니다 — 지시를 쓰지 말고, 작업하는 자기 화면을 녹화하라. 그런데 녹화는 중요했던 것과 그냥 일어난 것을 구분하지 못합니다. 그 구분을 되찾는 가장 싼 방법은 같은 작업을 두 번 녹화해서 diff 하는 것입니다.

아직 범위 미정이고, 첫 빌드는 통합이 아니라 실험입니다. 실제로 반복하는 작업 하나를 스킬로 녹화합니다. 하루 뒤, 작업은 그대로 두고 시작 상태만 바꿔서 다시 녹화합니다 — 다른 폴더, 다른 창 배치, 같은 표의 다른 행. 그리고 생성된 두 스킬을 diff 합니다. 같은 작업의 두 녹화에서 달라지는 것은 우연이고, 그대로인 것이 내가 실제로 뜻한 명세입니다. 그 diff 가 남길 값어치가 있는 결과물이고, 녹화 두 번에 코드는 0줄입니다. 그다음 세 번째 실행에서는 전제 하나를 일부러 깨뜨립니다 — 만료된 로그인, 없는 파일, 빈 결과 집합 — 스킬이 눈에 띄게 실패하는지, 아니면 자신 있게 틀린 결과를 내놓는지 보기 위해서. 출처는 1차 문서가 아니라 매체 보도이므로 인용 전에 제품 문서를 확인할 것: Claude Cowork "Record a skill"(2026-07-21 출시, 데스크톱 앱 + 메뉴, Pro/Max/Team)과 HeyClicky(YC 2026 봄, 커서를 따라다니며 화면을 보고 백그라운드 에이전트를 띄우는 맥 어시스턴트).

왜

제품 둘이 몇 주 간격으로 같은 수를 뒀습니다 — 쓰인 지시를 없애고, 그 일을 하는 내 화면 녹화로 대체한다. Anthropic은 2026-07-21 Claude Cowork에 "Record a skill" 을 출시했습니다 — 화면을 녹화하며 말로 설명하면 그 워크스루가 재사용 가능한 스킬이 됩니다. HeyClicky(YC 2026 봄)는 커서 옆에 붙어 내가 보는 것을 같이 보고, 다음에 눌러야 할 UI 요소를 직접 가리키며, 명령하면 백그라운드 에이전트를 띄웁니다. 스타트업과 대형 벤더가 이렇게 빨리 같은 상호작용에 수렴했다면 그 인터페이스는 해자가 아닙니다. 물을 값어치가 있는 것은 어느 쪽이 나은가가 아니라 지시(instruction) 자체가 무엇으로 바뀌었는가 입니다.

바뀐 것은 형식이고, 그 형식은 구체적인 방식으로 더 나쁩니다. "어제 주문을 뽑아서 취소 행을 빼고 합계를 재무팀에 메일로 보내라"고 쓰는 것은 이미 분리 행위입니다 — 무엇이 중요한지 정하고 나머지를 뺀 것이죠. 녹화는 그 분리를 전혀 하지 않습니다. 그때 마침 열려 있던 폴더, 창 위치, 클릭 순서, 스쳐 지나간 행, 쓰던 탭 뒤에 있던 다른 탭 — 전부 같은 무게로 결과물에 들어가고, 어느 부분이 하중을 받는지는 아래쪽 무언가가 추측해야 합니다. 녹화는 과잉명세이면서 동시에 미결정입니다 — 작업에 필요한 것보다 훨씬 많은 디테일, 그중 무엇이 요점인지에 대해서는 훨씬 적은 신호.

나레이션 요구가 결정적 단서입니다. Anthropic 버전은 녹화하면서 생각을 말로 설명하라고 요구하는데, 이건 시연만으로는 의도가 실리지 않는다는 자백입니다. 그러니 진짜 혁신은 말하는 대신 보여주기가 아니라 — 보여주면서 말하기, 의도와 동작이 서로에 타임스탬프로 묶인 것입니다. 이건 양쪽 절반보다 진짜로 나은 결과물이고, 정확히 이름 붙일 값어치가 있습니다: 프로그램이라기보다 해설이 달린 테스트 케이스에 가깝습니다. 테스트 케이스는 한 경로가 동작한다는 증거이지, 그 프로그램이 무엇을 위한 것인지에 대한 진술이 아닙니다.

그리고 시연은 겪지 않은 날을 녹화하지 못합니다. 밟지 않은 분기 전부 — 실패한 내보내기, 없는 행, 만료된 로그인, 빈 결과 — 는 녹화에 없고, 에이전트는 그것들을 전부 만나게 됩니다. 즉 녹화는 작성 비용을 낮추고 운영 비용은 있던 자리에 그대로 둡니다. agents-computer-use 는 모델이 충분히 좋아진 뒤 구매자가 실제로 사는 것은 검증·에스컬레이션·오류 처리라고 주장합니다. 녹화는 첫 10분을 쉽게 만들 뿐 그 부분에는 아무것도 하지 않습니다. 만들기 쉬워진 것과 신뢰할 수 있어진 것은 다르고, 그 둘을 뭉개는 것이 이 카드가 막으려는 바로 그 실수입니다.

그리고 하나 더 내주는 것이 있는데, 그건 자격증명이 아닙니다. 두 제품 모두 화면에 대한 지속적인 시야를 필요로 합니다 — 거기엔 비밀번호 관리자가 있고, CRM 안 남의 데이터가 있고, 쓰던 창 뒤에 마침 열려 있던 무관한 DM이 있습니다. third-party-blast-radius 는 인가받았느냐가 아니라 인가된 구성요소가 무엇을 할 수 있느냐를 묻는데, 여기서는 그 질문이 가장 날카로운 형태로 적용됩니다: 위험은 자격증명이 아니라 시야(field of view)입니다.

동작 방식

실험: 두 번 녹화하고 diff 한다

방법 전체가 실행 세 번에 들어가고 코드는 필요 없습니다.

고집할 값어치가 있는 것은 2번입니다. 시연을 글쓰기가 아니라 반복으로 명세로 바꾸기 때문입니다. 같은 의도의 예시 둘은 그 의도를 양쪽에서 조여 주지만, 예시 하나는 경로 하나를 지목할 뿐입니다. 통과하는 테스트 하나가, 어느 디테일이 중요한지를 두고 엇갈리는 테스트 둘보다 알려주는 게 적은 것과 같은 이유입니다.

3번은 사람들이 건너뛰는 실행이고, 스킬의 사용 가능 여부를 결정하는 실행입니다. 시끄럽게 실패하는 스킬은 불편이지만, 그럴듯한 틀린 숫자를 조용히 내놓는 스킬은 부채입니다. 그리고 녹화 인터페이스에는 그 둘을 대신 구분해 주는 장치가 없습니다.

형식이 실을 수 있는 것과 없는 것

마지막 줄이 이 아이디어가 단순한 지름길이 아닌 이유입니다. 모든 숙련자에게는 말로 진술하지 못한 채 수행하는 단계가 있고, 그게 바로 쓰인 지시에서 빠지는 단계입니다. 시연은 암묵지를 복원하고 의도를 잃습니다. 글쓰기는 정반대입니다. 녹화하며 나레이션하는 것은 둘 다 가지려는 시도이고, 그게 얼마나 되는지를 재는 게 2번 실행입니다.

왜 두 벤더가 동시에 도착했나

HeyClicky는 출시 주에 약 300만 조회를 얻었고, Anthropic은 몇 주 앞서 기존 제품 안에 같은 상호작용을 넣었습니다. 동시 발명은 어느 팀에 대한 진술이 아니라 제약에 대한 진술입니다. 모델이 화면 녹화를 해석할 수 있게 됐고, 그 순간 병목이 비프로그래머가 작업을 어떻게 진술하는가로 옮겨갔습니다. 두 제품 모두 그 병목을 똑같이 뻔한 방식으로 풀었습니다.

그러면 차별화는 녹화일 수 없습니다. 차별화는 시연이 틀린 것으로 드러난 다음에 벌어지는 일 — 검증, 에스컬레이션 경로, 그리고 "이번 실행은 녹화와 다르게 생겼다"고 말하고 멈출 수 있는 능력입니다. 이건 agents-computer-use 가 실행 쪽에서 도달한 결론과 같고, 여기서는 작성 쪽에서 도달했습니다. 독립된 두 경로가 일치한다는 것이 이 결론을 믿을 이유입니다.

내주고 있는 권한

두 제품 모두 범위가 정해진 자격증명이 아니라 화면에 대한 지속적 시야를 요구하고, 화면에는 범위가 없습니다. 프로토타이핑할 값어치가 있는 통제는 third-party-blast-radius 가 도달한 것과 같습니다 — 인가받았는가가 아니라 어디까지 닿는가. 실무로는 작업에 필요한 것만 들어 있는 전용 프로파일·워크스페이스에서 녹화하는 것, 그리고 "어시스턴트가 이 창을 볼 수 있다"를 한 번 켜는 설정이 아니라 범위를 정해야 할 권한으로 다루는 것입니다.

Jayverse에서의 위치

• Rabbit: 세션 키 위임(mandate)은 한 번 녹화한 승인이 아니라 범위가 정해진 권한으로 만든다. 7702/7715 위임은 어떤 컨트랙트와 액션을 포함하는지, 만료 시점을 명시해야 한다. 이는 화면 녹화 에이전트의 "시야 범위" 문제와 같은 맥락이다.
• Auditor: 스킬이나 워크플로를 출시하기 전에 두 번 녹화 diff와 전제조건 깨기 실행을 요구한다. 같은 작업을 다른 시작 상태에서 두 번 녹화해 의도와 우연을 분리하고, 전제조건 하나를 일부러 깨서 실패가 눈에 보이는지 조용히 틀린 결과를 내는지 확인한다.
• CI/gitboard: 정상 경로 테스트뿐 아니라 "크게 실패하는지" 체크를 추가한다. 에이전트 스킬이나 자동화를 완료 처리하기 전에 누락된 파일, 만료된 세션, 빈 결과로 돌려보고 실패가 눈에 보이는지, 자신만만한 오답을 내는지 확인한다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑