On 19/02/26 at 20:28 +0000, Sean Whitton wrote: > Lucas Nussbaum [19/Feb 12:18pm +01] wrote: > > Could you elaborate on how you would use such distinction in ballot > > options? I think that the core issue is the fact that tools generate > > content that is then integrated into Debian. I don't really see how it > > could be useful to distinguish between uses of such tools as long as > > they are used to generate code. > > My point is that they have uses beyond generating code and someone might > want to vote to say to allow those uses, but to disallow including > generated code. > > For example, if you use them as a fancy find-and-replace to do some > refactoring, that's not really generating code. Someone might be okay > with that. Someone else might not be (even though we couldn't detect > that a contribution was made using an LLM purely to do refactoring like > that, we want to vote on what we believe is actually acceptable).
I'm not sure that would work in practice. As soon as content is added (in the sense of + lines in a diff), all the problematic aspects of AI-assisted coding are there and the contributor must behave responsibly. I would be open to more explicitely exclude the vibe coding use case[1] in my draft, because it makes little sense in the context of Debian. But I feel it's already covered by "Contributors should fully understand the proposed changes and be prepared to justify them". Also vibe coded contributions can be useful in corner cases, for demos or POCs (e.g. "maybe we could do something along the lines of X"), so the wording would have to be carefully designed... Lucas [1] by "vibe coding", I mean the activity where you describe what you want, let the LLM generate the code, but never really look at the code (if you needed to change the product, you would update the requirements, not try to change the code). This is basically using the LLM as a compiler from requirements to real code. As a real example, see https://github.com/lnussbaum/vibe_multiplication/
