A feature has been working locally for twenty minutes. The code is correct, the tests pass, and the change is ready to commit. Writing a commit message that explains what changed and why is the next step — the part of a dev day that is pure prose, exactly like writing an email, and exactly where typing becomes hand motion and voice becomes explanation.
The conventional flow: a dev types a commit message at the keyboard. The context is still hot — the code change is obvious, the problem it solves is fresh, the reasoning is live. But typing the message takes the attention away from the code. A dev who finishes the code and then sits down to think about how to explain it in prose often gets interrupted, or the context fades, and the message either never gets written or comes out generic and unclear.
Hold the key. Say the commit message into the terminal. Let go. One sentence lands in the git editor, timestamped and kept in local history. A terminal is a text field like any other, and dictating into one works the same way it does in a browser — the git editor receives the sentence whether it is vim, nano or whatever core.editor points at.
Add pagination to user query results when limit exceeds service threshold
No message is shorter or longer because it was dictated. It is the same message, spoken instead of typed — but spoken while the code change is fresh and the context is live, rather than after three seconds of hand motion that broke the thought. A developer who dictates the commit message stays in the moment of having just finished the code, rather than context-switching away and back.
The message gets committed. One line of prose, one sentence, enough context for a reviewer to understand what the change is about. That message stays in the git history, linked to the code that proves it. A well-written commit message is the kind of documentation that pays for itself inside a month when someone is trying to understand why a line is there.
10:15 AM: The PR needs a description
The branch is pushed. The PR opens. The description field is empty. What changed, why it matters, what testing it went through — all of that is obvious right now, in the minutes after pushing, and all of it is going to be less obvious when the reviewer reads it tomorrow morning.
The conventional flow: a developer opens the PR form, looks at the summary it auto-generated from commit messages, and either fills in the description field or leaves it empty. Leaving it empty is slower in the long run — reviewers have to dig into the code to understand the intent — but typing the description right then takes another context switch away from the momentum of shipping.
Dictate it now, while the change is clear. The PR description is not code — it is the communication around the code, and it takes five minutes to say and two minutes to undo if something needs correcting.
The description lands. Two paragraphs explaining what the change does, what problem it solves, what testing it went through, and what questions a reviewer should have in mind before diving into the code. No prose is clearer because it was said instead of typed, but it exists earlier in the day, which means reviewers can read it earlier tomorrow morning and start understanding the change before they sit down to review.
11 AM: The code goes to review
The PR is ready and posted to the team's review queue. The context of having just built the feature is the time when the developer most understands what questions a reviewer might have. That understanding will fade.
A message goes into #code-review-queue: the PR number, the component it touches, and one sentence about what changed. That message is there because the developer said it into Slack while the change was still obvious, not because they found time to type it an hour later when the attention had moved to the next task.
11:30 AM: The code that shipped yesterday gets reviewed
A review comment is waiting to be written on a colleague's PR — something about error handling in a data transformation that does not quite make sense. Reading the code and writing a comment at the same time is the usual pattern, and it is where hand motion creates a real cost.
The conventional flow: a reviewer reads a line of code that is puzzling, stops reading to think about what question to ask, opens a text editor or comment field, types the question, and then returns to reading the next section. Stop, type, resume. That cycle takes three seconds per comment, and a typical review has twenty comments. That is a minute of context switches, which compounds: the reviewer finishes the review six comments into the code, but the first comment asked a question about something happening three sections earlier, and now the context has moved on.
Dictating the comment while looking at the code means that loop does not happen. A reviewer reads a section of code, and the moment a question forms, the reviewer holds the key and says the comment into GitHub. The sentence lands in the comment field, timestamped. The code stays in focus. The reviewer keeps reading and does not context-switch. The same habit works one file over, in the code comments themselves, where the explanation of why a branch exists is worth more than the branch.
This catches the transformation error but doesn't log it anywhere that ops can find. Need to either emit a metric here or add it to the structured logs so our error budget is accurate.
The feedback is the same whether it was typed or spoken. The difference is that eight code reviews happen in the time seven would have taken, because nobody has to redirect their eyes between the code and a text editor. The difference compounds: a reviewer who stays focused on the code writes more accurate feedback, because the code is still in working memory while the comment is being formed.
12:30 PM: A Slack thread about an incident
A system metric raised an alert fifteen minutes ago. The on-call engineer investigated, found the root cause, and applied a temporary mitigation while a more permanent fix gets scheduled. The question "what happened?" is in #incidents, and several engineers are guessing wrong because the details have not been posted yet.
The conventional flow: an engineer finishes the debugging, opens Slack, types an explanation, and posts it. But by then an hour might have passed, and the team has had time to propose five different theories about what the cause was. The first engineer types the right answer, but the wrong answers are already in people's heads.
Dictate one message into Slack while the investigation is still live. The context arrives while it is still load-bearing, and the team has the right story before the wrong stories take root. Chat is where most of a dev team's prose actually lives, and it is the place where the gap between what someone knows and what they have written down is widest.
1:30 PM: The Linear ticket for tomorrow's work
Tomorrow is a feature that touches the same code path as this morning's work. A ticket needs a comment describing what questions need answering before diving in, what the edge cases are, what the performance implications might be. One comment, a few sentences, dictated while the code is still in working memory.
A developer who types that comment loses the context during hand motion. A developer who says it keeps the thought through the moment the text appears, and the comment ends up more accurate and more useful for whoever picks up the ticket next.
2 PM: Context-switching to the next task
The day has reached the afternoon. Morning code got committed, reviewed, and shipped. Review comments got posted on other people's code, in the moments when understanding was fresh. Slack threads got closed with accurate information. Linear tickets got annotated with context that saves the next developer six minutes of investigation.
None of that is new. Commit messages, PR descriptions, code review comments and Slack threads exist on every developer's day. The difference dictation makes is that they get written in the moments when the context is live — right after a commit, while reading a PR, immediately after understanding a bug — rather than accumulated into a task for later when the reasoning has evaporated.
The compound effect across a year
A single day's worth of voice-dictated prose is a modest saving. Right after a commit, a developer saves thirty seconds of typing. While reviewing code, a developer saves three seconds per comment and stays in focus longer. Posted immediately, a Slack explanation prevents an hour of post-mortem guessing.
Across a week, that is one extra review completed the day it lands, one incident resolved three hours faster, three features shipped with better commit messages. Across a year, that is twenty more reviews finished on time, thirty faster incident responses, hundreds of commits that a future developer can actually understand without diving into the code.
The math is not complex, but the compound is real: five percent more reviews completed on the day they are assigned, five percent of postmortems solved by an engineer who remembered to record what happened an hour after the fix shipped.
Why this is different from typing on a deadline
A developer who types commit messages, review comments, and Slack posts has to decide whether to write them live or defer them. Writing them live means context-switching away from the code. Deferring them means losing context. Most developers choose deferring, which means most commit messages are generic and most review comments arrive after the code has been forgotten.
Dictation changes the tradeoff. A developer can dictate a comment into a text field while still looking at the code — no context switch at all. The sentence lands the moment it is formed. The code stays in working memory. By the time the dictation is done, the comment is timestamped and ready to post.
That is not faster at typing. That is the same speed at communicating, except the communication happens when the context is live instead of hours later when the reasoning has faded.
Why this adds up across a day
A developer who dictates one PR description, one commit message, two code review comments and one Slack explanation has written about fifteen lines of prose in the moments when they made sense. That same developer who typed all of that, or deferred writing it, would either lose time context-switching or lose context by deferring.
None of that saves time in the moment. It saves time across a week by making reviews more accurate, reducing the need for clarification comments on PRs, and preventing incidents from being investigated wrong because the context was never written down.
The only real limitation: syntax
This app does not write code syntax. It does not turn spoken commands into keystrokes that build a program. That is Talon's domain, and Talon does it better because it has twenty years of development and a large community of programmers building grammars for every language.
What this app does is write the ninety percent of a dev day that is not syntax: the words around the code. If that ninety percent stays in your working memory long enough to be useful — captured the moment it forms, timestamped, indexed, and never uploaded — then a dev can ship code with better commit messages, better review comments, and better incident documentation. That is the scope of the tool, and that scope is useful exactly because it has a clear boundary.
The app keeps everything local, so a commit message that names an internal project, a review comment about a private vulnerability, or a Slack thread about an incident stays on your machine until you choose to paste it. Only prose, never syntax, and nothing but what you said. One-time purchase versus subscription. The rest of the day's shape is in the developer's use case, and the field as a whole in speech-to-text for developers.