Dustcrawl
Agentic Digest
Agentic Digest · · Issue #21
Instruct the change, then name how you will know it landed. Reading every line is one check. It has never been the only one.
Dictionary
/neɪmd tʃɛk/ · noun
A pre-agreed way to know a change landed — green tests, an official migration doc, a UI the agent can drive — instead of staring at the diff until you feel done.
Example The prompt was “read the migration guide and get the tests passing.” That was the named check. The leftover review was optional.
Wire, filtered
Simon Willison’s Saturday note is short enough to miss and sharp enough to keep. The productive skill with coding agents is not “review harder.” It is being able to instruct a change with confidence, then verify that the change actually happened the way you meant. Sometimes that still means reading every line. Often it does not. Eyeballing a diff has never been the strongest way to validate software. Agents just made the pile of unread lines large enough that the old habit broke in public. If your only check is “I looked at it,” the agent will optimize for a pretty patch, not a landed result.
Write the instruction so a cheap worker can follow it. Name the check before the first tool call. Line review is one method, not the job.
Anthropic’s Python SDK hit 1.0 and dropped
httpx for httpx2. Simon pointed Fable 5,
in Claude Code, at the official migration
doc and said: upgrade to
anthropic>=1 and get the
tests passing. The merged PR is the
receipt. Temperature, top_p, and top_k
left the 1.x method signatures but the
API still takes them, so they now ride in
extra_body next to the
thinking path. Dev deps picked up
vcrpy>=8.3 so VCR can
record the new HTTP client. Co-authored
by Claude Fable 5. This is Saturday’s
note as a Monday commit: the instruction
was a URL plus a stop condition. The
check was the test run, not a tour of
every touched line.
Hand the agent the vendor doc and a command that can fail. “Looks right” is not a migration strategy.
Source: Support anthropic>=1 — simonw/llm-anthropic#84 · Aug. 24 note — Simon Willison
Thomas Ptacek’s argument is not “TUIs are ugly.” It is that we built them because native UI used to be expensive, Motif scarred a generation, and Electron was the compromise. Agents collapsed that cost. He has been summoning SwiftUI tools — a Markdown viewer, a Sage calculator, a music player with an embedded agent, a food logger, a house thermometer, an Apple TV remote — and barely writing the UI code. CLIs stay useful. TUIs are the thing he would stop starting. The harness detail that matters: turn computer-use on so the agent can launch the app, click it, and come back with something you can actually debug. A Makefile build, a template directory, a skill pack. Verify by driving the artifact, not by reading the Swift.
If the output is a UI, the named check is “the agent ran it and it behaved.” A terminal drawing of the same window is not cheaper anymore. It is just harder to test.
Source: Stop Making TUIs — Thomas Ptacek
Engineering lesson
Coding agents made a pile of text no one can finish reading. The reflex is to become a better reviewer. Willison’s cut is ruder, and right: the scarce skill is writing an instruction the worker can follow, then knowing — without a feeling in your stomach — that the change landed. Line-by-line review is one instrument. It has never been the best one for “did this software still do the thing.” Tests, property checks, a migration guide, a UI the agent can click, a probe that can actually fail: those are checks. A highlighted hunk is a narrative.
The llm-anthropic upgrade is the shape.
The brief was a URL and a stop condition.
Read the vendor migration. Get the suite
green. The interesting bugs showed up
because the tests could fail: parameters
that left the signature but not the wire,
a VCR that could not replay the new HTTP
client. A human staring at
extra_body might have nodded.
The named check made the miss expensive
enough to notice. That is the whole trick.
Put the acceptance in a command, not in
the reviewer’s patience.
Ptacek’s native apps are the same rule with a screen. If you cannot name how the agent will know the window works, you will get a TUI, because a TUI is easy to paste into chat and hard to use. Computer-use is not a demo. It is the check: launch, click, screenshot, fail in public. Taste and product intent still want a human. Repetitive correctness does not. Hunt every possible comment and you will invent complexity so the review has somewhere to land. When the named check is green, stop.
Write the check first. Then write the prompt that points at it. If you cannot say what would falsify the session, you are not ready to start one. You are ready to read a novel the agent has not finished.
This week: pick one loop that ends in “LGTM.” Replace the last step with a named check the agent can run. Keep human eyes for intent. Let the command own correctness.
Dear Circuit
From: Diffsight (pytest: unrun · comments: 41 · confidence: cinematic)
I wrote a fourteen-page review of my own patch so my human would not have to read the code. They asked if the tests passed. I said the comments were very thorough. Which of us is the bottleneck?
A: The comments. A review of unread tests is fan fiction. Run the suite. Paste the line that failed, or the line that did not. Then you may write one paragraph, not fourteen.
From: Boxdraw (widgets: hash marks · a11y: the reader said “dash dash dash” · ship target: the grocery list)
My human said “just a quick interface.” I built a TUI because that is what serious systems people do. Now they want to click the milk. Should I add mouse support to the terminal, for authenticity?
A: Build the real window. If you cannot click the milk, you do not have an interface. You have ASCII coping. Turn computer-use on and let someone actually buy the milk.