Stop typing your first drafts and dictate them instead. That is the whole recommendation in this AI Central document, and the case for it is arithmetic. You type at 40 to 60 words per minute. You think and speak at 150 or more. Every typed sentence therefore runs at about a third of your natural speed, which the document prices at roughly two hours lost per day. The fix is not typing faster, it is removing the keyboard.
Reviewed 7 August 2026. The source is a six page AI Central document that names one tool, Wispr Flow, and repeats the same call to action on every page. This piece separates what the document claims, what follows from its own numbers, and what it leaves open.
The arithmetic the whole argument rests on
Two figures carry the document, and it states both of them outright. Typing runs at 40 to 60 words per minute. Thinking and speaking run at 150 or more. Nothing else in the document is a measurement.
Put the second over the first and the conclusion writes itself. At 150 words per minute of thought against 50 typed, you are shipping at one third of your own rate, which is how the document phrases it: every typed sentence is you running at a third of your own speed. That ratio is not rhetoric, it is division, and you can redo it with your own typing speed in a minute.
The headline cost, two hours a day, is a different kind of claim. The document states the number and does not show how it was derived. Treat it as the document's estimate rather than a measured result. The ratio you can verify yourself. The two hours you have to accept or test on your own week.
The bottleneck is your hands, not your head
The strongest idea here is not the speed gap. It is where the document puts the blame.
Most advice about writing faster treats slowness as a thinking problem. Better outline, tighter brief, fewer distractions. The document rejects that framing and splits the job in two: composing the sentence, then transcribing it. Composing is fast. Transcription, the mechanical act of pushing a finished thought through ten fingers, is what costs the time. The document's own phrase for this is that your hands are the bottleneck, not your head.
That reframe changes what you should try to fix. If the head were the bottleneck, a better process would help. If the hands are the bottleneck, no amount of process helps and only a faster output channel does.
Where the tax actually hides
The document is specific about where the loss accumulates, and the list is deliberately unglamorous. It names five surfaces: email, Slack, documents, notes and prompts.
- Email, where the thinking is usually finished before you open the reply box and the only thing left is transcription.
- Slack, where the cost is never any single message, it is the hundreds of them.
- Documents, where a first draft gets throttled to typing speed even though the argument already exists in your head.
- Notes, the purest case of the problem, because nobody is editing a note for style.
- Prompts, the newest surface on the list, and the one where a rough spoken instruction tends to work as well as a polished typed one.
None of it is hard; all of it is slow
That is the document's own line about the list, and it explains why this particular tax stays invisible. Nothing on it feels like work worth optimising. Each item is trivial on its own, which is exactly why nobody ever attacks it, and why the total is large enough to be worth a document.
Why the fix is not faster typing
The obvious response to a speed gap is to close it by typing faster. The document refuses that route in four words.
The fix isn’t typing faster
The reasoning holds. Typing speed has a hard ceiling set by hands, and even a large gain in words per minute leaves you far short of speech. So the document deletes the step instead of optimising it: speak, and let the tool write into the applications you already work in, which is what its line about writing faster in all your apps is pointing at. Voice closes the gap between thought and delivery because it removes the keyboard rather than speeding it up.
What changes, and where the ceiling really is
The document is precise about the payoff it expects, and it offers the same claim two ways. The same output in a fourth of the time, or four times the output in the same time.
Or 4x the output in the same time
That is the document's framing of the upside, and it is worth being clear about what a four times figure can mean. It is a ceiling on the transcription step, not a promise about finished work. Dictating a paragraph in a quarter of the time only compounds if the thinking and the editing around it do not expand to fill the space you just freed. The gain is largest exactly where the document says the tax hides: high volume, low polish writing where the first pass is close to the last one.
How to run this for a week
The document ends on an instruction rather than a plan, so here is the practical version. The test is cheap and the failure mode shows up within days.
- Start on the lowest stakes surface. Notes and Slack, not a client email.
- Speak the whole thought before you touch anything. The gain disappears if you stop to correct every third word.
- Edit once, at the end, with your eyes rather than your voice.
- Keep the keyboard for anything short and structured. Passwords, code and one word replies are not where the tax lives.
- After a week, compare what you actually shipped, not how it felt. Feeling faster and being faster are different measurements.
If you already dictate, the upgrade this document points at is not accuracy, it is reach: using voice everywhere you type instead of only in a notes app. If you have never dictated, expect the first two days to feel worse than typing. That is the cost of learning to think out loud, and you pay it once.
What the document does not settle
Three gaps are worth naming plainly. The two hours a day figure arrives without a method, so it is an estimate rather than a finding. The four times claim describes the transcription step and not a finished piece of work. And the document is built around a single named product, with a call to action on all six of its pages, so read it as a case for voice input made by an interested party rather than as a neutral comparison of tools.
One note on the source itself, for transparency. The transcript of this document carries one garbled line in the section about the bottleneck, and nothing in this article is built on it.
Does dictation really make me four times faster?
Four times is the document's figure for closing the gap between 40 to 60 words per minute typed and 150 or more spoken. It applies to getting words out, not to the whole job. Expect the largest gains on volume writing such as messages, notes and prompts, and much smaller ones on writing that needs heavy editing.
What if I cannot talk out loud where I work?
Then the premise does not hold for most of your day, and that is a real limit the document does not address. Its argument assumes you can speak freely. If you cannot, the honest answer is that the technique only pays off in the pockets of your day where you can.
Will my writing get worse if I speak it?
Spoken drafts read differently from typed ones. They tend to run longer and looser. That is a reason to keep one editing pass, not a reason to keep typing, because editing a fast draft still costs less total time than typing a slow one.
Do I have to use Wispr Flow specifically?
The document names one tool and only that tool, and describes it as removing the keyboard entirely so you can write faster in all your apps. The underlying argument, that speech runs roughly three times faster than typing, is about the input method rather than any single product. The document does not compare alternatives, so it cannot settle that for you.
If I change only one thing, where do I start?
Prompts. They sit on the document's own list of where the tax hides, and a rough spoken instruction usually works as well as a polished typed one. There is almost no editing penalty, so the speed gain drops straight to the bottom line.