NVIDIA's Jensen Huang: The Most Valuable Thing You Can Do Is Explain What You Want

Every frustrated delegation story has the same shape. You asked for X, the other party built Y, and in the post-mortem everyone agrees the request was clear. The gap is not malice; it is the difference between what you wanted and what you managed to describe, and the gap is widest exactly where your expertise is deepest, because when you know a domain well, the context you assume is the context you forget to state. Jensen Huang's remark draws the boundary in sharp terms: the most valuable thing you can do is explain what you want, which is a different claim from thinking faster or typing better.

The explanation gap is structural, not personal. Your request is an export of a mental model, and the export drops exactly the parts everyone takes for granted: the history, the constraints, the exceptions, the reasons the existing thing is set up the way it is. Listeners repair the loss by asking questions, and the repair works because they share enough culture and context. An agent does not repair. It executes the export as if it were the whole model, and it never sees the silence. This is why the same person can be a brilliant explainer across the table and a confusing prompt author at the keyboard.

The gap grows as work moves to agents because agents fill it with confidence. A human saying 'I am not sure what you mean' at least surfaces the problem; a model produces the most probable completion of your words, which feels like an answer and is often an answer to the wrong question. That is the expensive failure mode of the agent era: not silence, but the confident wrong thing. Executors used to be the bottleneck and made the gap visible; agents made execution invisible, which moves the requirement up the chain. Explaining well is no longer a communication virtue; it is the performance standard.

The good news embedded in the claim is that explanation is trainable, unlike typing speed or raw IQ. Nobody is born clear; clarity is a craft with a structure, and the structure is mostly naming the thing you omit. If the gap is a habit, then the practical answer to Jensen's remark is a set of habits: state the audience, the constraint, the example, and the failure condition. The rest of this article takes those habits apart one at a time, and then deals with the uncomfortable fact that most people explain better out loud than they do on a keyboard.

It is worth stating the mechanism plainly because it explains every disappointing output. An agent has access to your explanation; it does not have access to your intention. It optimizes for the most plausible completion of the text you provided, which is an excellent guesser's job, not a mind reader's job. When your explanation is missing a constraint, the guesser cannot invent it from the corpus, so it fills the hole with the most common pattern. The result is a plausible report, a plausible email, or a plausible refactor: plausible because it follows your words, useless because it missed your point.

The corollary is about feedback. When a human consultant produces the wrong thing, you correct them mid-task and the correction enters their model of you. When an agent produces the wrong thing, you are usually correcting the previous run, not teaching the next one, and each correction consumes a round trip. In the agent economy, the number of corrections per task is the tax on your explanation. The tax is paid in attention, which is the resource that disappears first in a week of supervising. A poor explainer in an agentic workflow spends the day supervising; a good explainer spends it deciding, and the difference shows up as headroom, which is the wage Jensen is pointing at.

The second corollary is that the agent's confidence makes the gap feel safe. Nothing in the interface signals 'I guessed this part,' so the output arrives with the authority of a finished artifact, and the review habit is the only defense. Professionals who get good at this stop reading summaries and start checking the load-bearing bits: the numbers, the names, the assumptions. In practice, the checklist is short: every number, every proper noun, and every assumption should be traceable to something you actually said or provided. Reading everything is too costly; classifying the parts that must be verified is the discipline, and the discipline is only possible when the explanation told you exactly which parts those are.

This is also the honest reason why 'prompt engineering' as a vocabulary is off-base. The mechanical trick list, acting as a senior analyst, thinking step by step, is a crutch for a missing explanation. What actually moves outputs are content-expanding statements: the audience, the decision, the number that must check out, the example of a similar thing you liked or hated. When Jensen says the valuable act is explaining what you want, he is saying the value moved from the keys to the brief, and the brief cannot be faked with a persona tag; it has to contain the thing you actually know.

Treat the explanation as a spec and it becomes learnable. Three components carry most of the weight. Context is the part your recipient needs and would otherwise guess: the situation, the reader, the history, the systems involved. Constraints are the boundaries: what must not change, what does not matter, the budget, the format, the deadline, the vocabulary that must appear. Concrete examples are the anchor: one sample of good, one sample of bad, or one file reference. None of the three requires eloquence; they require only that you say the part you were about to skip. Together they turn a request into a brief that a competent executor can run with, which is the entire point.

Context is where experts fail most. The reason the old CRM has a field nobody uses, the reason the launch date moved, the reason this customer gets different treatment: all of it sits in your head and nobody else's, and every one of those facts changes the correct output. The training habit is the context sentence: say 'here is the part you need to know,' and then say it in one breath. If the sentence runs long, the context is probably two contexts, and you can split them. A competent agent with your context beats a brilliant agent without it, every time.

Constraints are the second lever and the most underused. An unbounded request invites the average answer, the one that hedges toward safety; a bounded request forces a specific one. The craft of constraints is mostly adversarial: before you send, ask what the worst plausible output would be, and then name the constraint that kills it. 'Do not exceed two pages' kills the padded answer. 'Name the risk in the first line' kills the buried finding. 'Do not quote the vendor's metrics' kills the copied slide. Each constraint is a decision you have already made, exported so the agent does not have to guess it.

Concrete examples beat adjectives on every test. 'Professional tone' is a guess; 'here is a recent email we sent to this client' is a definition. Descriptions of a design dream about 'clean' and 'modern' while a single screenshot of a different product says everything. For the same reason, the most valuable piece of an explanation is often the named artifact: the document, the function, the folder, the message thread the agent should look at before doing anything else. When in doubt, show more and describe less, because a reference is worth a paragraph of adjectives. In a Cursor workflow, the file path in the prompt is the difference between a guess and a ground truth.

The uncomfortable observation is that most people are better explainers than they are typers. In a conversation, you do not pre-compose; you start with the part you know, circle, correct yourself, and the other person follows. The structure of the explanation is negotiated out loud, and clarity emerges from the back-and-forth. At a keyboard, the same person writes one clean paragraph and sends it, honoring the constraint of the medium: no correction, no circling, and the reasoning stays unsaid. That is the real reason so many excellent briefs begin with 'let me just walk you through this,' a sentence nobody types. Every voice note you have ever received is a proof that spoken explanation carries more context per minute than its typed equivalent.

The mechanism is that speech externalizes the thinking loop typing hides. When you speak, the revision is audible and the listener absorbs it; when you type, the revision is deleted and the reader never knows what boundary you were exploring. That is why speaking a spec usually produces the missing pieces: the constraint arrives in the third sentence, the exception in the fifth, and the real goal in the last, after the context has been warmed up. The same loss happens in reverse when you read someone else's typed brief: you are reading the conclusion of their thinking, not the thinking. A transcript of that talk shows you the raw, complete explanation that the typed version never contained.

So the practical upgrade is to write the way you talk, with a translation step. Speak the full explanation out loud first, without composing; then polish it into the spec, removing the false starts and reordering so the reader gets the goal first and the caveats second; then type or paste the polished version into the field. The speak-polish-edit loop is exactly that process with the translation automated: the system reads your intent, not just your words, and returns a structured brief you can review. The pause when you lose the thread is not a flaw in your thinking; it is the location of the decision you have not made yet. The keyboard produced an abbreviated export; talking-to-polish produces the full one.

The same logic works in reverse for the hardest delegations. When you must brief the expert who will do the work, human or agent, do it out loud: talk through what you want and let the listener, or the recorder, catch the places where you hesitate, because the hesitation marks the exact point that needs a decision. Then restate it with the hesitation resolved. The people who built the moat did not get there by being smarter than you; they got there by completing one more sentence than their rivals. Most people began doing this decades ago in hallway conversations; the agent era just makes the hallway conversation the most valuable part of the work, and the reason to keep it.

The phrase 'explanation moat' sounds grand, but the mechanism is mundane. When everyone has the same models, tools, and data, the one variable left is the quality of the brief that goes in. A person who consistently exports a complete explanation gets first-pass results, then spends the savings on the next problem; a person who exports a fragment spends the day on corrections. Compounding decides the gap, and the compounding happens at the speed of your daily delegations. If the pipeline feels long, remember that most of it already happens, just invisibly and on the other side of the keyboard. The moat is not a secret; it is the unglamorous discipline of completing the explanation before handing it over.

The practical pipeline that builds the moat is the same one the rest of this article has described. Speak it: get the whole thought out in its natural order, including the parts you want to include. Polish it: strip the filler, keep the intent, and organize it into the spec shape, context, constraints, examples, plus one line of what success looks like. Hand it to the agent: the polished brief goes to the coding assistant, the research bot, the drafting tool, or the colleague, and the output lands closer to target. The discipline is the asset, and the channel is only the place where the discipline gets exercised. Review before send stays yours, because verification is the other half of direction.

The moat compounds with the channel because the loop fits any field. At the system level on Mac and Windows, the same polish happens in Gmail, in a document, in a chat, or in the prompt box of a developer tool, which means the explanation discipline does not stay a special occasion. Privacy matters here for the same reason it mattered everywhere: if audio stays local, with zero server retention and SOC 2 Type II on the deployment, then the explanation can be honest about the sensitive part, the real constraint behind the request, and the honest version is the version the agent needs.

Jensen's remark, that the most valuable thing you can do is explain what you want, is the quiet half of the typing verdict. If typing prices at zero, specifying prices up, and specifying is the skill of making your intention legible to an executor that will not fill in the blanks. That is what the roads he paved have in common: the agent you hire, the voice you speak to it, the local computer that keeps it private, and the real-time conversation, every one of them is a request to make yourself understood. NVIDIA makes the machine hear you. The explanation is what makes it know what you meant.