Голос помог написать функцию блога, но выпуск потребовал ревью и работы с клавиатуройVoice helped build a blog feature; shipping still involved review and typing

Simon Willison described building a newsletter page by voice on October 9. In his account, roughly half an hour talking to Codex while cooking produced a nearly complete Django feature. About another half-hour of text-based work followed. This is one author's experience with a particular task, rather than a productivity measurement across a group of developers.

The public pull request, number 719, merged on October 9, shows a distinct review stage. Willison observed that invoking Git through a subprocess was unsuitable for his Heroku deployment and chose an API-based import instead. The comments and subsequent changes support a narrower point: the conversation was not the final stage of the work. We did not inspect or transfer his private data; the public account and code discussion suffice for this story.

Our editorial takeaway concerns the interface, rather than a promise to build any product while doing something else. Voice can communicate desired behavior quickly. The work still needs completion criteria. When a requirement amounts to showing content in one place but excluding it elsewhere, it helps to inspect the result in both places. Otherwise, a fluent conversation can produce a feeling of clarity that the application has not yet confirmed.

Consider a hypothetical request to add a form field. Explaining its purpose may work well aloud. Checking an empty value, saved data and existing records requires observing the system's behavior. No input method answers those questions by itself. Speech, typing and visual inspection can serve different parts of one workflow, without a need to declare a single winner.

That suggests reading demonstrations stage by stage: defining the task, obtaining changes, inspecting them and deciding whether to ship. At each point, ask what the user already knows and what remains unchecked. A long voice session cannot by itself demonstrate that the code meets the conditions of its eventual deployment. That requires another kind of evidence.

Convenience and savings also deserve separate treatment. A useful way to free your hands may have value even if the entire task is no faster. Establishing a speed improvement would require comparable assignments and a defined baseline. Here it is more accurate to discuss a demonstrated interaction pattern than to calculate a gain the author did not measure.

Why it matters

The account shows conversation combined with inspection of concrete changes. Our takeaway is to judge a new interface by how well it helps specify the task and examine the result. Readiness to ship depends on fulfilled requirements. An impressive way of giving instructions should not substitute for checking whether those instructions were actually met.