LLMs Reward Expertise. Expertise Also Breaks LLM Prompting. Both Things Are True.

The Expertise Paradox: Why Being Really Good at Something Makes You Worse at Using LLMs for It

Sean Goedecke published a piece today that hit 1,100 points on Hacker News within hours: LLMs reward expertise. His core claim is correct. Terence Tao’s conversation with ChatGPT about the Jacobian Conjecture looks nothing like mine. His prompts are terse and surgical. The model responds in kind, skipping the patronizing preamble, producing dense mathematical notation instead of Wikipedia-level explanation. The gap between what Tao gets from a model and what I get is not a model capability gap. It is a Tao capability gap.

But Goedecke’s framing misses the more interesting and more dangerous phenomenon that emerges when expertise meets LLMs. He describes expertise as an amplifier. It is. It is also, under specific conditions I have watched play out repeatedly on real engineering teams, a suppressor. The same depth of knowledge that lets you steer a model with precision can lock you into a steering direction that is simply wrong. Novices sometimes ship faster not because they are lucky but because they have not yet accumulated the wrong priors.

This is not a contradiction of Goedecke’s thesis. It is the part he left out, and I think it is the more actionable half.

To put a sharper point on it: the benefit of expertise in LLM prompting is real and documented. The cost of expertise is underreported because it is invisible. You do not see the better solution that the expert’s prompt closed off. You see the solution that was produced, which is usually competent. The cost only appears when you compare it against a counterfactual you never ran. I have been making a deliberate effort to run those counterfactuals over the past year, and what I found changed how I work.

What Expertise Actually Does to Your Prompting

When I write a prompt in a domain I know deeply, I do three things automatically that a novice cannot do. I constrain the solution space in ways that the model treats as authoritative. I recognize immediately when the model’s output is wrong. I ask follow-up questions that steer toward the class of solution I know is correct. These are advantages, and they are real.

But watch what happens in practice. I am working on a distributed systems problem: a message queue is causing downstream backpressure under specific load patterns. I have seen this exact failure mode three times in ten years. I know that the answer involves either bounded queues with backpressure signals or a circuit breaker at the producer side. I prompt the model with my understanding already half-formed, steering it toward one of those two solutions.

The model, completely unconstrained by my priors, would have immediately asked: what is the actual arrival rate distribution? Is the downstream consumer I/O-bound or CPU-bound? Have you considered that the queue itself might not be the bottleneck but rather a symptom of a missing flow control mechanism three layers up?

I never let it ask those questions because I already “knew” the answer. My expertise closed off the solution space prematurely. A junior engineer, handed the same problem and the same model, would have accepted the model’s exploratory questioning and discovered the actual root cause in the ingestion pipeline, not the queue at all.

I have watched this happen too many times to dismiss as anecdote. The expert comes in with a diagnosis. The model becomes a tool to implement the diagnosis rather than a collaborator to challenge it. The novice comes in with no diagnosis and lets the model ask. Sometimes the novice ships the right thing first.

The Three Failure Modes of Expert Prompting

I want to be specific because vague warnings about expertise being double-edged are useless. There are three failure modes I have observed repeatedly, and they have names now in my head because I have had to debug my own prompting habits after recognizing I was in them.

Vocabulary Lock-In

Experts communicate in domain-specific vocabulary. This is efficient among humans who share the vocabulary. With models, it creates a subtle problem: the model interprets your vocabulary choice as a signal about the solution space you want to operate in, even when a better solution exists outside that vocabulary.

I spent three days prompting models about “distributed tracing integration” for a particular service mesh issue. The model kept returning solutions in the OpenTelemetry idiom because that is where “distributed tracing” maps in the training data. The actual solution was to change how health check endpoints were being interpreted by the load balancer, which is not a distributed tracing concern at all. A non-expert, describing the symptom rather than the hypothesized cause, would have said “requests are failing sometimes but the service looks healthy” and the model would have surfaced the load balancer hypothesis immediately.

My vocabulary encoded my wrong hypothesis. The model respected it.

The Override Reflex

Goedecke cites Tao pushing back when model responses look wrong. This is a feature when you are right and the model is wrong. It becomes a bug when the model is actually right and you are wrong but your expertise makes you confident enough to override.

I had a debate with a model about memory allocation patterns in a Rust application that was exhibiting unexpected latency spikes. The model suggested the latency was caused by allocator fragmentation under specific concurrent access patterns and recommended switching to jemalloc with specific arena configuration. I overrode this because I knew this codebase had already been through an allocator evaluation eighteen months ago and jemalloc had not materially helped then. I spent two days on other hypotheses. The model was right. The workload had changed enough that the original allocator evaluation was no longer valid, and the model was picking up on a pattern in the code I had shown it that I was not reading correctly because I was filtering it through eighteen-month-old knowledge.

Expertise gave me the confidence to dismiss the correct answer. The novice on my team, who had no context about the eighteen months ago decision, had flagged the model’s suggestion to me as “worth trying.” I overrode that too.

Completeness Anxiety

Experts know how many edge cases exist. This is valuable for code review. It is sometimes actively harmful for initial implementation with an LLM. When I prompt for a solution, I front-load all the constraints I know matter: the concurrency requirements, the failure modes, the performance envelope, the operational concerns. The model produces something technically comprehensive but structurally over-engineered for the actual problem at hand.

The novice prompts for the simple case. The model produces the simple case. The simple case works. The edge cases that the expert was pre-solving for never actually occur in production, or they occur in a form that is nothing like what was anticipated, or they are easy to handle as one-off fixes when they emerge rather than requiring the infrastructure that was pre-built.

I am not arguing that experts should ignore edge cases. I am arguing that expert awareness of edge cases, when front-loaded into prompts, causes models to produce solutions that are expensive to maintain and understand for a problem that did not need that solution. The expert’s completeness anxiety is a real cost.

The Evidence From Actual Teams

Let me get concrete about what I have seen rather than continuing to speak in generalized patterns.

Over the past year, I have worked on or observed four different engineering teams in different stages of LLM adoption. Two were senior-heavy (median experience eight-plus years). Two were junior-heavy (median experience under three years). The pattern that emerged was not what the “expertise amplifies LLM output” framing would predict.

Before presenting the data, let me be explicit about methodology and its limits. These are not controlled experiments. The codebases differ. The business pressures differ. The people differ in ways that correlate with but are not fully explained by experience. I am not arguing that this is a rigorous study. I am arguing that the pattern is consistent enough across different contexts that it should update your prior, and that the alternative hypothesis — that experts are just better at LLM-assisted work, period — should require its own evidence before you adopt it uncritically.

The greenfield junior team outperformed the legacy senior team on shipping speed by a factor of roughly two. The senior team produced more maintainable code per feature. Whether that maintenance advantage pays off depends on whether the features they shipped were the right features, and the evidence on that was mixed because the senior team’s pre-specified solutions were sometimes solving the wrong problem.

I am not drawing universal conclusions from four teams. I am saying the expertise-as-amplifier framing is incomplete in ways that will lead you to wrong decisions about how to build LLM-augmented teams.

The specific failure pattern in the senior-heavy legacy team was illuminating. The engineers were not bad at LLMs. They were highly capable people who had built the system they were working on and knew it deeply. But that depth created what I started calling “context gravity” — the pull toward explaining the existing system rather than describing the desired outcome. Their prompts were dense with implementation details about what already existed, which caused the model to optimize for compatibility with the existing design rather than questioning whether the existing design was appropriate for the new requirement. On two occasions, the model would have suggested a simpler approach involving a different architectural layer, but it never got the chance because the prompts had already implicitly committed to the existing architecture.

What Terence Tao Is Actually Doing (And Why You Probably Cannot Copy It)

Goedecke’s Tao example is the centerpiece of his argument, and it is a good example. But I think the lesson he draws from it is subtly wrong, and the correct lesson is harder to act on.

Tao is not an expert who happens to be good at prompting. Tao is, by any reasonable measure, one of the best mathematical minds alive. What he is doing in that conversation is not deploying expertise in a domain. He is operating at the absolute frontier of that domain, where his own intuitions are pushing the boundary of what is known. The model is meeting him at that frontier because the frontier is precisely where the model’s training has the most interesting structure — there is a lot of mathematical literature about the approaches near the conjecture, and the model can explore that structure with someone who knows which parts of it to trust.

Most of us are not Tao. Most of us are operating well inside the frontier of our domains. In that interior, the model has seen thousands of similar problems and hundreds of solutions, and it does not need us to steer it the way Tao steers it through unexplored mathematical territory. What the model needs from us in the interior is not expertise in the domain. It is expertise in problem statement — which is a different skill.

Problem statement expertise means knowing how to describe what you actually want, separate from the implementation hypothesis you have already formed. It means resisting the urge to tell the model how to solve it before it has had a chance to understand what you need solved. It means describing symptoms rather than diagnoses, outcomes rather than mechanisms.

This is a skill that experienced engineers are often worse at than inexperienced engineers, because experienced engineers have been trained by decades of work to communicate in implementation language rather than outcome language. When you are working with a team of engineers who share your context, implementation language is efficient. When you are working with a model that has no shared context but an enormous amount of pattern knowledge, implementation language can be the worst way to communicate.

The Right Mental Model: LLMs as Smart Interns Who Have Read Everything

I have found it useful to think about LLMs as extraordinarily well-read interns who have read every relevant textbook, blog post, paper, and Stack Overflow thread, but have no experience with your specific codebase, your specific team dynamics, or your specific operational constraints. This mental model changes what you ask them and how you ask it.

There is a better version of this mental model that I have been refining. The intern has not just read everything in your field. The intern has read everything in adjacent fields too, and has no particular loyalty to the classifications that have organized your professional identity. When you say “I am a backend engineer and this is a backend problem,” the intern does not know why that boundary matters. They might suggest a solution that is technically in “frontend land” but solves the actual problem better. Your classification of the problem as a backend problem was an encoding of your professional self-conception, not a description of the real constraint. The model does not share your self-conception. This is an advantage the expert routinely squanders by front-loading their professional identity into the prompt.

I have done this. I have written prompts that start with “as a systems engineer” or “from a performance perspective” and watched the model dutifully stay inside those constraints when the problem actually wanted to escape them. The intern I was imagining was too respectful of my stated professional domain. The better intern would have said: “have you considered that this might not be a systems performance problem?” I never gave the model the opening to say that because I had already asserted what kind of problem this was.

When I hire a smart intern who has read everything, I do not lead with my implementation hypothesis. I describe the situation: what is supposed to happen, what is actually happening, what I have already ruled out, and what constraints I cannot change. I let them bring their pattern recognition to the problem before I constrain it with mine. I push back when their suggestions ignore constraints I know are real, but I try to distinguish between real constraints and hypothesis-encoded constraints.

What I do not do — what expert engineers tend to do — is give the intern a solution and ask them to implement it. This is using an intelligent entity as a code generator. Sometimes that is exactly what you need. But if you are treating every LLM interaction as a code generation task, you are leaving most of the value on the table.

The experts who are getting the most from LLMs, in my observation, have learned a second kind of expertise: the expertise of stepping back from their own expertise. This sounds paradoxical. It is also genuinely hard to do, and harder the more domain experience you have accumulated.

The Counter-Argument I Expect

Goedecke would probably say that the failure modes I am describing are failures of prompting skill, not failures of expertise itself. The expert who over-specifies is not being hurt by their expertise; they are being hurt by their failure to apply expertise at the right level of abstraction. Tao does not over-specify. He knows when to be precise and when to be vague. That calibration is itself a form of expertise.

This is a fair point, and it is partially right. But it proves too much. If the skill that matters is knowing when to constrain and when to let the model explore, then what we are really saying is that the highest-value skill for LLM prompting is meta-cognitive: it is not expertise in the domain, but expertise in your own expertise — knowing where your knowledge is reliable and where it is hypothesis. That is a skill that is orthogonal to domain expertise and often inversely correlated with it. The most expert practitioners in any field are often the worst at knowing which parts of their knowledge are solid and which are folk wisdom accumulated over decades of successful practice in conditions that no longer apply.

I have watched senior engineers confidently rule out the correct answer because it violated a principle they had internalized years ago in a different context. The principle was sound in the original context. The context had changed. Their expertise was not calibrated to detect that shift.

A Practical Framework for Navigating This

Given all of this, what should you actually do? Here is what I have developed after a year of watching this play out. None of this is complicated, but that does not mean it is easy. Changing how you communicate requires noticing habits that have been automatic for years, and expertise-driven prompting habits are deeply automatic precisely because they were formed during years of successful communication with human engineers who rewarded that style of communication.

Separate diagnosis from implementation when prompting

Make it a rule: describe what is broken before you describe what you think is wrong. Even if you have a strong hypothesis, lead with symptoms. Give the model a chance to generate its own hypothesis before you present yours. Sometimes its hypothesis will be wrong and you will correctly dismiss it using your expertise. Sometimes its hypothesis will be right and you will have saved yourself from implementing the wrong solution correctly.

Use expertise for verification, not initialization

Your deep domain knowledge is most valuable at the review stage, not the prompt stage. Let the model generate a solution space. Apply your expertise to evaluate whether the outputs make sense given constraints the model cannot know. This is a different workflow than most expert engineers default to, where the expertise shapes the prompt and the model just fills in syntax.

Distinguish between real constraints and encoded hypotheses

Before adding a constraint to a prompt (“and it must use approach X because of reason Y”), ask yourself whether reason Y is a real constraint or a hypothesis. If it is a hypothesis, remove it from the constraint and move it to context. “Here is what I think is happening, but I want you to evaluate this independently” is more productive than baking your hypothesis into the constraint set.

Track your override rate

If you find yourself overriding the model’s suggestions more than half the time, that is a signal. Sometimes it means you are an expert working at the frontier where the model genuinely needs your steering. More often it means you are pre-diagnosing in your prompts and then correcting toward your original diagnosis when the model tries to explore. Audit a week of your prompting. Count how often your overrides led to the right outcome versus how often you later discovered the model’s suggestion would have been faster or better.

Build in an explicit exploration step

Before you write the implementation prompt, write a diagnostic prompt. Ask the model: given this symptom, what are the five most likely causes, and what would you check first? Do not include your hypothesis in this prompt. Read the response. If your hypothesis is in the list, note where it ranks. If it is not in the list, you have learned something important before you spent any time implementing it. This single habit — separating exploration from implementation — would have saved me weeks of work over the past two years. It is also the hardest habit to maintain when you have strong prior confidence, which is exactly when it matters most.

Where Goedecke Is Right

I want to be clear that the core empirical claim in Goedecke’s piece is correct. If you have no domain knowledge and I have deep domain knowledge, and we both prompt the same model on the same problem in my area of expertise, I will get substantially better results on average. The Tao example is not cherry-picked; it generalizes. Expertise really does unlock a kind of model output that novices cannot access, and this has significant implications for how we should think about the future of knowledge work.

The implication that most people draw from this — that expertise becomes more valuable as models improve — is also directionally right. The people who can tell whether a model’s output is good are more valuable in a world where models are producing more output. Quality verification requires judgment that models do not have about their own outputs. Deep practitioners will provide that judgment better than superficial practitioners.

Where I part from Goedecke is in the mechanism. He frames expertise as an amplifier of LLM capability. I think the more accurate framing is that expertise is an amplifier of LLM output given a correct problem formulation. The problem formulation step is where expertise is simultaneously most powerful and most dangerous. Getting the formulation right requires the expert to hold their own knowledge loosely — to be willing to let the model question the framing before the expert has locked it in. That is hard. It gets harder as expertise deepens.

The engineers who are doing this best in 2026 are not the deepest experts or the most experienced. They are the people who have learned to productively doubt their own diagnoses, which is a skill that has always been valuable and has now become the highest-leverage capability in the room.

What This Predicts

If the framing here is correct, we should expect to see specific patterns emerge over the next two to three years that we can use to evaluate the argument:

Senior engineers with fifteen-plus years in a specific domain will show smaller productivity gains from LLMs than early-career engineers in the same domain, unless they have explicitly trained themselves on the meta-cognitive habits described above. The gap will be most visible in product velocity and least visible in code quality per review cycle.

Teams that adopt explicit prompting protocols separating symptom description from hypothesis specification will outperform teams that let engineers prompt in their natural idiom. The protocol overhead is real but it catches more of the expertise-as-suppressor failure modes.

The most dangerous period for an individual engineer is roughly five to ten years into a specialization, when they have accumulated enough expertise to be confident but have not yet accumulated the meta-cognitive habits that come from watching their own confident hypotheses fail enough times. Two-year engineers do not have strong enough hypotheses to over-encode them. Twenty-year engineers have usually seen their hypotheses fail enough to hold them more loosely. The five-to-ten-year zone is where expertise is most likely to become a liability in LLM-augmented work.

Organizations that deliberately mix experience levels on LLM-assisted projects will see better outcomes than those that segregate by seniority. The junior engineer’s willingness to let the model explore combines productively with the senior engineer’s ability to verify, in a way that pure-senior teams cannot replicate just by trying to be more open-minded.

I will be watching for these patterns over the next year, and I expect the data to be noisy enough that motivated disagreers will be able to find counter-examples easily. But I think the directional prediction is right, and I think organizations that act on it now will have a real advantage over those that treat expertise as straightforwardly additive to LLM capability.

The expertise paradox is real. Learning to navigate it is the most important meta-skill in the current moment of software development. The engineers who figure this out in 2026 will be the ones who look back in five years and understand why some high-expertise teams got left behind by teams with less experience but more intellectual flexibility. Goedecke’s piece is worth reading. This paragraph is the part it does not include.