Michael Polanyi put it simply: We know more than we can tell.
You know how to keep a bike balanced, but you can’t write a manual that teaches someone to ride. You recognize a familiar face instantly, but you can’t list the features you used. You glance at a code review and know something is off, but you can’t name the rule it violates.
That’s tacit knowledge — judgment you already use but haven’t made explicit.
Subsidiary Clues and Focal Whole
In Polanyi’s framework, tacit knowledge has two layers.
The scattered signals you perceive are subsidiary clues. On a bike: the lean of your body, the micro-adjustments of the handlebar, the feedback from the road. You don’t analyze them one by one, but together they point to a focal whole — balance.
Code is the same. Variable names, function length, abstraction layers, error handling — you don’t check them item by item. You get a gestalt feeling: “this is clean” or “this is wrong.” The judgment comes from the whole, not a single rule.
Why Rules Are Never Enough
Ever written a style guide for a new hire? Use camelCase. Functions under 50 lines. One thing per function. He ships code that passes every rule, and it still feels wrong.
Because the real judgment lives between the rules. Proportion, rhythm, where to put emphasis, what to abstract and what to leave alone — these depend on case memory and trained perception. Hard to codify.
That’s why style guides keep growing and never finish. Every new smell adds a new rule, but the core judgment still slips through the gaps.
What This Means for LLMs
Understanding tacit knowledge saves you a lot of detours with LLMs.
Many people prompt LLMs with rules: you must do X, you must not do Y, format must be Z. It’s the same as handing a style guide to a newcomer — the LLM will fill the gaps with defaults, and the defaults are rarely what you wanted.
It’s more effective to give subsidiary clues.
Give examples, not definitions. Instead of “write concisely,” show three passages you consider concise and let the LLM extract the pattern. Examples get closer to tacit judgment faster than definitions.
Give counterexamples. “This is too verbose” is more specific than “be concise.” Telling the LLM what you don’t want conveys your implicit standard more easily.
Use metaphors. “Like chatting with an old friend” gets closer to the vibe you want than “warm and natural tone.” Metaphor bypasses the difficulty of formalizing and conveys the whole atmosphere directly.
Give context. Who you are, what you’re doing, why you need this — seemingly irrelevant to the task, but they are subsidiary clues that help the LLM complete the focal whole.
Admit when you can’t articulate. When something feels wrong but you can’t pinpoint why, just say: “This feels off, but I can’t say exactly where. Take a look.” Then unpack your cues — proportion, rhythm, emphasis, boundaries. No need to define everything at once. Bridge it layer by layer.
In Practice
At work I once used an LLM to batch-generate promotional scripts for short videos. Different brands, categories, and models all had different rules — some needed to highlight specs, some needed storytelling, some wanted a hard tone, some soft. My first approach was explicit rules: a prompt listing “must include X,” “must not include Y,” “format must be Z.” The prompt kept getting longer, results still fell flat. Too many rules made the LLM lose focus. The output satisfied every rule yet felt wrong overall.
Then I changed tack. No more rules. I just gave a few scripts I considered well-written as examples. The LLM extracted the pattern on its own — rhythm, emphasis, tone, structure — precisely the tacit knowledge that is hard to describe with rules. Results improved immediately, prompts got shorter.
It made me realize: the LLM wasn’t dumb. I was communicating the wrong way. I was forcing implicit knowledge into explicit rules, losing information in translation. The remaining rules were verbose yet missed the essence. Skipping the translation and giving examples directly avoided that loss.