There's a specific kind of frustration I've started running into that I didn't have two years ago. I'll be deep in a problem with the solution fully formed in my head, the architecture clear, the edge cases all mapped out. Then I sit down to type it out and immediately feel this mismatch. My thoughts are running faster than my fingers can keep up, and by the time I've typed three sentences I've already dropped two ideas. I try to compensate by going faster. The prompt gets messier and the output gets worse. For a long time I told myself it was just a typing speed problem, but the more I paid attention the more I realised that wasn't really what was going on.
The old bottleneck is gone
For most of software history, the bottleneck was the code itself. You had an idea, you sat down, you wrote it out slowly and carefully, one syntactically correct line at a time. The machine was dumb and you had to be precise.
That's changed completely. Today, 92% of developers use AI coding tools daily and an estimated 41% of code being written is AI-generated. The machine got astonishingly fast, and in doing so it moved the bottleneck somewhere nobody was really prepared for: it moved it to us. What's actually slowing people down now is no longer the act of writing code but the much harder problem of communicating an idea clearly enough for the AI to do something useful with it.
Typing is too slow, but that's only half the problem
The obvious response is: use your voice. And people are. The gooseneck microphone is quietly becoming the developer's desk staple of 2026, the way the standing desk was the decade before. Speak at 150 words per minute instead of typing at 40. On paper that sounds like it fixes things.
And it does. It reduces a bit of friction between you and the machine, but Speed was never the core issue. You can ramble at 150 WPM just as ineffectively as you can type slowly and badly. Whether the output channel is a keyboard or your voice, the real problem sits further back than that. It's what happens before you open your mouth or touch the keyboard at all.
The real barrier: thought to language to prompt to output
Every time you communicate an idea to an AI, you're performing a translation. The idea in your head is rich: it has context, history, constraints, preferences, implicit assumptions you've never even articulated to yourself. When you put it into language, some of that gets stripped away. When you compress language into a prompt, more gets stripped. By the time the model is working, it's working from a shadow of the original idea.
When the output misses the mark, most people assume the model got it wrong. More often what happened is a translation failure on the human side of the window. This is what people working in AI are calling context engineering: the deliberate work of packaging your mental model so that the AI can reconstruct it faithfully, less about finding better words and more about designing a better information environment to hand over. Each From your Idea to the actual prompt creates friction, you can compare it to a game of Telephone (in Germany we call this Stille Post) where each participant of the "chat chain" gets less or different informations. To avoid these degeradation of inputs, your skill to explain your mental model is getting much more important.
The new top skill: be the Great Explainer
Richard Feynman earned the nickname "The Great Explainer" by doing one thing extraordinarily well: taking a complex idea and distilling it until anyone could understand it. His rule was blunt: if you can't explain something simply, you don't understand it yet. The complexity isn't in the subject, it's in your own incomplete grasp of it.
That principle now applies directly to you working with AI.
The best results I've seen, and the best results I get, don't come from people who have mastered prompt syntax or memorised clever templates. They come from people who have done the Feynman work first. People who have sat with their idea long enough to actually know what they want, and can then explain it in plain terms, not because the AI needs simplicity but because that clarity is proof the idea is fully formed. The word for this is lucidity, and it turns out to be both the oldest and the newest skill in the room.
Why this hits hardest in coding
Code is uniquely unforgiving here. An idea in plain language can be a little fuzzy and still land. Code exists in a web of invisible context: your file structure, your naming conventions, the architectural decisions you made six months ago, the performance constraints nobody wrote down, the tech debt your whole team silently works around.
A human colleague absorbs all of that over weeks of working alongside you. An LLM gets whatever you put in the context window, right now, in the next thirty seconds. The difference between a vague ten-word prompt and a rich hundred-word prompt that includes your architecture, your constraints, and your actual intent isn't a stylistic preference. It's what separates generic broken code from something you can actually ship, and that entire gap lives on the human side. Of course there are harnesses like claude code or codex which try to mitigate this problem the best waye they can and they implement semantic trees of your codebase to have the LLM better understand the context it is working in. But still. Having the gift of explaining what you actually want will win, always.
The practical move: flip the roles
Even the best explainers have blind spots. You can't articulate what you haven't yet noticed, and that's where the /grill-me skill comes in. It's the most useful thing I've added to my workflow in the past year.
Instead of you explaining to the AI, you flip it: the AI interviews you. Relentlessly. It walks down every branch of the decision tree, surfaces the dependencies you hadn't noticed, and forces you to answer questions you didn't know were open. Rather than simplifying for an audience, you end up being interrogated until the idea is fully exposed.
Before AI, developers called this rubber ducking: explaining your problem out loud to an inanimate object until you figure out what you actually mean. The grill-me skill is rubber ducking with a duck that talks back, asks follow-up questions, and recommends answers to the obvious ones so you can move fast and spend your energy on the genuinely hard decisions.
Of course, you still have to make the call when the questioning is enough. And that is usually when the model is getting into really detailed questions which do not particualy matter at that specific time but should be asks later on.
You can find the full skill and how to use it at aihero.dev. These "grill-me" sessions are time consuming. They routinely run 30 minutes and end with a context window that's dense with exactly the right information, and at that point the AI has everything it needs rather than having to guess. So use it wisely.
The two skills compound nicely: if you're already a clear thinker, grill-me sessions are faster and tighter. If you're not yet, they'll train you to become one. Either way, you close the gap.
A new literacy
We teach writing in schools because externalising thought clearly matters. It changes how you think, not just how you communicate. The same shift is happening now, except the audience is a model rather than a person, and the medium is a context window rather than a page.
The models are good enough. The remaining barrier is cognitive and linguistic, the very human problem of knowing your own mind well enough to hand it off cleanly.
Feynman spent a lifetime learning to put his mind into words. He would have been extraordinary at this.