Simon Willison used ChatGPT's Codex voice conversation mode to build a new Newsletters page for his blog almost entirely by voice while cooking dinner. The feature adds a Django model, migration, views, templates, and import functions to index his free Substack and sponsors-only newsletters. The post highlights a practical workflow for voice-driven AI coding against a local development environment.
SynthePulse Insight · AI deep reading
Version 1 · 1 source
Simon Willison used the voice conversation mode of Codex in the ChatGPT desktop app to build a Newsletters page for his personal blog almost entirely by talking over roughly half an hour while cooking. But what is really worth looking at is not the gimmick of "writing code by voice," but where it stopped and why it stopped.
The number most likely to be remembered from this story is "half an hour": Willison says the voice conversation lasted about half an hour, exactly the time it takes him to cook a dinner. But in the same account there is another half hour—from the end of the voice phase to being satisfied and merging the PR and deploying to production, another half hour of typed prompts was spent. The two half hours placed side by side are the true shape of this experiment.
In other words, voice pushed the project from zero to "almost ready to ship," but not to "ready to ship." This dividing line was not drawn by model capability alone, but by the nature of the tasks: which work can be completed by describing it, and which must be completed by pointing at it.
According to Willison's own account, the output of the voice phase was quite specific: a new Django model and migration for representing imported newsletters, plus Admin configuration; four working import scripts; two public archive pages, /newsletters/ and /newsletters/2026/; newsletters appearing on the day and month archive pages but not on the tag pages or the homepage; weekly Substack emails linking back to Substack while archived monthly emails have their own pages; and integration with site search.
The four imports came respectively from: the RSS of the latest Substack entries, the undocumented API for the remaining Substack entries, the published monthly emails in the simonw/monthly-newsletter-archive GitHub repository, and the most recent sponsor-only email in a private repository.
These are the author's own list of outputs, a source_claim; the source provides no independent deployment verification or runtime results to corroborate them.
Willison believes his voice transcription, with plenty of filler words and pauses, was already clear enough, and the model understood from it what he wanted to build. During the roughly half-hour voice session, the model would reply, occasionally ask clarifying questions, and then go ahead and modify the code.
One noteworthy detail is Substack's undocumented API: Willison says GPT-6 Astra either already knew it or found it through search. He himself is not sure which. This shows that the "knowledge" the model displayed in this task has a source that is opaque to the user.
The model used for this development was GPT-6 Astra High; this is the model name given by the author, with no independent corroboration in the source.
After the voice phase ended, Willison had Codex create a branch and open a pull request. While reviewing in the GitHub PR interface, he found that one import script used a subprocess call to Git, so he switched to an API-based import and added commits to the PR to fix the import mechanism and the public page display.
There is a hard constraint here: some data is in a private GitHub repository, and the import required creating a new API key, so he had to sit down at the keyboard to do it. This is not a matter of the model not being smart enough, but of the physical location of permissions and credentials.
The more general limitation is that detail adjustments, pasting examples and error messages, highlighting code, and similar operations still depend on the keyboard rather than voice. Willison states clearly that pasting examples and error messages, or directly highlighting the code to change, is still more efficient than describing them in words.
Willison compared this experience with his earlier experience using ChatGPT voice mode on his phone. He believes the difference is the addition of a visual preview and the ability to type or paste with the keyboard when needed, making it a more powerful way of interacting with a coding agent.
This judgment deserves to be singled out: if voice is treated only as an input method, it is not more efficient than typing; but when voice is combined with a local preview and a keyboard fallback, it becomes a usable workflow. Voice drives progress, the preview calibrates it, and the keyboard closes it out.
He first entered "Start dev server and open in browser" in the local simonwillisonblog checkout directory to start the preview, then clicked the "Start new voice chat" button to begin the voice session. The preview existed before the voice, and that order itself is meaningful.
Willison says the biggest highlight for him is being able to multitask in parallel: previously, while cooking he could only listen to podcasts or scroll TikTok, but now he can write code along the way.
He also gives the boundary of the use case: he mainly works from home, because he is unwilling to talk to his computer like this in a shared office space. This is both a real constraint and a hint that this kind of interaction has physical environment requirements.
As for whether voice development is more efficient than pure typing, the source gives only the author's subjective impression, with no comparative data. The source also provides no evidence on whether this kind of voice-driven development can be extended to more complex projects.
All facts in this article come from a first-person account published by Simon Willison himself on October 9, 2026; it is a first-party narrative but not independently verified. Among these, "almost entirely by voice," "about half an hour," "an additional half hour of typing," "GPT-6 Astra High," and "whether the Substack undocumented API was known or found through search" are all the author's own statements, and this article treats them as source_claim. The launch of the Newsletters page, the use of Codex voice conversation mode, and the PR review and additional commits are treated as confirmed. Whether the feature was actually deployed to production and whether it ran normally after launch are not independently verified in the source.
The value of this experiment is not in proving that "voice can write code," but in marking out a reproducible division of labor: voice is suited to pushing a vague intention to the point where the feature is basically formed, while the keyboard still handles credentials, pasting, pointing, and closing out. Treating the two as substitutes misreads it; treating them as a relay comes closer to the author's real experience.
Primary report
Primary source