phantomCupcake

Any specific reason you ended up creating your own skills and workflow instead of using an existing one like get-shit-done or OpenAgent Control?

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.

Not at all! The ShowHN didn't really get a lot of feedback but this thread has already given me a lot to think about adding/improving.

This.

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.

Thanks for starting the conversation and sharing my dashboard. :)

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'm glad you like it!

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.

I have also seen some benchmarks that suggest the gap between DuckDB and Postgres isn't always so substantial: https://jsonbench.com/#eyJzeXN0ZW0iOnsiQ2xpY2tIb3VzZSI6dHJ1Z...

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.