Why do AI coding assistants keep suggesting the same few libraries?

Because the models lean on what shows up most in their training data, which means popularity and familiarity, not fit for the task. Research that gave models hundreds of coding tasks found each one reached for only a few dozen distinct libraries, even though thousands of well-used libraries exist. The model reaches for the name it has seen the most, so a handful of incumbents soak up the recommendations.

Can a company pay to be the library an AI recommends?

No. There is no ad slot inside a model's weights and no way to buy your way into a training run. The model learned its preferences from public text and code that existed before it was trained. You influence those preferences the slow way, by being present and correct in the places models read: real repositories, documentation, and reference examples that developers actually use and copy.

What is package hallucination and why should marketers care?

Package hallucination is when an AI confidently recommends installing a software package that does not exist. Security researchers studying hundreds of thousands of code samples found models inventing package names that no registry carries. Marketers should care because attackers can register those fake names, and because the same machinery that invents a package can mislabel or skip a real one. Consistent naming and presence reduce the odds your tool gets confused for something else.

Do developers actually follow what the AI suggests?

Most do, often without checking. Surveys put AI adoption among developers in the mid-eighties as a share who use or plan to use these tools, and a large chunk use them every day. Trust runs lower than usage, so developers often accept the default suggestion even when they are skeptical of it, which is exactly why the default matters so much.

Are newer AI models fixing the popularity bias?

Only partly. Made-up packages are getting rarer as models improve, but the popularity-default behavior has not gone away. Better models still reach for the well-known library over the better-fit one, so the marketing problem stays the same even as the reliability improves.

How to become the library the AI recommends

A developer opens their editor, types a comment describing what they want, and presses tab. The AI writes ten lines of code and picks a library to do the work. The developer doesn't weigh five options. They don't read a comparison post. They accept what the model handed them and move on.

That moment is the new buying decision for developer tools. And the model already made it.

Here's the uncomfortable part for anyone who markets to developers. The AI doesn't pick the best library. It picks the one it knows best. Those aren't the same thing, and the gap between them is where your job now lives.

The research is blunt about this

A team of software engineering researchers, including Mark Harman and Don Syme, the creator of F#, ran a study published in the Findings of ACL 2026. They gave large language models hundreds of programming tasks and watched which libraries the models reached for.

The models prioritized familiarity and popularity over fit, and they did it consistently, across every model the team tested. They leaned on NumPy even in tasks where it wasn't the right tool, and across the study the library a model picked diverged from the best-fit choice in up to 45 percent of cases. Each model used only 32 to 39 distinct libraries across hundreds of tasks, even though thousands of well-used libraries were available. Rust was never selected once.

So sit with the scale of it. Thousands of viable libraries exist, and the models use a few dozen. If your library isn't in that small set, the AI isn't weighing your tradeoffs and deciding against you. It isn't thinking about you at all.

Why this is winner-take-all

Developer tools have always had a popularity flywheel. The tool everyone uses has the most tutorials, the most Stack Overflow answers, the most plugins, so it picks up the next developer too. That flywheel was real but slow, and a better tool could break in by being clearly better.

AI coding agents speed the flywheel up and add a gatekeeper. The model trains on public code and text, sees the incumbent everywhere, and then recommends the incumbent to millions of developers who accept the suggestion. Those developers write more code using the incumbent. That code becomes training data for the next model. The incumbent gets recommended even more.

The scale here isn't small. Most developers now use AI tools or plan to, and a big share reach for them every day. A majority of tool selection passes through a system that's biased toward whatever is already winning.

I've written before about how every AI product sounds the same and ends up invisible. This is the same problem one layer down. When the model is the one choosing, sameness isn't your only enemy. Being absent from the model's working memory is the bigger one.

You can't bribe a training run

Let me be honest about the limits before I sell you a plan, because most posts on this topic skip the honesty.

There's no ad product inside a model's weights. You can't pay OpenAI or Anthropic to make Claude prefer your library. You can't buy a placement, sponsor a token, or run a campaign that changes what the model learned. The preferences baked into a model came from text and code that existed before training started, and that training closed months before the model shipped.

So when someone sells you "LLM optimization" as a quick lever you can pull this quarter, be skeptical. The base model's taste is set. What you can change is what the next model learns, and what today's models retrieve when they search the web at query time. Both are slower than an ad buy, and both are real.

The playbook for a challenger

If the model reaches for what it's seen most, then your work is to be seen, correctly and often, in the exact places models read. Here's how a challenger actually competes.

Put working code in public. Models learn from repositories, not from your landing page. Open-source examples, starter templates, and real projects that use your library are the raw material the next model trains on. One polished example repo that a thousand developers fork does more for your model presence than a year of press releases. Write the code you want the AI to imitate.

Make your docs the canonical reference. When a model retrieves documentation at query time, it favors sources that are clear, structured, and unambiguous. Plain function names, complete examples, and consistent naming help the model connect your tool to the task it solves. I covered the mechanics of this in how startups get noticed by LLMs, and the short version holds: state your facts plainly and the model has fewer reasons to skip you.

Show up in the places models retrieve. The training corpus is locked, but live retrieval isn't. Tutorials on dev.to, answers on Stack Overflow, comparison threads on Reddit, and walkthroughs on YouTube get read by models in real time. A developer who writes an honest tutorial after your tool helped them is worth more than any ad, because that's the content models trust.

Guard your name. Security researchers have shown that models hallucinate packages that don't exist, inventing names no registry carries. Simon Willison wrote about one case where models kept recommending a package called "huggingface-cli" that wasn't real, and a researcher who registered that name as a placeholder watched it rack up about 30,000 downloads in three months. If models can invent a name near yours, claim the obvious variants, keep your naming consistent everywhere, and don't let a squatter become the thing the AI suggests instead of you.

Be the better fit and prove it in code. Better-fit doesn't win on its own, the research is clear about that. But a tool that's genuinely better and present in public code can break in, because the next model trains on that code. Those NumPy answers measured NumPy's presence, not its quality. Your job is to raise your presence until the model has seen you enough to reach for you.

The pattern is sticky, even as models improve

Newer frontier models hallucinate fewer fake packages, so the made-up names are getting rarer. But the popularity-default behavior persists. Cleaner output doesn't mean fairer output. The model still reaches for the name it's seen the most.

So the work doesn't end when the models get more reliable. Share of voice used to mean the ads developers saw and the conference talks they attended. Now it means the libraries the model carries in its head and the references it pulls when it searches. You earn that the way you've always earned a developer's trust, by writing good code, documenting it clearly, and helping people in public. The audience just changed. Some of it is a machine now, and the machine remembers what it reads.

If you want the deeper version of this argument applied to product features rather than libraries, I made the case in marketing AI features to developers. The throughline is the same across all of it. Stop optimizing for the developer's first click. Start optimizing for the model's first guess.