As a programmer, I type a lot. And now that AI has become part of my daily workflow, I type even more.
Prompts, follow-up prompts, explanations, corrections, code context, error messages. It adds up.
My typing speed is pretty good, so for a while I didn't think this was much of a problem. But eventually I realized that typing speed wasn't actually the bottleneck.
The bottleneck was thinking.
I can explain something out loud much faster than I can type it. More importantly, when I'm typing a prompt, I have a tendency to shorten what I'm thinking.
Instead of explaining the whole problem, I write the minimum.
Instead of providing all the context in my head, I leave half of it out.
Then the AI misunderstands something.
Then I correct it.
Then it makes another assumption.
Then I explain the thing I should have explained in the first prompt.
And suddenly I've spent ten minutes going back and forth over something that could have been explained in a 60-second conversation.
So I started looking for a reliable way to talk to my computer and have it type my AI prompts for me.
Not a complicated voice assistant. Just:
Press a key → talk → stop talking → get good text.
It sounds simple. Finding a setup I actually liked took a bit more work.
Windows already has voice typing built in.
You can press Win + H, start talking, and Windows will transcribe what you say into the active text field.
You can read more about it in Microsoft's official Voice Typing documentation.
And to be fair, it's pretty good.
It's fast, it's already installed, and it's free.
For normal writing, emails, messages, and general-purpose text, I think it's completely usable.
My problem was technical language.
Once I started talking about programming concepts, framework names, APIs, functions, variable names, monorepos, server-side rendering, JSON-LD, and all the other weird vocabulary we use as developers, the transcription became less reliable.
You say something perfectly understandable and suddenly there are three words in the middle that make absolutely no sense.
Then you have to go back and fix them manually.
That starts defeating the purpose.
If your work isn't particularly technical, I'd still recommend trying Windows Voice Typing first. There's nothing to install and it might genuinely be all you need.
For me, though, I wanted something better.
The obvious next step was Whisper.
Whisper is very good at speech recognition, including the kind of messy, conversational speech you naturally use when you're explaining a problem.
There are commercial applications built around it, and some have reasonable free tiers.
I tried one that offered a limited number of free words and then required a monthly subscription.
The price wasn't really the problem. It wasn't particularly expensive.
I just didn't want another subscription.
I'm already surrounded by developer tools, AI services, API bills, SaaS subscriptions, and monthly payments. Paying another recurring fee for something I suspected my computer could handle locally didn't feel necessary.
That's what eventually led me to an open-source option.
I found OpenWhispr, an open-source application available on GitHub.
This was much closer to what I wanted.
It can use remotely hosted Whisper models through an API, but importantly, it can also run the speech-recognition model locally on your own computer.
That's what I'm doing.
At first, I used the Whisper Base model, which is around 141 MB.
It worked, and it was fast, but for my use case it made too many mistakes.
Technical terms were the main problem. The model would hear something close enough to what I said, but not close enough to what I actually meant.
So I moved to OpenAI Whisper Small, which is roughly 465 MB.
For me, that was the sweet spot.
The Small model has been golden.
It's still fast enough on my desktop that it doesn't interrupt my workflow, but the accuracy is noticeably better than Base, especially when I'm speaking quickly or throwing a lot of technical vocabulary into the same prompt.
That means the main speech-to-text step costs me nothing per transcription.
No word limits.
No monthly subscription.
No worrying about how many prompts I dictated today.
I just talk.
Speech isn't the same as writing.
When I talk naturally, I'll say things like:
Okay so basically what I want here is, uh, take this function and maybe instead of doing this every time, we should probably cache it, but only if the user is authenticated...
A speech recognition model can transcribe that accurately.
But an accurate transcription isn't necessarily a good prompt.
Spoken language has filler words, repetitions, unfinished sentences, corrections, and ideas that change halfway through a sentence.
This is where the second part of the setup comes in.
OpenWhispr can take the transcription and pass it through an LLM before inserting the final text.
So the workflow becomes:
My voice → Whisper → raw transcription → LLM cleanup → finished prompt
That small extra step makes a huge difference.
The LLM isn't there to answer my prompt. Its job is to understand what I said, clean up the wording, fix obvious transcription mistakes, normalize technical terms, and return something that reads like I actually sat down and wrote it properly.
One of the best improvements I made was customizing the cleanup prompt.
OpenWhispr lets you edit the prompt that gets sent to the LLM, so I don't just tell it to clean up the transcription. I also give it some context about me and the kind of language I normally use.
At the top of my prompt, I added something like this:
CONTEXT: User name is Sadeq. He is a technical user and mostly talks about technical stuff. His stack includes Vue, Nuxt, Directus, Express, and related web-development technologies. He is a programmer doing heavy work on a monorepo, so when cleaning up transcription, keep this context in mind.
This matters more than it might seem.
Speech recognition mistakes are often contextual.
If the transcription contains something that sounds like "view," the cleanup model has a better chance of realizing I probably said Vue.
If it sees something like "Jason LD," it can infer that I probably meant JSON-LD.
If it sees some mangled version of Directus, Nuxt, monorepo, SSR, or another technical term I use constantly, it has a better shot at correcting it properly.
I also added examples to show the model the exact kind of cleanup I expect.
For example:
Input: create another Jasson eldie, emmm schema file inside my sidiq dev application in my mono repo and audit all the changes in the end
Output: Create another JSON-LD schema file inside my Sadeq dev application in my monorepo, and audit all the changes in the end.
And another example:
Input: check the new use fetch implementation in nucks and make sure the direct us requests aren't happening twice during server side rendering
Output: Check the new useFetch implementation in Nuxt and make sure the Directus requests aren't happening twice during server-side rendering.
I like this approach because I'm not asking the LLM to rewrite my thoughts into some over-polished corporate prompt.
I want it to preserve what I meant and how I naturally speak.
I just want it to understand my vocabulary.
That distinction is important.
For the cleanup step, I connected OpenWhispr to OpenRouter.
OpenRouter gives you access to many different language models through one API, including models and routes that can be used for free depending on current availability.
So in my current setup:
The only part leaving my machine in this setup is the LLM cleanup step.
If privacy is important for a particular prompt, that's worth keeping in mind.
You can skip the cleanup step entirely, or use a local LLM and make the whole pipeline local.
This is one of the most important practical things I learned while using OpenRouter.
At first, it's tempting to choose the strongest, most popular free model you can find.
That sounds logical.
But for this use case, the smartest model is not necessarily the best model.
The cleanup model isn't solving a difficult programming problem. It isn't planning architecture. It isn't writing an application from scratch.
Its job is mostly:
Understand messy transcription → fix obvious mistakes → normalize terminology → return the result quickly.
Most reasonably capable models can handle that.
The thing that can completely ruin the experience is latency.
I had this problem personally with some of the more popular free models available through OpenRouter.
At the time I was testing them, some popular NVIDIA-backed models looked like an obvious choice because they were powerful and widely used.
But the latency was terrible for this particular workflow.
You stop speaking.
Then you wait.
And wait.
And wait some more.
That sounds like a small problem, but when you use voice input dozens of times per day, those few seconds become extremely annoying.
Your life becomes miserable surprisingly fast.
So instead of automatically picking the most popular free model, I now prefer a model with lower latency, even if it's technically less impressive.
For transcription cleanup, responsiveness matters more than benchmark scores.
A smaller or less popular model that responds almost instantly can feel dramatically better than a stronger model sitting behind a busy free endpoint.
That is probably the biggest thing I'd tell someone copying this setup:
Choose your cleanup model based on latency first, intelligence second.
The biggest benefit isn't actually that I can "type" faster.
It's that I give the AI more context.
That's the important part.
When typing feels expensive, you unconsciously compress your thoughts.
You write:
Fix this function. It sometimes returns the wrong result.
But when talking is effortless, you say:
This function works most of the time, but when two requests arrive at roughly the same time we're sometimes getting the previous cached value. I think it might be related to this lock here, but I'm not sure. I don't want to change the public interface because several other parts of the application depend on it. Can you inspect the concurrency logic first and tell me where the race condition could happen?
That is a much better prompt.
Not because of some magical prompt-engineering technique.
You simply gave the AI the information that was already in your head.
And that means fewer misunderstandings, fewer follow-up messages, fewer corrections, and fewer rounds of:
No, that's not what I meant.
Once I started dictating longer prompts, I noticed that I was spending less time fighting with AI responses.
That's the real productivity improvement.
Put the cursor wherever I want the prompt to appear.
This can be ChatGPT, Claude, an IDE, a browser, a text editor, or almost any other application.
Trigger OpenWhispr with a shortcut.
I press the shortcut and start talking naturally.
I don't try to speak like I'm dictating a formal document. I just explain the problem the same way I would explain it to another developer sitting next to me.
Whisper Small transcribes the audio locally.
The local model converts my speech into raw text.
The transcription goes through an LLM.
The cleanup model uses my custom context and examples to fix transcription errors, normalize technical terminology, remove unnecessary filler, and make the result easier to read.
The finished text is inserted into the application.
I quickly scan it, make any tiny correction if necessary, and send the prompt.
That's it.
After using it for a while, manually typing a long AI prompt starts to feel strangely inefficient.
At first, I thought I was looking for better speech-to-text software.
But that's not really what I wanted.
What I wanted was a low-friction interface between my thoughts and an AI.
Traditional typing puts a surprisingly large compression layer between those two things.
You think ten sentences.
You type four.
The AI receives four.
Then you spend another five messages slowly giving it the other six sentences of context.
Voice changes that equation.
When talking is almost free, you can explain the edge cases.
You can mention the weird behavior you noticed yesterday.
You can explain what you've already tried.
You can say what you absolutely don't want changed.
You can explain the architecture around the problem instead of only the line of code that happens to be broken.
The prompt becomes richer because providing context no longer feels like work.
And with AI tools, better context is often worth far more than clever prompting tricks.
No.
Technical terms can still occasionally be transcribed incorrectly.
Local models use system resources.
The LLM cleanup step can sometimes rewrite something more aggressively than you'd like.
A slow remote model can make the whole workflow frustrating.
And depending on how you configure it, you should think carefully about privacy before sending sensitive dictated text to any remote model.
But compared with manually typing every long prompt, the tradeoff has been easily worth it for me.
I still type short questions.
But when I need to explain a bug, describe architecture, brainstorm an implementation, review some code, or give an AI a lot of context, I increasingly just talk.
The funny thing is that I started doing this because I wanted to save time typing.
I ended up discovering that the bigger advantage was something else
I communicate with AI better when I'm not worried about how much I have to type.
Hi, Im a seniour software engineer building web platforms. I write about Nuxt, Typescript, DevOps, AI and engineering decisions behind real products, based on my real experience.