How to dictate code without ending up with 'open paren close paren' soup

Step by step

1. 1

   Dictate comments and docstrings — never the function signature

   Position your cursor on the line above a function and hold push-to-talk. Dictate the prose explanation of what the function does, who calls it, and what edge cases it handles. Release. Then type the function signature and body with your hands, because dictation reliably mangles type annotations, generic parameters, and parameter lists. The split is clean: voice owns the natural-language layer of the file — block comments, docstrings, TODO notes, deprecation reasons — and your fingers own the code layer. This division produces better comments than typing does, because speaking aloud forces clearer explanations.

2. 2

   Use voice for commit messages and PR descriptions, not for the diff

   Open your terminal or Git client, run git commit, and inside the message editor hold push-to-talk. Dictate a one-line summary followed by a two-to-three-sentence body explaining the why. Release. The same applies to PR descriptions on GitHub: click into the description textarea, dictate the context, the change, and the testing notes. PR descriptions are pure English-language artefacts that benefit from speaking pace — the average dictated PR description is forty percent longer and substantially more informative than the average typed one, because typing punishes long explanations.

3. 3

   For pseudocode-to-real-code, dictate the algorithm then trigger AI rewrite

   When you are exploring an approach before committing to syntax, open a scratch buffer and dictate the algorithm in plain English: 'Loop through each user in the array, period, for any user with a stale token, period, refresh the token and update the database row, period.' Release. Select the dictated block, trigger Amical's AI rewrite with your BYO LLM key, and prompt for 'convert to TypeScript with proper error handling'. The model returns real code based on your spoken algorithm. Treat its output as a starting point, not a finished implementation — review and edit before committing.

4. 4

   Use voice to brainstorm variable and function names out loud

   Naming is the part of coding most directly limited by typing speed because you tend to stop at the first acceptable name to keep moving. Voice removes that pressure. Hold the hotkey and dictate ten candidate names for a function: 'fetchUserSession, refreshAuthToken, getActiveCredentials, hydrateUserContext, primeSessionCache' and so on. Release. Read the list, pick the best one, delete the rest. This twenty-second exercise produces measurably better names because the cost of generating each candidate dropped from typing it to speaking it. Names that survive this exercise hold up better in code review.

5. 5

   Know the cases where voice is wrong for coding and just type

   Do not dictate: actual syntax with operators and brackets, configuration files with strict indentation like YAML, regular expressions, SQL queries with quoted strings, JSON or TOML, terminal commands with flags, or any code where a single character mistake breaks the build. The error rate is unacceptable and the time to correct mistakes exceeds the time to type it correctly the first time. Voice for code is exclusively a tool for the English-language artefacts that surround code — comments, descriptions, names, pseudocode — not for the code itself. Anyone selling you voice-for-syntax is overselling.

Frequently asked questions

Use Amical with the apps in this guide

Cursor

VS Code

GitHub

Built for these roles