I've built with GSD, and experimented with rolling my own. I think GSD is good if you don't know exactly what you want to build, but you only have a vague idea. However, if the opposite is true (and I believe it should be), then GSD has a lot of overhead, and costs a lot of tokens.
Subjectively, my GSD apps looked very much like AI slop (the app itself, not the code), and felt soulless.
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.
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.
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.
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.
reply