The major point is AI usage.
References:
My stand (for now):
There are three main points for me:
-
Copyright and authorship
-
Quality
-
Costs (I'm not talking just about money)
-
I need to research more, so no comments for now, however, I do not welcome a PR that wasn't really made by the contributor (that is, it was 100% AI generated).
-
Even if coding becomes extinct (and I doubt it), you're responsible for what you propose to push, and thus, engineering quality is important and it is contributor's responsibility to ensure a good quality contribution; In my projects, and will especially the case of Nene, "quality > silly productivity": I much more prefer code that doesn't needs to be rewritten than constant refactor on the same thing over and over, so stability is a concern. Of course, no slop allowed.
-
The major pain point: environmental costs. There's nothing I can do about it since I cannot control (and shouldn't control either) which model a contributor use. However, considering local and smaller models is a good goal.
In summary:
I'll test LLM usage for software engineering in this project, along with other things, as a way to learn myself a more solid software engineering work than I'm used to do (which I'm currently unsatisfied). More details on #1
As a rule: only use LLMs when I know what I'm doing and why.
The major point is AI usage.
References:
- [Fedora AI contribution policy](https://docs.fedoraproject.org/en-US/council/policy/ai-contribution-policy/)
- [Forgejo AI agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md)
- [Linux Foundation AI policy](https://www.linuxfoundation.org/legal/generative-ai)
My stand (for now):
There are three main points for me:
1. Copyright and authorship
2. Quality
3. Costs (I'm not talking just about money)
1. I need to research more, so no comments for now, however, I do not welcome a PR that wasn't really made by the contributor (that is, it was 100% AI generated).
2. Even if coding becomes extinct (and I doubt it), you're responsible for what you propose to push, and thus, engineering quality is important and it is contributor's responsibility to ensure a good quality contribution; In my projects, and will especially the case of Nene, "quality > silly productivity": I much more prefer code that doesn't needs to be rewritten than constant refactor on the same thing over and over, so stability is a concern. Of course, no slop allowed.
3. The major pain point: environmental costs. There's nothing I can do about it since I cannot control (and shouldn't control either) which model a contributor use. However, considering local and smaller models is a good goal.
In summary:
I'll test LLM usage for software engineering in this project, along with other things, as a way to learn myself a more solid software engineering work than I'm used to do (which I'm currently unsatisfied). More details on #1
As a rule: only use LLMs when I know what I'm doing and why.