Speak your documentation while your cursor sits in the comment

Writing code comments is often slower than writing the code itself. The logic is clear in your head, but describing it in words takes focus away from the next feature. Dictation moves that overhead to the background: hold a key, talk through what the function does, and the comment is done before you have forgotten what you meant to say.

Code comments benefit from natural language in a way code does not. Your variable names are shorthand, your logic is symbolic, but your explanation is a sentence. That sentence is easier to speak than to type.

Why dictate comments instead of typing them

The usual reason to skip comments is time. Your hands are on the keyboard writing the next function, and stopping to reach for typing an explanation feels like a detour. Dictation removes that context switch. You do not leave the code editor; you hold a key, speak, and your comment is written. The cost is only the time to speak, which is often faster than typing.

Comments are also the place where your natural voice matters most. Code is for machines: precise variable names, exact syntax, no ambiguity. Comments are for the person who reads the code six months later, maybe you, maybe a teammate. They work better when they sound like someone is explaining the code to them, not when they sound like they were extracted from sparse typing. Dictation captures explanation naturally.

A third reason is accuracy. When you speak, the name of a variable or a concept you just used is fresh. You do not have to look back and check the spelling of useEffect or maxRetries. You say the name as you know it, and your dictionary handles the rest. Typing comments in a code editor is slower because you are split between the problem you just solved and the comment you are writing. Dictation keeps you in the problem.

Setting up dictation in your editor

Any code editor on macOS that has a text field will work. This includes VS Code, Xcode, Sublime Text, Nova, BBEdit, Neovim with a GUI, and any other. There is nothing to install or configure in the editor itself. Open the app settings, choose your hotkey (⌥ Space by default), and you are ready. How to set up a dictation hotkey explains the options and how to remap it if the default conflicts with your tools.

Most developers remap the hotkey to something that does not conflict with their editor. Some use ⌘ Shift D, others use F12, still others use a key combination that does not appear in any of their tools. Find what works for your workflow and set it once. After that, the hotkey is always available, whether you are in VS Code, the terminal, Xcode, or a web-based IDE.

The key can be different in different contexts if you need it to be. The app has profiles that let you set one hotkey for coding and another for writing, but most developers just use one key everywhere and it works fine.

Dictating into comment syntax

Different languages have different comment syntax. JavaScript and TypeScript use // or /* */, Python uses #, SQL uses --, and so on. You do not have to type the comment markers — your cursor is already inside the comment block where you clicked — but the app transcribes everything you say, including the markers if you say them.

If you want to dictate a multi-line comment and include the markers, you can say them: "slash star" for /*, "star slash" for */, "hash" for #. Most of the time you will just place your cursor after the comment symbol and start speaking. The content of the comment is what matters; the syntax is already there.

For JSDoc and similar structured comment formats, you have options. Some developers dictate the entire block in one go: "at param string url, at returns promise." Others type the structure and dictate only the descriptions. Both work. The transcription is exact, so if you need specific formatting you can either speak it or type it; most developers mix the two.

Handling code-specific language

The biggest challenge in dictating code comments is the language itself. Your vocabulary in a comment includes variable names, function names, acronyms, and technical terms that are specific to your codebase. This is where your dictionary is invaluable.

Open the app settings and add entries for the names and terms you use often:

• Variable names: userCallback, setMaxRetries, asyncTask
• Acronyms: HTTP, REST, CORS, CSRF
• Compound terms: microservice, WebSocket, OAuth
• Product names: your company name, product names, brand terms

The app applies these entries both during recognition (as a hint) and after transcription (as a rewrite rule). If you say "you are ale" in a comment and want it to become "URL", add you are ale → URL to your dictionary. If you just say "use effect" and want it to be useEffect, add that too. The entries are exact matches on word boundaries, so they will not interfere with related words.

Building the dictionary takes a few minutes the first time. After that, it saves you corrections on every dictation where those terms appear. For a developer dictating regularly, this is often the biggest gain from using the app. The full method, including what belongs in the dictionary and what does not, is in teaching a dictation app your jargon.

Common code comment patterns

Several patterns are especially common in code comments, and they dictate well.

Explaining a quirk: "This uses setTimeout instead of setImmediate because of a bug in older Safari versions." Natural speech handles this without trouble. The transcription will be accurate, and if you add setImmediate to your dictionary, the technical term is right.

Describing a parameter: "At param userID, a string representing the database ID of the user whose preferences we are loading." Again, natural speech works well. If your dictionary has entries for userID and database, they resolve correctly.

Outlining steps: "First we check if the token is expired, then we refresh it, then we retry the request." Multi-step logic dictates clearly because you are just explaining the order. Speak slowly enough that each step is distinct, and the transcription will separate them correctly.

Referencing other functions: "Calls loadUserProfile after authentication succeeds to populate the global user state." As long as loadUserProfile is in your dictionary, this dictates perfectly.

The pattern that works best is the one closest to how you would explain the code to a teammate. Skip the fancy phrasing; just say what it does.

Integrating dictation into your coding flow

Dictation works best when it is part of your rhythm, not an afterthought. Here is one approach:

1. Write the function or feature.
2. Before moving to the next one, place your cursor in the comment block.
3. Hold the hotkey and describe what you just built.
4. Let go, review the comment, and move on.

This takes only the time to speak, which is often just a few seconds for a simple function and ten or twenty for a complex one. Compare this to typing a comment: for a three-line explanation, typing might take a minute if you are stopping to choose words. Speaking takes thirty seconds.

The workflow is the same as dictating into any app on your Mac: click where you want the text, hold the key, and speak. Your words land in the code editor just as they would in email or a document. The difference is that you are explaining code, so your technical vocabulary matters more.

Another pattern is to dictate comments while you are thinking through the problem. Some developers dictate a rough outline of what a function should do before writing the code, then use that outline as a guide. The comment is a record of your design process, not an afterthought. This can be especially valuable for complex algorithms or when you are working through a tricky bug. Speaking through the logic helps you clarify it before you type a single line.

Handling mishearings and repairs

If the transcription was wrong, you have a few options:

Undo and re-dictate: Press Cmd-Z to undo the comment and try again. This is fastest for small comments.

Edit manually: Your comment is plain text, so just fix the typo by hand. For a single mishearing, this is often simpler than re-dictating.

Check your dictionary: If a technical term was wrong, add it to your dictionary and the next dictation will be correct. The earlier mistranscription will not be retroactively fixed, but future ones will be right.

Use the history panel: If you dictated a longer comment and want to recover the raw text, open the history panel, find the dictation, and copy the raw transcript. You can paste it in your editor and fix it from there.

Comments are usually short enough that a quick manual fix is the fastest resolution. The goal is not perfection from the first dictation — it is speed. Even with one or two small edits, dictating a comment is often faster than typing it.

When dictation saves the most time

Dictation is most valuable for developers who write a lot of comments. If your codebase requires careful documentation, or if you work in a style where comments explain the why rather than just the what, you will dictate regularly.

It is also valuable for long-form comments: refactoring notes, explanations of tricky logic, or documentation of why you chose one approach over another. These are the comments that take real time to write, and dictation cuts that overhead dramatically.

For small comments — // increment counter — typing might be just as fast. Dictation's advantage grows with comment length and the number of technical terms in them.

Where dictation saves the most time

For developers, dictation is most valuable when your comments explain complex logic. Simple comments like // increment counter take just as long to dictate as to type. Comments that run multiple sentences or explain a design decision are where the advantage appears.

It is also valuable for function docstrings and module-level documentation. If your codebase maintains careful documentation, dictation is a fast way to capture explanations while the logic is fresh in your mind. You finish writing the function, and before moving to the next one, you have already documented what it does.

For pair programming or when you are onboarding a team member, dictating comments as you code also serves as a live explanation. The comment becomes a record of what you were thinking.

Beyond code comments

This same workflow applies to commit messages, pull request descriptions, and code review feedback. Any text field where you are explaining code and want to move quickly is a place where dictation helps. Try it on a low-stakes comment first — a message explaining a refactor, or a note about why you chose a library. Once you feel the rhythm, it becomes natural.

The app saves both the raw and processed transcripts in your history, so if you ever need to recover what you said, it is there. This is especially useful for long explanations or when you want to quote yourself in documentation later. You can dictate into any text field on your Mac, which means you can use the same technique for GitHub comments, Slack explanations of code changes, or email to your team. A commit message written in a git editor in the terminal works the same way, and a developer's whole day of it is what the habit looks like once it is normal.

Accuracy tips

A few small things make dictation more accurate:

• Speak at a natural pace. Rushing leads to slurred words. Slow is fine; the app processes at a comfortable conversational speed.
• Use a good microphone. The built-in Mac mic is decent, but a USB headset or a wireless headset with a mic makes a real difference. Audio quality is the biggest driver of accuracy.
• Minimize background noise. A quiet room or a quiet time of day helps. The app works with some background noise, but a noisy environment will cause more mistakes.
• Add technical terms to your dictionary early. Do not wait until you have dictated the comment and found a mistake. Add terms as you learn your codebase, and the first dictation will be right. Your custom dictionary applies to all dictation, not just comments, so investing in it early saves time everywhere.

These are the same things that make speech recognition accurate everywhere. Nothing special is needed for code; the patterns are the same. If you find you are making a lot of mistakes at the keyboard anyway, dictation often gives you better accuracy because you are less focused on typing and more focused on what you are saying.

Getting started with dictation for developers

The best way to start is with a single comment on a feature you just built. Click in the comment, hold your hotkey, describe the function in one or two sentences, and let go. See how it feels. Most developers find the rhythm clicks after just a few tries.

If your first few dictations feel slow, keep going. The speed comes from building muscle memory around the hotkey and learning when to pause versus when to keep speaking. After ten or twenty comments, it feels automatic. The guide to dictating on a Mac covers the basic technique if you need a refresher, and the case for dictation in a developer's work covers why the prose around the code is worth the habit.

The app works entirely on your machine and does not send your comments anywhere, so your code and your explanations stay private. You can dictate comments on proprietary code, security-sensitive projects, or anything else without concern.