Michael Polanyi put it bluntly: we know more than we can tell.
Your body knows how to balance a bicycle, yet you cannot write a manual that teaches someone to ride instantly. You look at a code snippet and know it stinks, but if asked to cite the exact violated rule, words fail.
That is tacit knowledge: judgment you actively practice but can never fully formalize.
Longer Style Guides, Worse Code
Anyone who has mentored junior devs knows this agony.
You write down clean rules: use camelCase, keep functions under 50 lines, do one thing per function. The PR comes back ticking every checkbox, yet the architecture is an absolute mess.
Good taste lives between the rules. Where abstraction stops, structural rhythm, and when to pragmatically bend the rules cannot be codified into rigid statutes.
Style guides grow thicker and thicker until nobody reads them, yet bad code keeps slipping through.
Prompting by Rules Is a Dead End
When prompting LLMs, many act like strict school principals: you must do this, you must never do that, format must match step 1, 2, 3.
The more rules you stack, the stiffer the output becomes. Where rules leave a gap, the model defaults to bland corporate filler.
Only three approaches actually work:
- Provide examples, not abstract definitions: saying “keep the tone concise and natural” achieves nothing; pasting three actual sentences you like lets the model extract the pattern directly
- Show negative examples: “don’t sound like this” sets hard boundaries faster than describing the ideal state
- Admit when you can’t define it: if the draft feels off, tell it: “this feels fake, rewrite with a raw conversational voice”. Keep judgment in your hands instead of expecting one prompt to solve everything forever
Instead of exhausting yourself translating intuitive taste into rigid rules, pass concrete samples. You lose far less signal in the process.