Comment by mik3y
1 day ago
Sort of a digression, but it's the first time I've seen something like this:
> We don't take pull requests. Have your agent open
> an issue describing the bug or idea, and our agents
> usually turn it around fast.
Pretty interesting approach, compared to receiving a zillion potentially sloppy PRs. Open source in the age of LLMs.. ("agent source"?)
I find this line pretty sad actually, what if someone wants to contribute code, written by hand? What if some beginner finds this project interesting and wants to invest own time into it?
Or human is completely removed from the development whatsoever..
> I find this line pretty sad actually, what if someone wants to contribute code, written by hand? What if some beginner finds this project interesting and wants to invest own time into it?
Then they would be better off contributing to a project that welcomes them.
While I sympathize I think we all know a majority of contributions would not be hand written. This is optimizing for the reality we're in.
You could fork and reference it in the issue if you still wanted to contribute.
> what if someone wants to contribute code, written by hand?
It's up to the maintainer. Sometimes it's just easier to listen to what's needed and do it the way you know and are efficient with than to review someone else's code.
> What if some beginner finds this project interesting and wants to invest own time into it?
There's nothing stopping them. They can even publish it in a fork.
Why would any beginner want to contribute or invest a large amount of time where he doesn't trust a maintainer or their processes?
Yep. There's other projects that have a "we want your ideas, but not your code" policy (like SQLite and Lua), but the "just tell your agent to tell our agent what to do" framing makes me depressed.
Why would you contribute code written by hand in 2026?
Just take your hand written code and have it send it as the request to the AI.
Why would you want to contribute thoughtfully written code to a slop project?
Those days are over
I did the same for a vibecoded project [0] but I would never do this for a human-written project. Simply put, if most contributions are similarly vibecoded and/or they will be reviewed/treated as such, then how is a PR/review from an unaffiliated agent any better than one managed by the project curator. Of course that human curation still needs to occur.
This is a natural progression (only on these types of projects). We accepted contributions because it actually helped and they were difficult and time consuming. When that is no longer the case, contributions are a burden, the actual problem/idea is the real value, hence the request to open the issue.
0 - https://github.com/cretz/vitaslop
Won’t this just lead to bloatware in the long run? Part of creating a product is knowing what to say no to. And I’ve found my customers’ ideas for how to improve my products aren’t always the best way to implement the feature they want (or it would create issues for other customers who use it differently).
They never said they'd merge in every idea.
I had a Nix issue. Agents fixed it in 5 min.
Of course, one could conclude that another agents screwed up before, still was a good experience.
It sounds like a black hat penetration tester's nirvana. All you have to do is open the right issue to trick the model into installing the right security vulnerability or backdoor, or better yet, a series of small security vulnerabilities that can be chained to create a tailor-made exploit. It's practically a hacker's choose-your-own adventure.
I am not sure about that.
Which gate is easier to maintain?
1. Check issues for malicious intent
2. Check PR for malicious intent.
I think in PR requests it is easier to introduce purposeful bugs or obfuscated code than it is to hide them in issues.
So I think gating on issues is easier and more secure.
I suspect they'd be manually filtering which issues/features their agents attempt to fix/implement. Otherwise you end up with all sorts of features that simply make no sense for the project.
The approach is at least better than accepting slop PRs that could have backdoors injected into them.
That seems a lot harder than if they accepted PRs like everyone else
Makes this (not a real) job posting seem all the more funny/relevant:
https://lovro-bikic.github.io/software-line-specialist/
My main concern with this would be that for a library in particular I need a stable API and behavior (Hyrum's law). I do not know to what extent a fully autonomous agentic approach can ensure that. Note: I don't see a problem with preferring issues over pull requests (many of which would be poorly coded slop), just fully automating the handling.
Also a bit wild to assume that no person will just create an issue manually. This is not something I'd normally use an agent for.