llm code

Simon Willison gave Claude Code two instructions: write a spec, then build it using red/green test-driven development in a series of sensible commits. What came back was `llm-coding-agent` — a coding agent with six tools (read, write, edit, list, ripgrep search, and sandboxed command execution), an approval loop that pauses for a human before it acts, resumable sessions logged to SQLite, and a Python API Willison says he never asked for but was delighted to find. He calls it a 'slop-alpha,' installs with `pip install --pre llm-coding-agent`, and treats the whole thing as disposable.

A coding agent, written by a coding agent, on a library that grew into an agent framework while nobody was calling it one.

The disposability is the point. What matters isn't the agent — it's what it reveals about the library underneath it. Willison's `llm` started life as a way to run prompts from the terminal; over the past year it grew a tool-calling loop, then file tools, then human-in-the-loop approval. Those primitives have now accumulated to the point where a competent coding agent is a short wrapper over them — thin enough that the entire build could be handed to a bot for an afternoon. A general-purpose LLM CLI has become a sufficient substrate for the agents people were writing frameworks to build.

This is a data point, not a first: Willison shipped a near-identical `datasette-agent` a month earlier, and 'build a coding agent in N lines' is by now its own genre. Judge it as a demonstration, not a product — the agent has essentially no users and isn't meant to. What lingers is a small beat from his own demo: asked to build a SwiftUI command-line clock, the model pushed back that SwiftUI wasn't right for a CLI and quietly built a plain Swift app instead. A throwaway prototype, overriding its user's spec because the user was wrong.