From voice typing to a maintainable sample store

Voxi started with a practical desktop problem: speaking a sentence is often easier than typing it, but dictation should feel immediate and should not send private audio to a cloud service by default. Voxi is a standalone Go application for Linux desktops. It captures microphone audio, recognizes speech locally, and types the result into the focused window. On Wayland, it uses dotool for keystrokes; an optional privileged helper observes physical modifier keys through Linux evdev so injected text does not accidentally act like a Ctrl, Alt, or Super shortcut. A systemd user service coordinates recording and other long-lived work, and a GNOME Shell extension offers desktop controls.

The project’s recent work shows how much of a voice product lives around the recognizer. In late September, Voxi replaced a collection of loosely related development recordings and allowlists with one sample store. That store gives each recording a purpose: dictation samples have expected transcripts for accuracy checks; noise samples should produce no words; and voice samples are reserved for voice training or cloning. Each recording has a JSON sidecar for its metadata. Private recordings live under the user’s data directory, while reviewed, non-speech noise fixtures can be kept in the repository for tests.

This was delivered as a connected sequence rather than one large rewrite. Issue 169 recorded the vocabulary and storage decision. Issue 170 introduced the store package and sidecars, then checked the migration against 29 real records. Issue 171 moved the legacy directory and training allowlist into the new layout. Issue 172 added the voxi sample commands for listing, inspecting, playing, recording, adding, editing, moving, and deleting samples. Issues 173–175 added purpose restrictions and consent checks, moved public noise examples into test fixtures, and aligned help, man pages, and website language. Sample merging, tracked in issue 168, lets a developer make a longer clean recording from several shorter samples.

The key design choice was to make purpose visible in the directory layout, not just a metadata tag. A path under voice can be treated differently from a path under noise; the command layer can require own-voice consent when a sample is added or moved into the voice purpose, and publication is limited to noise samples. That makes a sensitive action harder to trigger by accident and makes the rules easier to explain. It also forced a careful migration: preserve recordings and metadata, remove the old parallel allowlist, and verify the result rather than assuming that a successful copy meant the new store was correct. The issue record reports a 29/29 real-data check for the store migration.

Another concrete example came on September 30. Issue 177 addressed a dead or missing microphone at recording start. Voxi now checks and repairs the microphone alongside the recording start path, records a mic_repaired drop reason, and asks the user to record again when repair may have interrupted capture. The change was implemented and marked closed after live verification. The project’s audio-repair guidance says to inspect live PipeWire, WirePlumber, or Bluetooth behavior before designing a fix, because policy managers can undo manual changes. This is a useful distinction for desktop software: a unit test can check a state transition, but it cannot establish how a live audio stack behaves.

Voxi is also a useful example of agent-assisted engineering because the work is broad and persistent. In the six weeks ending October 4, 2026, Git records 572 commits. The tracked repository contains 186 Go source files and 509 Go test functions across 157 test files. The issue tracker has reached ticket 179, and recent work is documented as small tickets with milestones and closure notes. docs/AgenticLoop.md defines advisory, development, review, hygiene, and retrospective phases; docs/ModelRoles.md explains how advisors, implementers, and reviewers divide work. Existing studies record cross-agent reviews and design iterations, including a monitor redesign based on checked-in terminal mockups. Those records show the practical value of agents here: many small changes across CLI behavior, audio, sample data, installation, tests, and user documentation can be handed off with durable context and checked against a shared acceptance record.

This does not mean a solo developer could never build Voxi. The evidence supports a narrower point: agents make it more plausible to sustain this pace across several connected workstreams without relying on chat history as the project memory. Tickets preserve decisions, tests preserve behavior, and studies capture the surprises that future contributors would otherwise rediscover. A human still has to make the product and safety choices—what counts as publishable audio, when to ask for another recording, and whether live verification is convincing.

Facts