I was thinking about this now and has satisfactory results in my own projects.
Basically there is a bot in Matrix which lets you know when a package you maintain has a build failure. Sometimes the situation is simple but there is all that intertia.
What if we add something that reacts to those events to spawn Jules agents to do that? Jules has a unique position of having Nix installed in it’s environment. I have a Cloudflare Worker to run proactive housekeeping tasks in a scheduled manner.
Something has a build failure, it triggers an event, build a prompt from a template and automatically sends PRs. It’s just a matter of someone to review, or close if the solution is bad.
That way our work as maintainers shift from “do” to “review”. They dont bill by the tokens, there is just that 100 daily, 15 concurrently running sessions limit for AI pro subscription, which one can take one year for free by using the uni email.
It may increase a little the spam PR rate but I think the tradeoff is worth it, also, we can finetune the prompt and learn together how to finetune it.
What do you think about this? Even though there is that irracional hype AI is there to stay so we should find ways to better use it and Gemini is getting very good for a lot of things, and at least in my perception, Google has a much more sustainable model around that by being able to internalize the whole stack.
At the very least, i think this would require a first triage ahead of pr-ing, with nixpkgs-review, so the generated code is a solution that builds. Then, the indirect author (the person that started the AI job) to review themselves the pr to approve whether it should be open. They should definitely be knowing about the area of work and have some background with working in the codebase to be able to change things in case of a problem (which will realistic happen with AI).
With theses restrictions we would avoid getting tons of crap half-working stuff that floods the long nixpkgs queue of opened prs, and possible intervention of the author. Or even mass pinging people on un-mergeable prs.
I also think a label, a bot user, or a mention in the description that clearly indicate the nature of the contribution, so it can be filter-out easily for people that dont want to review/deal with AI-generated content.
I think the main issue with PR throughput in nixpkgs is review capacity, not speed of PR generation. At worst this will just pull more review capacity from important topics, simply because this will generate more PRs. I also wonder if low-hanging fruit PRs like this don’t serve a valuable training purpose.
I.e., I see where the value in this would be on typical projects, but the sheer volume and contributor composition of nixpkgs is a bit different than your average project, and I think this should be recognized. I’m worried about atrophying our skilled-human influx in a world where this is already going to fall off a cliff; broken package builds are a good motivator for learning how to contribute.
In practice I don’t think it would have that negative of an impact, so I don’t really think there’s an issue with experimenting, especially given @Sigmanificient 's suggestions on implementation.
It would certainly reduce the amount of time the community spends cloning git repos, though I’m not holding my breath for much of an increase in meaningful throughput.
Outside of that my only concern is copyright; I’m sure the US legal battles will fall in line with the money, as they always do, but I am less certain the outcome will be what a FOSS community who want to retain copyright over their projects is comfortable with.