Hello,
On 5/22/26 16:19, Ludovic Courtès wrote:
Hello,
Hugo Buddelmeijer via "Development of GNU Guix and the GNU System distribution."
<[email protected]> skribis:
The `openshot` package was not building on the python-team branch. I
spent 20 minutes on it, and couldn't figure out what was wrong, so I
asked Codex.
>> >> The P.R., with the included codex output is here:
https://codeberg.org/guix/guix/pulls/8736
I see 537 commits;
Apparently python-team rebased, I rebased the PR; it is only one commit.
If it were changing less than 15 lines of code (thus not being “legally
significant”), it’s OK for inclusion, per the current GCD draft.
I consider myself part of 'the project', therefore no genAI use is
allowed at all according to pledge 1. Or is that interpretation wrong?
The GCD does a good job in arguing against the extreme cases of genAI
use, but I found it rather weak w.r.t. to more mundane usage. So I
looked for a simple example that we could use as a vehicle to clarify
the GCD.
This is the simplest case I could think of that violates the pledge (as
I understand it):
- genAI was used by a team member, thus 'by the project'.
- The genAI only investigated, but did not write any code.
- It probably saved energy compared to by-human investigation.
- A very minimal change was made, by hand, based on the genAI analysis.
- The genAI corrected my theory of the software (see below).
If this is bad, why is it bad? What would be a good alternative?
I'm open to it being bad, but I think the GCD in its current form does
not provide a clear justification.
That is, if someone else would have created this P.R. in this way, I
would not be able to explain to them why they should not have done that
(and I don't want to make a pledge I cannot explain).
For a package in my field though, I may well do a better job than an
LLM, in particular anticipating planned changes in our packaging
strategy
I indeed thought about this; because the problem was tied to "changes in
our packaging strategy", and (partly) came to the opposite conclusion.
It turned out that the problem was not related to the Python 3.12
migration at all, but to the pyproject-build-system migration.
Something the genAI properly identified.
But if I would have figured out the fix myself, I might still have
assumed it was related to Python 3.12, reinforcing an incorrect theory.
I actually called the LLM out on its conclusion, and it went through the
git history to show me that it was right.
So I think the LLM actually helped me correct my mental model of the
software we are building, something we hold dear.
Hugo
