It will be interesting to see how the project activity is unfolds? Are people using it in production. How many errors do they find. What do those fixes entail. What happens with the docs over time. Etc.
I haven't had a change to look in depth, but based on a quick glance I'd say that the activity on the project seems like the tempo you'd expect of a similar open source project.
I got curious and had a look at some of the code (>1m .rs). I was surprised to see code for a S3 client in there?
I clearly don't get the value proposition of bun? And even if I accept that you want to bundle your run time, package manager, test runner and bundler, why do you want to include things like a custom S3 client?
I like the idea, but I didn't like losing after a few words. Now it might just be me not being good at losing, but who is?
Maybe the game can always progress to the next word with your total score being reduced. So if you get all within 30 seconds you score 18/18. That way everyone can play the whole game and share with their friends how far they got:
The challenge is that more and more people are producing project like this - 1,000s of commits and > 200k lines of code - and saying it was carefully created using agent based workflows and not vibe coded.
How would one go about reviewing a piece of code like this?
One of the things I'd typically do is peek at the commit history. Seeing what people worked on and how they did it tends to say a lot about a project. But with LLMs generating 7101 commits in less than a month that isn't feasible. Even looking at a single day is way too much [1]. It probably also doesn't make sense since the commits content won't tell you much anyway.
ps. How do you easily get to the first commit in a repo on GitHub? Browsing commit history feels rather tedious
For me the worst scenario is when a kitchen sink of non-existent functionality the customer never asked for was sold. And in all likelihood it will never be used. But some project manager is hellbent on getting it through the pipeline and checked off!
I (maybe idealistically) believe that when you give the people building agency and connect them with the end-user, you get better outcomes.
Thanks, this articulates something that I've been struggling to put a finger on. You can't review agent generated code the same way you would review a PR, someone needs to fine comb it to make sure everything is fine. And doing that for something like 100,000 lines of code over a few weeks just doesn't sound realistic to me.
Don't compromise your professional integrity by lying about how you work. Rather find a job where you don't need to lie about your use of AI if you can.
> The security researchers are not special, the insight and confidentiality are
vs
> The bottleneck now is not finding potential issues but assessing which ones are real. Unless there’s already a trust relationship, external researchers can’t meaningfully contribute
My take-away from this is that the researchers were special all along and you should probably be building a trust relationship with them.
Despite what I want to believe about tech being a meritocracy, the reality is that trust plays an extremely important role and without it we risk a collapse of our open source software ecosystem.
One of my biggest criticisms of AI is the trust vacuum within which it operates