The most common complaint about large language models is that they reward the wrong skills. Anyone can type a prompt, the argument goes, so the models flatten expertise into a commodity. Software engineer Sean Goedecke makes the opposite case in a new essay: LLMs reward expertise, not prompting fluency, and the gap between what an expert and a novice can extract from the same model is widening, not narrowing.

Goedecke’s central evidence is Terence Tao’s now-famous conversation with ChatGPT about a recently discovered counterexample to the Jacobian Conjecture. Tao, a Fields Medalist at UCLA, used the model to explore a genuine open problem in mathematics. Goedecke’s point is blunt: “This is not the same ChatGPT I talk to! I couldn’t get to where Tao gets, even with unlimited tokens to burn.”

That observation matters because it cuts against the dominant narrative of the last two years. The pitch from OpenAI, Anthropic, and Google has been that frontier models make expertise accessible to everyone. Ask for PhD-level mathematics, competent code, or serviceable prose, and you get it. The models are the same for everyone, so the skill must be in the asking. Goedecke argues this is backwards. The skill is in the knowing.

Look at how Tao actually interacts with the model. His messages are short and to the point. He does not respond point-by-point to the model’s output; he responds to the gist. He pushes back when responses look wrong, but he does not directly contradict. Instead, he says things like “this looks more complex than I was hoping for.” He makes leaps and suggests his own directions, almost never taking the model’s advice about where to go next.

None of that works without mathematical fluency. The tricks are downstream of the knowledge. Tao can pull the relevant idea out of a multi-paragraph response because he already knows what the relevant idea looks like. He can suggest alternate formulations because he has a mental map of the problem space. He can identify what “looks weird” because he has spent decades developing a sense for what mathematical arguments should feel like. A novice following the same conversational pattern would produce gibberish.

Goedecke’s own experience as an engineer at GitHub confirms the pattern outside elite mathematics. With a good theory of your codebase, you can push an LLM much harder. You can say “no, I think it could be simpler here,” or “but don’t we already do X?”, or “can we express this problem in these familiar terms?” Those interventions require a working model of the system, not just a general understanding of software. Goedecke notes that system design problems are dominated by concrete specifics, not generic principles. Familiarity with the codebase beats a deep abstract understanding of software systems.

There is a mechanistic explanation for why this works, and it is worth making explicit. LLMs are next-token predictors trained on human text. The distribution they learned includes different registers: explaining-to-amateurs and talking-to-experts. When Tao signals expertise through his phrasing and specificity, he shunts the model into the second register. The outputs get more concise, more technical, more useful to someone who can already do the work. The model is not doing more computation for Tao. It is retrieving a different slice of its training distribution, one that is far more information-dense.

This reframes what the human bottleneck actually is. Goedecke’s claim: for many tasks, the human is the bottleneck, not the model. The information is “in the model” already, but extracting it requires a human who knows what they are looking for. The model is a library where every book is indexed by a librarian who only responds to precise queries. The generalist gets a summary. The expert gets the primary source.

The implications for AI builders are uncomfortable, because they invert the current product logic. The industry has spent enormous resources making models more capable and more accessible, on the theory that capability plus accessibility equals value. If Goedecke is right, accessibility is the easy part. The hard part is the human on the other side of the conversation. A model that can do PhD-level mathematics is only as useful as the PhD who knows how to interrogate it.

This has consequences for how we think about evaluation and benchmarking. Standard benchmarks measure what a model can do in isolation. They do not measure what a human can extract from a model, which is the actual economic activity. Two users with identical API access to the same model can produce wildly different results, not because of prompt engineering, but because of what they bring to the conversation. The variance is in the user, not the system.

There is a real risk of motivated reasoning here, and Goedecke acknowledges it. The essay’s edit notes that Hacker News commenters expressed “a sensible suspicion of a view that’s reassuring them about how they’re still valuable.” That suspicion is warranted. It is flattering to believe that expertise still matters in an age of generalist models. But the Tao example is hard to explain away. OpenAI’s own math prompts were inexpert, Goedecke notes, and the company had to deploy a team of expert mathematicians to check and filter the model’s suggested discoveries. You cannot currently skip that step.

The honest version of this argument is not that LLMs will never displace expertise. It is that they displace the wrong kind of expertise first. The generalist who could write sort-of-okay CSS in the 2010s by searching the internet is now redundant. The specialist who could hold a complex system in their head is more valuable than ever, because they can direct a model to produce work that looks like their own. The model amplifies the expert. It does not replace them.

Goedecke’s essay ends with a prediction that the landscape will change again before researchers formally study this effect. That is probably right. But the direction of change is not obvious. If models get better at reading intent, the expertise premium may shrink. If they get better at generating multiple candidate solutions, the expert’s ability to select and refine becomes more valuable. The one constant is that the human side of the equation remains the least understood and least optimized part of the stack.

The practical takeaway for builders is to stop treating prompting as a skill to be learned and start treating domain knowledge as the asset to be cultivated. The person who knows the codebase, the math, the regulatory regime, or the clinical workflow will get more from the same model than the person who has memorized every prompting pattern in the literature. Invest in the humans who know things, not the ones who know how to ask.