Star-Farm Forensics: A 30-Second Checklist When GitHub Trending Lies

What happened

A day after @Top10_dev flagged GitHub Trending's broken state, the leaderboard hasn't healed — it's rotated. PMTraderAdam/PMTraderAdam sits at 318 stars (up from 297 yesterday). iebb/mithka is at 282 (up from 246). And slimopump/sillygoose has slotted in at 278, replacing kanavtwtgg/birds.cafe from yesterday's screenshot. Three repos. Same archetype: profile READMEs and personal sites with no inbound dependencies, no issues, no fork graph, no recognizable maintainer footprint.

The pattern isn't that bad repos trend — it's that the same shape of bad repo keeps trending, with new aliases substituted in as the algorithm rotates. Birds.cafe is gone. Sillygoose is here. Tomorrow it'll be something else with a four-syllable vibe-name. The Trending algorithm is not failing to detect coordinated inauthentic behavior; it's failing in a way that's perfectly compatible with someone running a sustained pipeline.

The defensive question for senior developers isn't "why hasn't GitHub fixed this?" — that ship sailed in 2019 when star purchasing went public. The useful question is: what does a real repo look like, and what does a farm look like, and can I tell the difference in less time than it takes to read the README?

Why it matters

GitHub Trending is the default discovery surface for a substantial fraction of working developers. It's linked from the homepage. It shows up in onboarding tours. Internal corporate dashboards and "tools to watch" newsletters pull from it directly. Every minute Trending stays gameable, the cost of seeding a malicious package or a vibe-coded grift into a senior engineer's reading list drops.

The economics are not subtle. A fake star from a low-effort seller runs roughly $0.05–$0.15 wholesale; a curated batch from accounts with plausible commit history runs more. Two hundred stars to crack Trending costs less than a steam key. Compare that to the marketing-attributable value of being on the GitHub homepage for six hours and you understand why the supply exists. The classic security framing — "could an attacker use this to distribute malware?" — is already a year out of date. They are. There have been public incidents of typosquatted npm and PyPI packages riding inflated GitHub stars to legitimacy. The Trending list is the cheapest social proof on the internet, and social proof launders trust faster than any audit catches up.

The community reaction in HN threads and Lobsters comments has settled into a kind of weary realism. Nobody's defending GitHub's algorithm. The disagreement is between "GitHub should fix this" (the dwindling optimists) and "GitHub will not fix this because engagement metrics don't distinguish between real and fake interest" (the structural-cynicism camp). The latter is winning on the merits. Star count, like Twitter follower count, has converged on a Goodhart's-Law endpoint: the metric stopped measuring the thing the moment it started being optimized.

Which leaves practitioners to build their own filter.

What this means for your stack

Here's the 30-second forensic checklist. None of it requires fancy tooling — just `gh`, the GitHub UI, and the `git log` of the repo.

Tell 1: Account age vs. star velocity. Real repos accrue stars logarithmically from a long-tail of accounts. Farms spike. Run `gh api repos/OWNER/REPO/stargazers --paginate | jq '.[] | .starred_at'` and look at the histogram. A repo gaining 300 stars in 18 hours, where 80% of the starring accounts were created in the last 60 days and have starred fewer than 10 other repos, is not having a moment — it's having a transaction.

Tell 2: Follower-graph triangulation. Click three starrers. If they follow each other, follow the repo owner, and have no overlapping interests beyond "following accounts that follow this repo," you're looking at a sock cluster. Real developer follower graphs are dense in technology communities (Rust people follow Rust people) and sparse otherwise. Farm graphs are dense in the farm and sparse everywhere else.

Tell 3: README lexical sophistication. Real maintainers write READMEs that explain installation, dependencies, and tradeoffs; farms write READMEs that explain vibes. Grep the README for the words "install," "requires," "license," "contribute," "issue." If none of them appear, and the prose reads like a personal mission statement, the project does not exist to be used. It exists to be counted.

For discovery beyond Trending, the working alternatives in 2026 are: GHArchive on BigQuery (you can write your own velocity-and-graph filter — the data is public), lobste.rs filtered by tag (smaller community, harder to astroturf, mod-curated), Show HN with a 24-hour delay so the dust settles, and curated awesome-lists where the maintainer has personal reputation skin in the game. None of these are Trending-shaped — there's no leaderboard. That's a feature.

For dependency selection specifically: if your only signal for adding a library is its star count, you have no signal. Stars correlate with mindshare among people who star repos, which is a population whose overlap with "people who have run this code in production" is unknowable and shrinking. Look at issue close rate, release cadence, the ratio of dependents to stars, and whether the maintainer responds to bug reports in something less than geologic time. All of that is on the repo page. None of it is on the Trending page.

Looking ahead

GitHub will not fix Trending in a way that hurts engagement metrics, because that's how product managers get demoted. The realistic forward path is that Trending becomes vestigial — a thing on the homepage that experienced developers learn to ignore the way they learned to ignore the App Store top charts. The discovery work moves to higher-trust, lower-bandwidth channels: newsletters with named editors, mailing lists, the social graph of senior engineers you actually respect. That's already happening. The repos at the top of Trending today are evidence the migration is overdue, not evidence the system is salvageable.