How AI Is Changing How Developers Choose npm 2026

TL;DR

AI coding assistants are the new Stack Overflow for package recommendations — and they have biases. In 2026, developers increasingly ask Claude, ChatGPT, or GitHub Copilot "what package should I use for X" instead of searching the web. These models have knowledge cutoffs and training biases that make them recommend established packages (React, Express, Axios) even when newer alternatives are objectively better for new projects. Understanding how AI picks packages helps you know when to trust the recommendation and when to verify it.

Key Takeaways

• 50%+ of developers use AI coding assistants as their primary package discovery tool (JetBrains survey 2025)
• Knowledge cutoff bias — models recommend packages popular at training time, not today
• Recency gap — packages that grew 5x since model training are systematically underrecommended
• The "safe default" effect — AI prefers well-documented, widely-used packages even when smaller alternatives are better
• Verification still matters — AI recommendations should be checked on npmjs.com or PkgPulse

How AI Recommends Packages

When you ask an AI "what's the best state management library for React?", it's doing pattern matching on training data:

Developer asks: "What state management should I use for React in 2026?"

AI considers:
- How many times was this library mentioned in training data?
- Was it in positive contexts (tutorials, docs) or negative (bug reports)?
- When was the training data cut off?

Result: AI recommends Redux Toolkit (highly documented, widely discussed)
        over Zustand (grew 400% after many models' training cutoffs)

Reality in 2026:
- Zustand: ~4M weekly downloads
- Redux Toolkit: ~4M weekly downloads
- For new projects: ~80% choose Zustand/Jotai over Redux Toolkit

The Knowledge Cutoff Problem

Scenario: Developer in March 2026 asks AI about HTTP clients

Model trained through: Q1 2024

Downloads at training time:        Downloads in March 2026:
- axios:        ~50M/week          - axios:        ~55M/week
- ky:           ~2M/week           - ky:           ~5M/week
- node-fetch:   ~30M/week          - native fetch:  built-in

AI recommendation: axios (correct for its training data)
Reality: native fetch (Node.js 18+) is often the right answer in 2026
         ky is a strong recommendation for fetch-compatible API + browser

Packages that grew significantly after common training cutoffs:

Library          Training-era DL    2026 DL    Change
Drizzle ORM      ~200K/week         ~2M/week   10x
Biome            ~200K/week         ~2M/week   10x
Hono             ~300K/week         ~1.5M/week 5x
Bun              N/A (runtime)      ~1M users  New
React Email      ~200K/week         ~800K/week 4x
t3-env           ~100K/week         ~400K/week 4x

These are systematically underrecommended by AI.

What AI Gets Right vs Wrong

What AI Recommends Well

✅ Established libraries with years of documentation:
   - React, Vue, Angular (frameworks)
   - Express, Fastify (servers — though misses Hono)
   - Jest, Testing Library (testing — though misses Vitest momentum)
   - Prisma (ORM — though misses Drizzle's growth)
   - TypeScript (general tooling)

✅ Widely-taught comparisons:
   - "Use Zod for validation" — well documented, in training data
   - "Use TanStack Query for data fetching" — common blog posts
   - "Use Tailwind for styling" — massive online presence

✅ Package-specific implementation help:
   AI excels at "how do I use X" once X is chosen

What AI Gets Wrong

❌ Package momentum (which is gaining, which is declining)
   - Doesn't know Express adoption dropped for new projects
   - Doesn't know TypeORM is in maintenance mode vs Drizzle growth

❌ Recent version changes
   - Next.js 15 features (after training cutoff)
   - React 19 changes (after training cutoff)
   - Breaking changes in major version bumps

❌ Community sentiment shifts
   - "Create React App is deprecated" — many models still recommend it
   - "Don't use Moment.js" — many models still suggest it

❌ Newer, high-quality alternatives
   - Biome over ESLint+Prettier (newer, less training data)
   - Drizzle over TypeORM (rapid growth, newer)
   - Hono over Express for edge (category barely existed at training)

The AI-Recommended Package Ecosystem Effect

AI recommendations are now significant enough to affect package download trends:

Observed pattern (2025-2026):
1. Developer asks AI → AI recommends Package X
2. Developer installs Package X
3. npm downloads for Package X increase
4. Future AI training data includes more mentions of Package X
5. AI recommends Package X even more

This creates winner-take-more dynamics:
- Well-documented packages with lots of tutorials get a sustained boost
- Newer packages without training data get a "discovery gap"

Practical implication for new packages (open source developers):
- Write comprehensive, AI-indexable documentation
- Publish comparison posts ("Why X vs Y")
- Submit to context windows (State of JS survey, awesome lists)
- The documentation is now also training data

The Numbers: How AI Changed Package Discovery

To understand the scope of this shift, it helps to look at how package discovery has changed since 2022. According to the JetBrains Developer Survey 2025, more than 50% of developers now use AI coding assistants as their primary way to discover new packages and libraries. That number was negligible in 2022, when the dominant discovery channels were Stack Overflow answers, GitHub trending, npm's own search, and search engine results.

The Stack Overflow traffic data tells the same story from a different angle. Stack Overflow reported a multi-year decline in new questions being asked and answered, with the steepest drop happening in 2023 and 2024 — precisely when GitHub Copilot and ChatGPT became mainstream developer tools. The "how do I do X in JavaScript" questions that used to drive developers to Stack Overflow are now being answered directly in the editor. A developer who would have searched "how to validate a form in React" and landed on a three-year-old Stack Overflow answer is now asking Copilot and getting a working code example in seconds.

This shift has measurable consequences for package discovery. Stack Overflow answers tended to surface whatever the community considered best practice at the time the answer was written, with upvotes as a quality signal. AI assistants surface whatever has the most representation in training data, with recency being invisible to the model. The practical difference is that Stack Overflow naturally evolved its recommendations as packages fell out of favor — old answers got downvoted and new answers rose. AI models are frozen at their training cutoff.

What this means for documentation quality is underappreciated. When Stack Overflow was the primary discovery channel, a mediocre README could be offset by a helpful community answer. When AI is the primary channel, the quality of the package's own documentation — the README, the API docs, the official examples — directly determines how often the AI recommends it. An excellent package with sparse documentation will be underdiscovered. A mediocre package with comprehensive, well-structured documentation will be systematically overrecommended.

The SEO implications are also real. Packages that ranked well in search results because of backlinks and domain authority now need to optimize for AI training data representation. That means publishing content in venues where AI models are trained: GitHub, official documentation sites, high-traffic developer blogs, and survey datasets like the State of JS annual survey. The discovery landscape has shifted from search-engine-optimized content to AI-training-data-optimized content, even if those two things overlap substantially.

Model-Specific Differences

Not all AI models recommend the same packages. The differences are subtle but worth understanding if you use AI tools heavily for package discovery.

Claude (Anthropic) tends to recommend more modern alternatives more readily than older models. Claude's training appears to include more recent content, and Anthropic has indicated that Claude's training process emphasizes accuracy about current best practices. In practice, Claude is more likely to mention Drizzle alongside Prisma, more likely to recommend Hono for edge deployments, and more likely to acknowledge that Create React App is deprecated. Claude also tends to explicitly acknowledge uncertainty about rapidly-evolving tooling — you'll often see phrases like "as of my training data" or "you should verify this is still current."

ChatGPT (GPT-4o and later) has become more aware of knowledge cutoff limitations and now frequently suggests web searches for questions about package versions and current best practices. OpenAI's models have historically had some of the most comprehensive training data coverage of JavaScript ecosystem content, which means they recommend established packages confidently. GPT-4o's awareness of Drizzle, Biome, and other fast-growing packages improved significantly compared to GPT-3.5-era recommendations.

GitHub Copilot operates differently from chat-based AI because it has context from the repository you're working in. If your project already uses Prisma, Copilot will recommend Prisma-compatible patterns. If your project uses pnpm workspaces, Copilot will suggest pnpm commands. This context-sensitivity makes Copilot better at package recommendations when a project context is available, but it also means Copilot rarely suggests that you switch to a better alternative — it optimizes for consistency with what's already there.

Cursor, which uses a combination of models including Claude and GPT-4o depending on settings, adds codebase indexing on top of the base model. This means Cursor's recommendations are influenced by what packages are already in your codebase, similar to Copilot. The practical difference is that Cursor users interacting with the chat interface can get more exploratory recommendations when explicitly asking about alternatives.

The general principle: for questions about very new packages (released or significantly updated in the last 12-18 months), treat all model recommendations with extra skepticism and verify against current npm download data. For questions about established packages that have been stable for years, model recommendations are more reliable.

The Training Data Flywheel: Why Well-Documented Packages Win

The connection between documentation quality and AI recommendation frequency is the most underexplored consequence of AI-first package discovery. It deserves a detailed explanation because it changes what package maintainers should prioritize.

The mechanism works like this: AI models are trained on text from across the internet. When a package has comprehensive documentation — detailed API references, multiple tutorials showing different use cases, comparison articles explaining why it's better than alternatives, integration guides for common frameworks — that documentation gets included in training data from multiple sources. The package's official docs site, developer blogs that republish the tutorials, Stack Overflow answers that reference the docs, GitHub issues that link to specific documentation pages. The package gets many independent mentions across many training data sources, which reinforces the model's confidence in recommending it.

Contrast this with a package that has excellent code quality but sparse documentation. Maybe a brief README with basic usage and then "see the source code for details." This package appears in training data mainly through its npm page, maybe some GitHub stars, but without the long tail of tutorials, comparisons, and secondary mentions that well-documented packages accumulate. The model doesn't have enough training signal to recommend it confidently.

Concrete examples illuminate the pattern. Zod became the dominant TypeScript validation library not only because of its API quality but because its documentation is exceptionally comprehensive. The Zod README is thousands of words covering every feature with examples. There are dozens of "Zod tutorial" articles across the web. The State of JS survey featured Zod prominently. When developers write about validation in TypeScript, they almost always mention Zod. All of that becomes training data.

TypeORM tells the opposite story. TypeORM has been around since 2016 and was for a long time the default choice for TypeScript database access. But as TypeORM's maintenance slowed and Drizzle ORM emerged with better TypeScript inference, the community sentiment shifted. However, the documentation advantage TypeORM accumulated over years means that many AI models still recommend it as a primary option rather than as a legacy choice — there's more TypeORM content in training data than Drizzle content, simply because TypeORM has been around longer and accrued more tutorials.

The practical implication for package authors is stark: documentation investment is now also a marketing investment. Writing a comprehensive API reference, publishing tutorial articles, creating comparison posts, and getting your package mentioned in survey datasets directly affects how often AI recommends you. This is a new kind of compounding advantage — good documentation creates more tutorials, tutorials create more training data, training data creates more recommendations, recommendations create more users, users create more tutorials.

RAG and Context Windows: How AI Package Recommendations Are Improving

The knowledge cutoff problem is real, but it's not static. AI tooling is actively improving its ability to provide current package recommendations through retrieval-augmented generation and larger context windows.

GitHub Copilot now includes workspace-aware context as a standard feature. When you ask about packages in a project context, Copilot reads your package.json, lock files, and even your existing code to inform its recommendations. This RAG-style approach means Copilot is less likely to recommend packages that conflict with your existing stack and more likely to suggest packages that are known to work with what you already have. The limitation is that this context helps Copilot be consistent with your existing choices but doesn't help it know about packages that postdate its training.

Web search augmentation is becoming more common in AI tooling. Claude, when used through Claude.ai or certain API integrations, can perform web searches to supplement its training data. When asked about current package recommendations, Claude with web search enabled will pull current npm download data and recent discussions before responding. This addresses the knowledge cutoff problem partially — the model can find information about new packages that it wasn't trained on.

Real-time npm data integration is the next frontier. A few AI tools are beginning to integrate with npm's API directly to pull current download counts, last-publish dates, and maintainer activity before making recommendations. PkgPulse's health score data is exactly the kind of real-time signal that addresses AI's blind spots — current download trends, maintenance activity, TypeScript support status, and community health metrics that no static training dataset can capture.

The gaps that remain are at the application logic level. Even with web search and real-time data, AI models are still doing final synthesis based on their training. They can look up that Drizzle has 2M weekly downloads, but they're interpreting that number through a lens of knowledge about the JavaScript ecosystem that was shaped by their training data. The structural biases toward well-documented, established packages don't disappear entirely with RAG.

A Practical AI-First Package Selection Workflow

Integrating AI into package selection intelligently means using it for what it's good at and supplementing it with real-time data where it falls short. Here is a complete workflow that combines AI recommendations with verification.

Step 1: Get the Recommendation

User: "What should I use for form validation in a React TypeScript app in 2026?"
AI:   "React Hook Form with Zod resolver. RHF handles form state, Zod handles schema validation..."

Step 2: Verify It's Current

# Quick verification workflow:
# 1. Check npm trends: npmtrends.com/react-hook-form
# 2. Check PkgPulse health score: pkgpulse.com/compare/react-hook-form-vs-formik
# 3. Check GitHub: last commit, open issues, Stars
# 4. Check package.json: "types" field? (TypeScript-first?)

# For react-hook-form specifically:
# ✅ High health score
# ✅ Recent releases
# ✅ Growing downloads
# ✅ TypeScript-first
# → AI recommendation is good

Step 3: Check Alternatives

"What are the alternatives to [AI's recommendation]?"

This forces the AI to surface options it might not have led with.
Often reveals newer alternatives the AI knows about but didn't prioritize.

Example:
Q: "What alternatives exist to Prisma for TypeScript database access?"
A: "Drizzle ORM is a newer alternative that's gained significant adoption..."
   [Now you know about Drizzle even though AI led with Prisma]

Step 4: Validate Against Current Data

Use a live data source — npm trends, PkgPulse, or GitHub trending — to confirm:

AI said: "Prisma is the most popular TypeScript ORM"
Verification (March 2026):
  Prisma: 5M weekly downloads
  Drizzle: 2M weekly downloads (growing 400% YoY)
  TypeORM: 3M (declining)

Conclusion: Prisma is accurate for "most popular by downloads"
            but Drizzle is the momentum play for new projects

The step that most developers skip is asking for alternatives explicitly. AI models default to a single recommendation because that's usually what's being asked for. But forcing the model to enumerate alternatives often surfaces newer or more specialized options that the model knows about but ranked lower because they have less training data representation. For any important architectural decision — ORM choice, state management library, testing framework — always ask "what are the main alternatives and when would you pick each?" as a follow-up.

Specific prompt templates that improve package recommendation quality from AI: "What are the most popular packages for X, and what has the community adoption trend been over the last year?" (this forces the AI to reason about momentum explicitly). "What packages for X have emerged or grown significantly in the last 12 months?" (directly prompts for newer options). "What package would an expert pick for X in a new TypeScript project started today, and what would an expert avoid?" (the "avoid" framing surfaces deprecated or declining packages).

One additional step for consequential decisions: check the fastest growing npm packages list against whatever the AI recommended. If the AI's recommendation doesn't appear on a growth list but an alternative does, that's a signal worth investigating.

What This Means for Package Authors

If you maintain or are building an npm package, the AI-first discovery landscape changes your marketing and documentation priorities significantly.

Documentation is no longer just for users — it's training data. Every page of your documentation that's comprehensive, well-structured, and includes real-world examples is a unit of training signal for future AI models. Write API documentation that explains not just what a function does but when you'd use it and why it's designed that way. Include comparison content that explains how your package relates to alternatives. Document migration paths from competing packages. All of this content will end up in training datasets.

Publish in high-signal venues. The State of JavaScript survey, the State of CSS survey, and similar annual ecosystem surveys are known to be included in AI training data. Getting your package mentioned in those surveys — either because developers voluntarily mention it or because you encourage your community to participate — amplifies your training signal. Getting included in "awesome" lists on GitHub matters. Getting mentioned in popular developer newsletters matters.

Update your documentation frequently, not just when APIs change. AI models trained on content from 2023 will have older versions of your documentation. Regular updates, new tutorials, new comparison articles, and new integration guides keep your training signal current as new model versions are trained. Think of documentation as a living SEO and AI-presence strategy rather than a static reference.

The practical documentation investment for a package looking to improve AI discoverability: write a detailed README that explains the core use case clearly, publish at least two "getting started" tutorials on your documentation site, write at least one "X vs Y" comparison article, and create integration guides for the most common frameworks your users combine with your package. This investment compounds over time as content gets discovered, linked, and included in training datasets.

The packages that thrive in an AI-first discovery environment are not necessarily the technically superior ones — they are the ones that have invested in documentation quality commensurate with their code quality, making the discovery advantage between them and less-documented alternatives a sustained competitive moat rather than a temporary lead.

Check real-time package health and download trends on PkgPulse — the data AI can't always access.

See also: React vs Vue and The Average Lifespan of an npm Package, How GitHub Stars Mislead Package Selection.