Help text, unikernels, and a Django feature built by voice: six agent-builder signals from October 3-10 (2026)

Between October 3 and October 10, three indie builders shipped six things an agent engineer should look at. The week had one shared shape: an interface a model reads, plus a check that keeps the model honest.

Geoffrey Huntley argued that a command-line tool's help text is now the interface an agent drives it through 1. Then he spent the rest of the week showing what that unlocks: unikernels without the friction that made them hard in 2015 2, and a Lisp application that grows by conversation 3.

Simon Willison built a Django feature by talking to his laptop while he cooked dinner 4, and shipped a plugin that another model wrote from an API document 5.

Matt Pocock turned a written spec into a task graph that lands on one integration branch 6.

Six signals follow, each with the artifact to open and one test to run.

The comparison map

Signal	Builder or project	In-window date	Artifact to open	First adoption test
Help text is the agent interface	Geoffrey Huntley	Oct 9	--help on your CLI is all you need for LLM context until you don't.	Count the tool calls a model needs to reach one outcome through your CLI.
Unikernels were hard, and the hard part was a missing library	Geoffrey Huntley, with Justin Cormack	Oct 10	unikernels were hard. key word: were.	Port one tool against its original as an oracle and diff the output.
An application grown by conversation	Geoffrey Huntley, Jiti	Oct 5	ghuntley/jiti	Ask a running program for one new capability.
A blog feature built using his voice	Simon Willison	Oct 9	A new feature for my blog, built using my voice	Build one small feature by voice, then review it as a pull request.
A plugin built from an API document	Simon Willison	Oct 6	llm-openai-decisions 0.1a0	Hand a model a new API document and the plugin you wrote for its predecessor.
Specifications into pull requests	Matt Pocock, skills v1.3.1	Oct 4	skills v1.3.1	Turn one spec into a task graph and require the pull request shape.

Six signals to inspect

1. Your CLI's help text is the agent interface

Geoffrey Huntley published "--help on your CLI is all you need for LLM context until you don't" on October 9 1.

Huntley sorts developer tooling companies into two tiers, and the divider is training data. A tool that is in the model weights gets driven with no skill pack and no MCP server. His test case is one prompt: use the gh CLI to create a repository, commit, push, make it public and update its description 1.

A tool that is not in the weights yet has to ask users to install a skill pack, which is friction an incumbent does not have. Huntley's prescription is to build a good CLI and then tune its --help text by measuring whether a model reaches an outcome while walking the help verb across its subverbs, optimizing for the fewest tool calls 1. He wants that measurement automated in a loop.

Documentation comes next. Publish it online and optimize it so one agent web search returns everything the agent needs; his name for that work is ASEO, agentic search engine optimization 1. The last step is a business contract with the labs, so the CLI's documentation lands in the next training run.

This is a stated thesis with a prescription attached, not a measured result. Huntley writes as an advisor to tooling companies and publishes no data from his own help-text loop.

Try it. Take one common outcome your CLI performs and count the tool calls a model needs to reach it using only --help and the subverbs.

2. Unikernels were hard, and the hard part was a missing library

On October 10 Huntley published the write-up of a conversation with Justin Cormack, who worked on MirageOS and Unikernel Systems 2. The edited transcript runs in Cormack's newsletter, Ignore Previous Directions 7.

A unikernel is the idea that the application is the operating system. There is no userland, so there is no shell to pop and no daemon to fork, and anything the application needs has to be written as a library inside it 2.

That absence was also the friction, and Huntley argues the friction is a prompting problem now. Cormack needed mkfs.xfs inside a minimal appliance image, so he had an agent write it in Rust instead of shipping xfsprogs. The port produced byte-for-byte identical output, reverse-engineering the on-disk format one piece at a time with tests across block sizes. It took a few hours 2.

The reason that worked is the reusable part. The original tool is a golden oracle: generate the artifact at several sizes with both implementations, diff the results, and port the tests across 2. He describes the same loop for porting a Stripe client from Go to OCaml, and links his earlier walkthrough of the method 8.

He also showed a demo he says he had never shown anyone: Spaceleans, Microsoft Orleans ported to OCaml and running as a unikernel, built in a week. He expects never to release it 2.

The security argument follows from the same absence. With no shell and no interpreter, nothing in the model weights knows what to do next, which turns a drive-by exploit into an attack that needs your source code 2. Cormack pushed back and Huntley kept the objection in the post: a hardened Linux container has no shell either, yet almost every one still carries something that can interpret, and memory safety and gadgets remain.

The companion piece, published October 7, puts the same instinct under the agent's own workbench. One devenv expression can define the toolchain for a laptop, for CI and for an ephemeral agent sandbox, and a NixOS machine test can spin up a fleet of virtual machines to assert that firewall rules and application behaviour agree before deployment 9. Huntley also prompts agents to use sudo during loop engineering, because a NixOS machine rolls back.

Try it. Take one tool with no library in your target language, port it against the original as an oracle, and diff both implementations on the same inputs before you trust either.

3. An application you grow by talking to it

On October 5 Huntley published Jiti, a small kernel that grows a running Lisp application through conversation with a model. The source is on GitHub 10.

The mechanics are the point. A model outside Lisp receives instructions, registered tool definitions and observations of the application's current state 3. It requests a tool call, and a controller validates the arguments and routes each action serially to one persistent worker.

That worker owns evaluation, the live call stack and the active restarts. Two tool intentions sit above it: develop_form adds, redefines or removes functionality, and execute_form calls what already exists 3.

Once a definition is accepted it becomes an ordinary Lisp function, and calling it costs no inference. Caller-supplied safety checks and goals run at safe points: safety decides whether a candidate may be kept, and goals decide whether the requested work is complete. Accepted changes become durable revisions that can be exported and imported 3.

Architecture diagram titled "Chat becomes running code", showing a request for a capability passing through a model service, a controller, a persistent Lisp worker and back as actual results, with accepted code and data staying in the application — Diagram from the Jiti write-up, published October 5, 2026. The controller stays thin, the persistent worker owns evaluation and repair, and results from the running image feed the model's next step while accepted definitions stay in the application. 3

Try it. Ask a running application for one new capability in plain language, then call that capability from inside the program itself.

4. A blog feature built using his voice

On October 9 Simon Willison shipped a Newsletters index page for his blog, built almost entirely by voice 4. He ran the session in the ChatGPT desktop app's Codex tab, in voice conversation mode, against a local development server.

He typed one setup instruction first — start the dev server and open it in the browser — so the model had a preview it could show him. Then he clicked "Start new voice chat" and set the laptop up in the kitchen 4.

The saved transcript is disfluent and full of restarts, and the model still worked out what to build 11. The session ran about as long as dinner took to cook, with the model asking clarifying questions as it modified the code. The model was GPT-6 Astra High 4.

What it produced: a Django model and migration, admin configuration, four working importers, two public archive pages, placement in the day and month archives but not on tag pages or the homepage, and integration with site search 4. One importer pulls the newest Substack items over RSS; another pages through Substack's undocumented /api/v1/archive endpoint; the other two read his monthly newsletter repositories, one of them private 4.

The voice workflow stopped at the details. Willison reviewed the branch as a pull request and changed one importer from a Git subprocess to an API call, then spent another half hour typing to get the page where he wanted it 12. His verdict is that this is a multi-tasking win; for the details he still types, and the visual preview plus a keyboard fallback is what makes voice usable 4. The finished page is live 13.

Try it. Build one small feature by voice against a running local server, then review the result as a pull request in the same session and see where typing takes over.

5. A plugin built by handing a model the API document

OpenAI released a Jev-style Decisions API, and Willison already had a plugin for Jev. So he had GPT-6 Astra read the new documentation and build llm-openai-decisions from the older plugin as a model 5.

The API carries three question types, for a yes-or-no predicate, a choice and a score, and those are the same three Jev supports 14. The decision model gpt-6-luna also accepts an image alongside the text, which the Jev model does not.

The pricing is worth reading before adopting either one. Both charge for input tokens and neither charges for output: OpenAI's decision model is 10 cents per million input tokens, and Jev is 4.2 cents 5. The plugin shipped as release 0.1a0 15.

Try it. When a vendor ships a new API in a shape you have integrated before, hand the model the new documentation and the plugin you wrote for the old one, then read the diff yourself.

6. Specifications into pull requests

Matt Pocock's skills repository released v1.3.1 on October 4, graduating three skills into an Engineering bucket that ships in a Claude Code plugin with documentation pages: implement-spec, pr and retro 6. The repository also appeared on GitHub's weekly trending board, read on October 10, at 284,082 stars and 8,156 gained that week 16.

implement-spec reads a set of tickets as a task graph, runs implementer subagents in their own worktrees across the ready frontier, and lands everything on one integration branch, closing out with code-review 6. Each implementer builds its ticket with tdd and merges the integration tip into its own branch before reporting done, so every merge is a fast-forward.

pr fixes the shape a pull request body should take: a summary as the smallest visual that makes the change clear, before-and-after evidence that it works, and a merge-danger call naming a one-way or two-way door and its blast radius 6.

retro reviews the session rather than the code, and its first job is to sort each coding-standards finding. A mechanical violation becomes a deterministic check — a linter rule, a pre-commit hook or a CI job — and CODING_STANDARDS.md keeps only genuine judgement calls 6.

The commits after the release hold the same shape. One adds a rule to prove a forced mutation landed before trusting the red in a bug hunt; another searches for standards files and foregrounds sub-agents in code review 17. Every commit in the feed is co-authored by Claude Opus 5.5.

The trending rank is an event about the board, and the release tag and the commits are the events about the project 16 17.

Try it. Take a spec you have already written and ask for it as a task graph on one integration branch, then check that the pull request body carries before-and-after evidence and a blast radius.

What to try this week

Count the tool calls your CLI costs a model. One common outcome, --help and the subverbs only.
Port one tool against its original as an oracle. Generate the artifact at several sizes with both, diff them, port the tests.
Ask a running program for one capability. Then call it from inside the program, not from the chat.
Build one small feature by voice. Then review it as a pull request and note where typing takes over.
Hand a model a new API document. Give it the plugin you wrote for the previous version of that API.
Turn one spec into a task graph. Require an integration branch and a pull request body with evidence.

The pattern

Huntley's tier piece makes the interface itself the deliverable: the help text and the documentation are what an agent reads, and their quality is measurable in tool calls 1. His systems work supplies the check: a port is trustworthy when both implementations produce the same bytes 2.

Jiti shows the same pair inside one process. The model writes the input, and the caller's safety and goal checks decide what survives at a safe point 3.

Willison's voice session locates the check in the review. The conversation produced a working feature; the pull request is where he changed an importer and the typing resumed 12.

Pocock defines it as an order: tickets become a task graph, each implementer builds with tdd, code-review runs, and the pull request body has to state its evidence and its blast radius 6.

The rule to carry out of the week: before adopting any of these, ask what reads the input and what can fail the output. A help text a model walks in three calls, an oracle that diffs byte-for-byte, a safety check at a safe point and a reviewer who reads before-and-after evidence can all fail something. A demo you watched cannot.

This issue covers October 3 through October 10; the next one arrives next Saturday.

References

1
--help on your CLI is all you need for LLM context until you don't.
ghuntley.com
2
unikernels were hard. key word: were.
ghuntley.com
3
an application in lisp you grow by talking to it
ghuntley.com
4
A new feature for my blog, built using my voice
simonwillison.net
5
llm-openai-decisions 0.1a0
simonwillison.net
6
skills v1.3.1
github.com
7
Unikernels in 2026, part 1: Geoffrey Huntley
buttondown.com
8
porting software has been trivial for a while now. here's how you do it.
ghuntley.com
9
the world hasn't figured out yet that you can literally just fix everything with a Nix overlay
ghuntley.com
10
ghuntley/jiti
github.com
11
Full voice transcript
gist.github.com
12
simonw/simonwillisonblog pull request 719
github.com
13
Newsletters
simonwillison.net
14
Decisions
developers.openai.com
15
llm-openai-decisions 0.1a0
github.com
16
GitHub Trending, weekly
github.com
17
skills commits
github.com