the more interesting signal in that data is about intent, not quality. most of these low-star repos probably aren't failed open source attempts - they're personal tools that were never meant to be shared.before ai-assisted coding, the effort-to-build ratio was high enough that most personal scripts stayed on a laptop or in a private gist. pushing to a public repo implied an implicit claim that someone else might want this. now the build cost is low enough that people just push things to git for their own version history and move on.what's actually happening is that git is becoming a personal dev journal as much as a collaboration platform. stars were always a weak proxy for value, but they're especially wrong for this use case.the 90% number probably also undercounts the real extent of this - most serious claude code usage is on private repos and internal tooling that never touches public github at all. the 50b lines stat would look very different if you could see total token output vs just github-public-linked output.
The security implication of this shift is underappreciated. A repo that was never meant to be shared was also never security-reviewed. Personal tools built fast tend to have hardcoded API keys, credentials committed during a "just get it working" phase, and file system access patterns that weren't meant to be public.
The 50B lines across those low-star repos isn't just an interesting metric about usage patterns. It's a significant amount of unreviewed code sitting in public repositories. Stars were never a quality signal, but they were at least a proxy for "someone other than the author looked at this." That selection effect disappears entirely when the build cost drops to near zero.
It would be very interesting to see how much of this is the "audience of one" type of project - i.e. personal scripts - vs new developers/vibe coders trying to start an app. I have definitely been surprised by the scale of some of the repos that seem to be vibe-coded. People who seem to have no history in development are building game engines, and payroll systems, and Broadway review websites.
Unfortunately that type of analysis would take a bit more work, but I think the repo info and commit messages could probably be used to do that.