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. In GitHub's developer survey, 92% of US-based developers said they already use AI coding tools at work, and that was before agents could edit a whole repository. 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 takes some friction out of the channel 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, more about designing a better information environment to hand over.
Every hop from idea to language to prompt loses something. It's a game of Telephone — Stille Post, in German — where each link in the chain passes on a slightly thinner version of the message. The only place you can stop that degradation is at the source, which is why being able to explain your own mental model has quietly become the skill that matters.
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 that try to mitigate this, building semantic trees of your codebase so the LLM understands the context it is working in. They help. But they can only recover what is already written down somewhere. The intent never is. Being able to explain what you actually want still wins.
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 on when the questioning has been enough. For me that point usually arrives when the model starts drilling into details that don't matter yet, but will matter later.
You can find the full skill and how to use it at aihero.dev. These grill-me sessions take time: they routinely run 30 minutes. But they end with a context window dense with exactly the right information, and at that point the AI has everything it needs instead of having to guess. Use them 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.