Voice for Developer Documentation

The short answer: open your README file, code comment block, or commit message field, press ⌃+⌥+R (Mac) or Ctrl+Alt+R (Windows/Linux), speak your explanation for 30-45 seconds, and AICHE transcribes and inserts the formatted text.

Typing documentation and detailed code comments takes 15-20 minutes per component and interrupts your coding flow with context switches between implementation and explanation.

1. Open the file where you want to add text (README.md, code comment block, or commit message editor).
2. Position your cursor at the insertion point.
3. Press your AICHE hotkey to start recording.
4. Speak your explanation naturally (example: "this function validates email addresses by checking format, verifying the domain exists, and rejecting disposable email services").
5. Press the hotkey again-AICHE transcribes, applies Message Ready formatting, and inserts the text.
6. Edit for technical accuracy if needed, then continue coding.

Heads-up: AICHE transcribes your spoken words literally. If you say "function that validates email," it inserts that sentence - not function code syntax. Use AICHE for writing documentation that explains code to humans, not for dictating code syntax itself.

The pro-tip: when writing function documentation or code comments, speak while looking at the implementation on screen. This produces more accurate descriptions than trying to remember what the code does from memory.

What Voice Is Good For (and What It Isn't)

Voice dictation excels at prose - the English sentences that explain, describe, and document code. It's not designed for dictating code syntax. Saying "const user equals await fetch slash api slash users" is slower and more error-prone than typing it.

The dividing line is simple: if the output is read by humans, voice is faster. If the output is read by a compiler, type it.

Where Voice Wins

README files. Project descriptions, setup instructions, architecture overviews, contributing guidelines - all prose, all faster by voice. A comprehensive README section that takes 15 minutes to type takes 4 minutes to dictate.

Code comments. Inline comments explaining why code exists, what edge cases it handles, and what assumptions it makes. These are the comments developers skip because typing them feels like overhead. Speaking them takes 10 seconds per comment block.

Commit messages. Detailed commit messages that explain the reasoning behind changes. "Fix authentication bug" becomes a 3-sentence explanation of what broke, why, and how the fix works - because speaking three sentences takes 15 seconds.

Pull request descriptions. Context for reviewers: what changed, why, what to test, what risks exist. Voice produces more thorough PR descriptions because the barrier to being detailed is lower.

API documentation. Endpoint descriptions, parameter explanations, example use cases. The prose that makes an API usable rather than just technically correct.

Technical specs and design docs. Architecture decisions, system design rationale, tradeoff analysis - all the writing that shapes a project before code gets written.

Where Voice Doesn't Help

Code syntax. Variable names, function signatures, import statements, and logic expressions are faster to type. The mental overhead of translating code concepts into speech ("open curly brace, const, space, result...") exceeds the time to type them.

Configuration files. JSON, YAML, and TOML are structured data, not prose. Type them directly.

One-line changes. Fixing a typo, changing a value, or adding a single import doesn't benefit from voice. The hotkey press takes longer than the edit.

The Documentation Deficit

Most codebases are under-documented because typing documentation feels like overhead on top of the real work of writing code. Developers know they should document, but when the choice is between writing the next feature and writing docs for the last one, features win.

Voice changes the economics. When a function comment takes 10 seconds to speak instead of 2 minutes to type, documentation happens in the moment rather than being deferred indefinitely. The incremental cost drops so low that it stops feeling like overhead.

Over time, this produces codebases with meaningfully better documentation - not because developers are more disciplined, but because the friction disappeared.

Tips for Developer Dictation

Speak while looking at the code. Your description is more accurate when you're reading the implementation as you speak. Open the file, position your cursor above the function, press the hotkey, and describe what you see.

Use technical terms naturally. Say "React component," "API endpoint," "database migration," "TypeScript interface" - AICHE handles technical vocabulary well, especially with Recognition Fix at Polish level. Uncommon library names may need one correction.

Dictate in the moment. The best time to document code is right after writing it, when the logic and reasoning are fresh. Waiting until later means you forget the "why" behind decisions and write documentation that describes what the code does (which anyone can read from the code) instead of why it exists.

Batch your documentation sessions. Some developers prefer a dedicated documentation pass: scan through recent code, dictate comments and docs for each file, then move on. A 15-minute voice session can document a full day's worth of code changes.

Result: a comprehensive README that takes 22 minutes to type becomes 6 minutes of dictation, and inline code comments get written immediately instead of being skipped for later.

Do this now: open any undocumented function in your codebase, add a comment block above it, press your hotkey, and dictate what the function does, why it exists, and what edge cases it handles.