Hi Divya et al.,
On 2/20/26 19:04, Divya Ranjan wrote:
Moreover, I don't think we /need/ LLM contributions. Guix gets a decent amount
of contributors already, and it's already difficult for us to review and
maintain those contributions, adding another layer of analysis where we're
worried about if something is from LLM or not will just be a waste of time in
my opinion.
Putting this number-of-contributors argument in context of the 4 package
fixes I generated earlier in the thread: that was using LLMs to solve
the wrong problem.
The main benefit of using LLMs is speed. Creating those 4 patches would
easily take an hour by hand, but only minutes with an LLM. So if ones
goal is to just 'fix packages', then LLMs are a clear winner, easily
making the developer 10x as productive (while preserving quality).
But if one uses those packages 20 hours a week, then spending 20 minutes
every few months to fix them doesn't even move the needle. And one
would probably also want to make upstream P.R.s and such, increasing the
'quality' beyond the patch itself.
I strongly believe "users are developers". So we don't actually have
enough users, since many packages are broken for months. Using an LLM
won't solve that number-of-users issue.
Hugo
P.S. Maybe we could use LLMs to have an on-the-fly "Let's fix this
package tutorial!". A user does "guix install my-favorite-package", and
it is broken. An LLM figures out what's wrong, and then guides the
user-to-be-contributor through the steps required to fix it and make a
P.R, luring them in. Can someone vibe-code such a tool? :-)
Semi-serious though; using an LLM as a tool to figure out what the
problem is, feels different to me from having the LLM fix it itself.
