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 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.

I am not sure about that.

Which gate is easier to maintain?

1. Issue requests

2. PR requests.

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.

That seems a lot harder than if they accepted PRs like everyone else

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..

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.

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 us what our agents should do" framing makes me depressed.

Those days are over

> 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.

Why would you want to contribute thoughtfully written code to a slop project?

> 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.

Just take your hand written code and have it send it as the request to the AI.

Why would you contribute code written by hand in 2026?

Why would any beginner want to contribute or invest a large amount of time where he doesn't trust a maintainer or their processes?

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.

I did the same for a vibecoded project [0] but I would never do this for a human-managed 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

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.

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.