LLMs Reward Expertise: How Domain Knowledge Turns Prompts Into Answers

You’ve probably lived through the change.

Back in the 2010s, a technical gap meant friction: if you couldn’t write CSS, you either begged a teammate who could—or you hunted the exact solution online and hoped it matched your problem closely enough. Today, you can ask an LLM (a “large language model,” basically a neural net trained to predict text) for CSS, math, or code, and you’ll often get something workable on the first try.

That convenience creates a tempting belief: prompting is a matter of clever wording, and “skill” can’t be that important. What changes when everyone can ask the same model for the same help? Plenty—because the model isn’t guessing what you want. It’s guessing the rest.

This is where domain knowledge quietly becomes the multiplier.

Why “prompting skill” isn’t mostly about prompts

The important skill in LLM prompting isn’t writing fancy incantations. It’s knowing what kind of correct answer exists inside your domain, and being able to steer the model toward that shape.

A useful mental model is this: an LLM can generate plausible text quickly, but your job is to provide the “control signals” that define the solution.

In the source story behind this idea, Terence Tao’s interaction about the Jacobian conjecture becomes a case study. The Jacobian conjecture (a classic question in algebra/geometry) asks whether a polynomial self-map with a Jacobian determinant that is a nonzero constant must have a polynomial inverse. (en.wikipedia.org) A newly discovered counterexample shook that long-standing question, and Tao’s public conversation transcript shows what domain expertise looks like in practice. (teorth.github.io)

Even without reproducing the mathematics itself, the interaction highlights something that beginners often miss: expertise doesn’t mainly show up as “long explanations.” It shows up as precision under pressure—knowing what to test, what to ignore, and what kinds of mistakes are most likely.

A quick story about “expert mode”

Most people try prompting like they’re asking for tutoring.

They ask for an explanation, and they keep answering the model’s questions, treating the conversation like a guided tour. That works for many tasks. But for hard technical problems, it can also lead to a trap: you end up collecting a beautiful, well-written answer that doesn’t match the structure you actually need.

Domain experts behave differently.

They ask in a way that assumes knowledge on both sides. Their messages are short because they already understand the surrounding context. Their feedback is diagnostic rather than emotional. And their iteration targets the failure modes they can recognize.

In Tao’s Jacobian-focused transcript, his messages are unusually compact and gist-oriented, and the assistant’s replies are framed as reconstruction/checking rather than open-ended lecturing. () That style isn’t just about personality. It’s about how expertise controls the search.

An LLM is doing statistical continuation. Your domain knowledge narrows which continuations are even worth considering.

The key pattern: constraints beat cleverness

When domain knowledge drives prompting, you don’t merely request an answer—you provide constraints that act like guardrails.

Here are the constraint types domain experts tend to use, even when they don’t label them as such.

1) Invariants (what must stay true)

Invariants are properties that remain unchanged as the problem transforms.

In a math setting, invariants might be “the Jacobian determinant must be a specific constant,” or “a constructed object must satisfy a defining equation.” () In software, invariants look like “this API must remain backward compatible,” “this refactor must not change output formatting,” or “time complexity can’t blow up.”

When you prompt with invariants, you’re not asking the model to guess correctness. You’re asking it to satisfy requirements.

2) Coordinate choices and representations

Experts often know that the same idea can be expressed in multiple coordinate systems (different ways of describing the same underlying structure).

In Tao’s transcript, you can see the emphasis on reading the mathematics first and building the conversation around a precise representation (including coordinate systems and how data updates when parameters change). ()

That’s the same principle you can use in code: the model is more useful when you tell it which representation matters—input/output contracts, data schemas, or invariants expressed in types.

3) Sanity checks (what should look weird)

A surprisingly expert move is to ask for verification signals.

Not “do you think this is right?” but “what would you expect to be wrong here?” or “what output patterns would contradict the hypothesis?”

The Jacobian conjecture has a long paper trail where “it seems plausible” is never enough. In fact, the counterexample and its properties weren’t left as vibes: there’s documented formal verification work, and the verification targets specific mathematical claims like the Jacobian determinant being identically a particular constant and demonstrating non-injectivity via coinciding images of distinct points. (isa-afp.org) That’s verification culture.

You can import that culture into everyday prompting by demanding checks the model can perform (unit tests, property-based tests, dimensional analysis, type-level constraints, invariants).

What “expert prompting” looks like in practice

Let’s translate the idea into a workflow that works for beginners.

Step 1: Write the target as a contract

A contract is a precise statement of inputs, outputs, and constraints.

For example, instead of “fix this function,” a contract might read:

• Input: List[int] named xs
• Output: bool named is_valid
• Constraint: must return False if any element is negative
• Must: run in O(n)

An LLM can generate code either way. But contracts make it generate code that respects the shape you already know is correct.

Step 2: Tell the model how correctness will be judged

Correctness criteria are how you measure whether the answer works.

Examples:

• “Provide a minimal failing test case if your reasoning is unsure.”
• “State which invariant(s) the solution satisfies.”
• “Add a property-based test that would catch off-by-one errors.”

This turns prompting into engineering: you’re defining an evaluation harness.

Step 3: Iterate by diagnosing likely failure modes

Domain experts don’t iterate randomly.

They iterate by eliminating the most plausible mistakes.

In programming, that might mean you keep seeing boundary errors and so you force the model to reason about empty lists, single-element lists, and max/min indices. In math, it might mean you know which algebraic steps tend to break assumptions, so you request the model to re-derive those steps from scratch.

Tao’s interaction shows a version of this: rather than accepting the model’s next-step suggestions, he pushes for reconstruction, checks structure, and flags when something “looks more complex than hoped.” ()

That’s domain knowledge acting like a radar system.

Domain knowledge also changes what you ask for

There’s another subtle effect.

A model can produce an answer that’s fluent but wrong in structure. Domain knowledge lets you recognize structure problems quickly.

In prompting terms, that means you stop treating every output as equally valuable. You start asking for:

• alternative formulations that match known methods
• simplifications that preserve invariants
• explicit mapping between the proposed solution and the domain’s “usual” variables

For beginners, this can feel intimidating at first. It’s not. It’s learnable.

The trick is to build domain intuition in small loops: learn how correct solutions look, then use prompting to accelerate the search toward that shape.

Why the human stays the bottleneck

Even as models get stronger, there’s a stubborn bottleneck: describing the exact solution you want.

In other words, the hard part is communicating constraints and judgment criteria—the information “in the model” is abundant, but the information about your specific target is not something a generic model can invent.

The Jacobian story is extreme, but the lesson generalizes: expertise makes prompting more than a question-answering button. It turns prompting into controlled problem-solving.

And that’s the real reason LLMs reward expertise: domain knowledge isn’t decoration. It’s the steering wheel.

Closing thought

LLMs make everyone feel like a generalist, because “sort-of-okay” output becomes widely available. But the jump from output to correct, useful output depends on expertise. The more you understand the domain, the better you can (1) specify constraints, (2) demand verification, and (3) recognize when an answer is drifting into plausible-sounding wrongness.

That’s what “LLMs reward expertise” really means: the model can generate language fast, but your domain judgment decides what counts as a solution.