How do developers use dictation at work?

Dictation fits the text around the code better than the code itself. The evidence we found supports that split, though it is thin. In the evidence we found, prose is where speech recognition does best, and code is where it has the most trouble.

Prose is where dictation fits a developer's day

Programmers reported spending 26 percent of their work week writing in the NC State survey ¹, which is about 10.4 hours in a 40-hour week ². Some of that time is prose: tickets, design notes, pull request descriptions, documentation and team messages. Dictation suits that kind of text. In a 2023 PCWorld test of Windows dictation, the writer found that Windows does a good job transcribing what you say ³. That is one writer's test of one system, not a measured accuracy rate.

Speaking code was slower in the evidence we found

In Begel's 2006 evaluation of a speech-based Java programming system, most expert Java developers had little trouble learning the system, but they found it slower than typing ⁴. That was an early research tool, so the study does not settle the question for current software. It does show that a speed gain on prose does not automatically carry over to code.

Voice-coding tools exist, but they change how you edit

Cursorless describes itself as a spoken language for structural code editing that lets developers code by voice ⁵. A spoken command language takes practice, so judge it after a fixed trial on a small task, not on the first hour. Time the same task by voice and by keyboard, and compare the results.

Moving around by voice is the weak point

In the 2023 PCWorld test, the writer found that navigating within an application, using just the voice, sometimes felt nearly impossible ⁶. The same test found that Windows gets confused when a word can be read either as text or as an action or punctuation ⁷. Code is full of words like that, such as delete, return and list, so you may need more corrections when you dictate near code.

Measure the prose share before you count the savings

The 10.4 hours is total writing time, not only prose. Before you count savings, log how much of it is prose, such as tickets, reviews and documentation, and how much is text typed around code. Only the prose hours are a clear candidate for dictation. The question on office writing hours explains how to set up that log.

Read dictated text back before it reaches reviewers

Dictated text needs a read-back before it is posted. In a 2018 study of short phone messages, speech left 1.30 percent uncorrected errors in the final text, against 0.79 percent for the keyboard ⁸. That study measured short messages, not pull requests, so the rate for your text will differ. The lesson still applies: a dictated identifier or symbol that is wrong is harder to spot than a wrong word in a sentence, so check those before you post.

A practical split for developers

1. Dictate prose into a plain text box: tickets, pull request descriptions, documentation and review comments. If you work in Claude Code, see dictation in Claude Code.
2. Keep typing code. Use the keyboard for code, identifiers and short commands.
3. Trial any voice-coding tool on a fixed task, and time it against typing before it goes near real work.
4. Measure the result with the method in our guide on how much time dictation saves at work. Start from your own writing hours, not from the survey average alone.

Related questions

• How many hours a week do office workers spend writing?
• Can you use dictation in an open-plan office?
• How do sales and support teams use dictation?