How Developers Use Verity: From Code Comments to Technical Docs

Why developers dictate

Most of a developer's job is no longer typing code character by character. It's describing what you want to AI agents, writing context for reviewers, explaining architecture to teammates, and documenting decisions. All of that is prose — and dictation is faster than typing prose.

The shift toward AI-assisted development has made this more true, not less. If you spend your day talking to Claude Code, Cursor, or Copilot — describing bugs, requesting refactors, explaining requirements — that's natural language input at high volume. Dictating those instructions is a genuine speed multiplier (see our speed guide for the technique), especially when the AI polish layer turns your spoken thoughts into clear, well-structured prompts.

There's also an ergonomics argument. Repetitive strain injuries are common in software engineering, and voice dictation offloads the mechanical burden from wrists and hands for the prose-heavy parts of the job.

How Verity handles technical vocabulary

Verity's Minimal and Formal personas already preserve technical identifiers well — a reference to useState or tokio::spawn stays as spoken, not transformed into "use state" or "Tokyo spawn." The custom vocabulary feature lets you pre-register terms specific to your codebase — proprietary function names, project-specific abbreviations, team-specific naming conventions. These are added in Settings → Vocabulary.

The Minimal persona works well for technical dictation: it applies light cleanup without rewriting your phrasing, which keeps technical accuracy intact.

Dictating to AI coding agents

This is the highest-value workflow. Tools like Claude Code, Cursor, Copilot, and Windsurf are increasingly how code gets written — you describe what you want in natural language, the agent writes it. The input is prose: "refactor the auth middleware to use JWT rotation," "add error handling for the WebSocket reconnection path," "explain why this test is flaky." Dictating those instructions is dramatically faster than typing them. The AI polish layer cleans up your spoken thoughts into clear, well-structured prompts, which directly improves the quality of the agent's output.

There's a compounding effect here. The better your prompt, the fewer correction rounds you need with the agent. A dictated instruction that runs through polish comes out more precise than what most people type under time pressure — complete sentences, no shorthand, technical terms preserved. That specificity saves the agent from guessing, which saves you from reviewing code that missed the point.

Some concrete examples of what this looks like in practice:

• Bug reports to agents: "The login flow breaks when the OAuth provider returns a 302 with no location header. The error surfaces in auth/callback/route.ts at the redirect parsing step. Add a guard that falls back to the login page with an error parameter instead of throwing." Spoken in ten seconds, polished into a precise instruction that an agent can act on without follow-up questions.
• Architecture changes: "Move the rate limiter from the API gateway into the service layer so each endpoint can set its own threshold. The current implementation uses a single sliding window for all routes, which means a burst of webhook callbacks can starve interactive requests." This level of context — the why, not just the what — is natural to speak and tedious to type.
• Code review narration: "This diff changes the retry logic from exponential backoff to a fixed interval. That's fine for the health check path, but the payment webhook handler needs backoff to avoid hammering Stripe during an outage. Split the retry strategy by caller." You can dictate review feedback as you read the diff, then paste the polished version as a review comment.

The "thinking out loud" workflow

There's a development pattern that dictation enables which typing does not: thinking out loud as a design step. Before touching code, you speak through the approach — what components are involved, what the data flow looks like, where the tricky parts are. The polished output becomes a design sketch that you can hand directly to an AI agent or paste into a planning document.

This works because speaking and thinking operate at the same speed. When you type a plan, the mechanical slowness of typing filters your thoughts — you skip details, abbreviate, lose the thread. When you speak it, the full reasoning comes through: edge cases you'd normally forget to mention, constraints you'd normally leave implicit, alternatives you'd normally discard without recording.

The result is better agent output on the first try, because the agent received a complete picture instead of a compressed sketch. It also creates a natural artifact — the polished transcript — that serves as documentation of the design decision. Two outputs from one action.

A practical example: you're about to refactor the notification system. Instead of writing a design doc from scratch, you open Verity, hit the hotkey, and talk for ninety seconds: "Right now notifications go through a single channel — email. We need to add push and in-app. The challenge is that each channel has different retry semantics and different rate limits. I think we should extract a NotificationDispatcher interface with per-channel implementations, route through a priority queue, and let each channel own its own retry policy. The migration path is: add the interface, move email behind it, then add push and in-app as new implementations without touching the existing callers." That comes out of the polish layer as a clean, readable paragraph — ready to paste into a GitHub issue, hand to an agent, or drop into an ADR.

Switching between coding and communicating

A typical development session alternates between writing code and writing about code. You implement a feature, then write the commit message. You fix a bug, then update the issue tracker. You review a PR, then leave comments. The code parts need a keyboard. The communication parts need prose — and that's where dictation takes over.

The system-wide hotkey makes this transition seamless. You don't switch applications, open a separate dictation window, or break your flow. Press the hotkey in your terminal to dictate a commit message. Press it in your browser to dictate a PR review comment. Press it in Slack to dictate a status update. The polished text appears wherever your cursor is, in whatever application you were already using.

This is particularly valuable during long debugging sessions, where you need to document what you tried, what you observed, and what you concluded. Typing those notes while simultaneously reasoning about the problem is a context-switching tax. Dictating them is not — you're just narrating what you're already thinking.

Other workflows that work well

• Code comments: inline documentation that explains why, not what. These are typically 1–3 sentences and don't require the same precision as code itself.
• PR descriptions: context for reviewers — what changed, why, what to look for. These are often the most tedious part of the PR process and are naturally prose-first.
• Commit messages: subject lines and extended descriptions for git commit. Dictating the message is often faster than typing it, especially for conventional commit format.
• Technical documentation: README sections, wiki pages, architecture decision records (ADRs), runbooks. High prose volume, moderate precision requirements.
• Technical emails and Slack messages: longer context-setting messages to teammates or stakeholders that benefit from being composed verbally.

Linux, macOS, and Windows

Verity runs on Linux, macOS, and Windows — all three platforms as first-class targets, not afterthoughts. This matters more for developer workflows than for most use cases, because a significant portion of developers work on Linux, either as a primary OS or as their development environment.

Most dictation tools don't support Linux at all. The platform's built-in dictation is limited to its own ecosystem, and most alternatives are single-platform. Linux has historically been ignored entirely.

System-wide text injection works on all three platforms — dictation goes directly into any text field, regardless of which application is focused. You don't need a browser extension, a special text editor plugin, or a dedicated input area.

Privacy for proprietary code

If you're dictating code comments or technical documentation, you're likely dictating proprietary information: internal API names, architectural decisions, business logic details. The zero-retention architecture matters here in a specific way.

Audio is processed on Verity's own infrastructure — no third-party AI providers are involved. No audio from your dictation session is stored, logged, or used for model training. Your proprietary code details don't persist in any system after the transcription request completes.

See our privacy architecture post for the full technical breakdown, or the privacy features page for a summary of the processor list and DPA terms. The per-user AES-256-GCM encrypted transcript storage means that even the text of your transcripts is inaccessible to Verity without your key.