LLMs reward expertise. The democratization narrative crumbles.

Are you the person on your team who gets the most out of AI tools, and you have quietly noticed that your less experienced colleagues are not getting anywhere close to the same results, even though they are using the same model?

That observation is not a fluke, and it is not about prompt engineering tricks. A recent analysis by Sean Goedecke, published and discussed on Hacker News, argues that LLMs systematically return better outputs for people who already know the domain they are asking about. The implication undermines one of the most repeated claims in the AI industry: that these tools democratize access to expert-level work.

Why expertise compounds instead of equalizing

The standard pitch for LLMs is additive. A junior developer gets senior-level code suggestions. A first-time founder gets legal summaries that used to require a lawyer. The gap between novice and expert narrows because the model fills it in. That story is intuitive, it is well-funded, and it is largely wrong about where the real gains concentrate.

Here is the mechanism the headline version misses. When an expert asks an LLM a question, they already know enough to recognize a bad answer. They can spot when a model has hallucinated a function that does not exist in the library, when a legal summary has omitted a key exception, when a medical explanation has described the common case but not the relevant edge case for their patient. The novice cannot do any of that. They receive the output, it sounds authoritative, and they move forward on wrong information.

There is a second mechanism on top of that. Experts ask better questions. Not because they have memorized prompting frameworks, but because domain knowledge shapes what you know to ask. A senior engineer asking about a database query problem can specify the index type, the approximate row count, the query planner behavior they observed. A junior engineer says "my query is slow." The model gives both an answer, but one answer is calibrated to the actual problem and one is a generic suggestion that may or may not apply.

The third mechanism is iteration. Experts know when to push back. They say "that answer assumes X, but in my case Y is true, reconsider." Novices tend to accept the first confident-sounding response. The LLM is not smarter for the expert; it is just being used as an interactive tool rather than an oracle. That distinction produces radically different outputs over a session.

The counterargument: novice gains are real, even if unequal

Before accepting the expertise-concentration thesis entirely, the skeptical position deserves a full hearing. And the skeptical position is stronger than the framing above suggests.

A novice using Claude or ChatGPT to write their first Python script is not just getting a slightly worse version of what an expert gets. They are getting something they could not have gotten at all without either six months of learning or paying a contractor. The absolute value of that output is positive. The argument that "experts benefit more" is a relative claim. It does not mean the novice is worse off than before LLMs existed.

There is also a category of tasks where expertise is irrelevant or actively unhelpful. Summarizing a long document, reformatting data between schemas, generating first-draft copy for a product nobody on the team has sold before. These are not tasks where domain knowledge dramatically reshapes the quality of what you ask or what you can evaluate. The model's output is roughly as useful for the expert as for the novice, and in some cases the novice benefits more because the expert would have done it themselves anyway.

The democratization claim is weakest for complex, high-stakes professional work: legal advice, medical diagnosis, production code in unfamiliar systems. It is strongest for breadth tasks, tasks where you need a competent first draft across a domain you will only visit once. A solo founder writing their first privacy policy, a designer writing API documentation, a small business owner drafting an employment contract template. Those users are getting real value from AI tools, not because the model is perfect but because the baseline they are comparing to is doing nothing or hiring someone.

The failure mode nobody is measuring

The real problem is not that novices get less value. It is that novices get confidently wrong answers and cannot identify them as wrong. This failure mode is well-documented in AI safety research but underrepresented in the product conversation around LLMs.

Consider what happens when a developer with six months of experience uses an AI coding tool like Cursor or GitHub Copilot to build a feature involving authentication. The model will produce plausible, syntactically correct code. It will look like it works. The novice developer will test the happy path, it will pass, and they will ship it. A senior engineer reviewing it three weeks later during an incident might find that the token expiry logic is missing, or that the session invalidation call is in the wrong order, or that a deprecated library was used that has a known CVE. None of these failures are visible to the person who shipped the code. They looked like working code to someone without the context to know what working auth code actually requires.

This pattern recurs across domains. A junior marketer using an AI writing tool to draft a campaign gets copy that sounds like marketing but may have inadvertently made a claim the product cannot support. A first-time founder using AI to summarize a term sheet gets a summary that correctly identifies the headline numbers but misses the pro-rata rights clause that will matter in two years. The model does not flag these omissions. It does not know what the user does not know to ask about.

The gap between LLM hype and practical reality shows up most clearly here: the tool's confidence is uniform across outputs that vary widely in quality. A hallucinated detail and a correct detail are presented with identical tone. Expertise is the filter. Without it, you are not evaluating outputs; you are just publishing them.

Steps to audit whether your team is actually benefiting from AI tools

1. Pick one high-volume AI task your team does regularly. Writing code for a specific system, drafting client-facing copy, summarizing research. Make it concrete and repeatable.
2. Have two people with different experience levels complete the same task independently using the same AI tool. Do not tell them you are comparing outputs.
3. Have the most senior person on the team review both outputs blind, without knowing who produced which. Ask them to identify errors, omissions, or things they would change before using the output in production.
4. Count the number of issues found in each output. You are not grading the people; you are measuring how much domain knowledge is acting as a filter on the model's output.
5. For any issues found in the novice's output, trace back whether the model actually produced the error or whether the human accepted an error the model made. Run the same prompt again and see if the model can correct the issue when the right context is added to the question.
6. Verification test: take the prompt from the novice's session and add three pieces of domain context the senior engineer would have included naturally. If the output quality improves materially, you have confirmed the feedback loop. The model was not failing; the question was failing.

Watch a junior team member use AI on a real task without coaching them

Find the most junior person on your team who uses AI tools daily. Sit with them for thirty minutes and watch them use the tool on a real task, without coaching them. Do not help. Just observe what questions they ask, what outputs they accept without pushback, and what they do with those outputs downstream. What you will likely find is not that they are using the tool wrong. It is that they do not know what a wrong answer looks like. That is the actual problem, and no amount of better prompting tutorials solves it. The solution is either pairing them with someone who can evaluate the output, or being honest that the tool's ROI on their work is lower than your adoption metrics suggest.

If you are evaluating which AI assistant to put in front of a less experienced team, the Claude vs Perplexity comparison covers how each handles uncertainty differently, which matters a lot when the user cannot independently verify the answer. And if you are already running AI-assisted coding workflows, the post on how LLM-generated code handles CVEs is a useful concrete case of what undetected failure looks like in practice.