The top of GitHub is three lists. That's a problem for your agent.

What happened

A quick look at GitHub's all-time leaderboard today: sindresorhus/awesome sits at 444,000 stars, freeCodeCamp/freeCodeCamp at 437,900, and public-apis/public-apis at 411,900. All three are trending again this week, which is itself a quirk — repos this large rarely move the trending needle unless something external pushes them.

Two of the top three are markdown files. The third is a curriculum. `awesome` is a list of links to other lists of links. `public-apis` is a table of free APIs. `freeCodeCamp` is the only one that contains a working application, and even there the star count is overwhelmingly driven by the learning content, not the codebase.

This isn't a new observation, but it's worth re-stating now because the audience for GitHub's leaderboard has changed. It used to be humans browsing Explore. Today a meaningful fraction of repo lookups originate from coding agents — Claude Code, Codex, Aider, Cursor's background indexer — that are doing some version of "find me a library that does X" and using stars, recency, and trending signals as a proxy for quality.

Why it matters

The star count was never a quality signal. It's a save-for-later button with a public counter attached. Stars correlate with discoverability, language popularity, and how many times a repo got linked in a viral tweet — not with whether the code works, is maintained, or is safe to depend on. Anyone who's ever inherited a 40k-star abandoned package knows this. But the gap between "stars" and "quality" only mattered as long as the consumer was a human who could spend ten seconds reading the README before installing.

Agents don't spend ten seconds. They spend a tool call. And the heuristics agents use to rank candidate repos are almost universally derivative of the same public signals — stars, fork count, last-commit recency, trending position. If those signals are gamed, or simply misleading, the agent doesn't have a second-order judgment to fall back on. It just picks the top result and writes an import statement.

The `awesome` / `public-apis` problem is the benign end of this spectrum. They're high-quality lists. The worst case is that an agent gets confused about whether a repo is a library or a directory of libraries and produces a broken plan. The malignant end is what we've been watching for the past week: typo-named repos like `Codex-5.5-codex-instruct-5.5`, `dd`, and `clash` farming GitHub Trending specifically because agents tokenize repo names and don't disambiguate. Different mechanism, same root cause: the leaderboard is a trust surface, and trust surfaces with no authentication get exploited.

There's a structural piece here too. GitHub's ranking algorithms — Explore, Trending, the search API — were tuned for an era when the marginal user was a developer at a laptop. They reward broad appeal, link density, and English-language READMEs. A bilingual systems library with 800 stars and a working test suite is invisible next to a links-to-links-to-links repo with six figures of stars. For human discovery that's a tolerable bias. For machine retrieval that's a poisoned well.

Community reactions over the past year — from Simon Willison's posts on agent supply chain, to the Socket and Snyk writeups on npm typosquatting, to last week's discussion about Anthropic's Skill marketplace surface area — keep landing on the same conclusion: the package-discovery layer is the weakest part of the agent stack, and nobody owns fixing it. GitHub treats stars as a vanity metric. npm treats download counts the same way. PyPI has been more aggressive but still doesn't verify maintainership transitions. The result is a discovery substrate where the most popular thing and the most correct thing have only a loose correlation, and agents have no way to tell which is which.

What this means for your stack

If you're building anything that lets an LLM pick its own dependencies, audit the ranking function. Specifically: if you're feeding GitHub search results, npm search results, or PyPI search results into a prompt as "candidate libraries" without an additional filter, you've inherited every weakness of the underlying ranking. At minimum, exclude repos where the primary language is Markdown, the last meaningful commit (not a README touch) is older than 12 months, or there's no `package.json` / `pyproject.toml` / `Cargo.toml` / equivalent manifest at the root. Those three filters alone would drop `awesome` and `public-apis` from any agent's candidate set without losing anything an agent would actually want to install.

For retrieval-augmented setups, weight signals the leaderboard doesn't: download counts from the actual package registry (not stars), CI badge status, downstream dependent count, and presence of a security policy file. None of these are individually authoritative, but together they're a meaningfully better proxy for "this code does something" than the star count is.

For agent runtime sandboxing, assume the agent will occasionally try to clone a repo that turns out to be a markdown file and write code against it as if it were a library. That failure mode should produce a clean error, not a hallucinated import path that compiles and silently does nothing. The tightest fix is a post-tool-call validator that checks whether the cloned repo contains a manifest matching the language the agent thinks it's working in.

Looking ahead

None of this gets solved at the GitHub layer in 2026. The leaderboards are too entrenched, the SEO incentives are too strong, and the company has no commercial reason to demote its most-starred repos. The fix has to happen one level up, in whoever sits between the agent and the registry — and right now that's a job nobody has hired for. Expect the next wave of agent infrastructure to include something that looks a lot like a package-trust API: a signed, versioned, ranked feed of "libraries the agent is actually allowed to install," curated by someone with skin in the game. Until that exists, the top of GitHub is going to keep being three lists, and your agent is going to keep being mildly confused about it.