Claude's Code dev here, and I thought I would chime in on this point to clarify why I track it at all.
When I started reading commit data, it became painfully apparent that a very large number of repos are tests, demos, or tutorials.
If you have at least 1 star, that excludes most of those - unless you starred it yourself.
Having 2 stars excludes the projects that are self-starred.
Starring is also quite common with my friends and colleagues as a way to find repos again later, so there is some use to it, but I agree it's not a perfect indicator of utility or quality.
It's a great idea to track releases. Won't be a perfect measure since not all things are packaged on Git, but adding it to the roadmap. Thanks for that.
But also, GitHub profiles and repos were at one point a window into specific developers - like a social site for coders.
Now it's suffering from the same problem that social media sites suffer from - AI-slop and unreliable signals about developers.
Maybe that doesn't matter so much if writing code isn't as valuable anymore.
That's a fair question, I shouldn't have posted that without context.
I was initially considering storing JSON to speed up the ingestion since the results are in JSON, which is how I found JSONBench.
But, of course, parsing the JSON isn't the bottleneck for me - rate limits and response time is - so I didn't end up going that route.
What I mention first in my message was a much bigger driver - convenience.
If the analytics become much more complex I might revisit DuckDB or another OLAP solution.
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.
Absolutely! I think the real stats will far exceed what we can see on public GitHub. That said, going through some of the top "performers" by commit and line count - I am surprised by how many people have all their code in public repos.
I have been enjoying looking into the projects that use it heavily. That one, for instance, was entirely built this year and the owner hasn't been active on GitHub before - again showing that agents are inviting people who either didn't have the skill or didn't have the time to build out some of their ideas.
Another view I like keeping an eye on is projects with higher star ratings - that often excludes the "pet projects" and gives you an idea of how larger teams or popular repos are applying it differently to the general "vibe coders".
I considered it, but when I started the project I was using a Supabase DB for the backend since their free-tier is quite nice, and after the switch to and from BigQuery, PostgreSQL was the easier migration. I also thought Postgres might be more suited to the backfill/ingestion job due to the frequent row-level reads and writes. That said, I know DuckDB can use Postgres in the backend, and I might consider that if the current model starts to struggle.
Are you using Grok for the coding? Because I have Copilot connected and I can see the request to Copilot for the summaries - with no "small model" setting even visible in my settings.