Re: AI contributions
On Fri, 2026-05-08 at 14:04 -0400, Richard Kimberly Heck wrote: > To my mind, the key difference is between existing contributors and > submissions from people we do not know, and who have no track record. > I'm less worried about large vs small. If Pavel wanted to us Claude to > help re-write large segments of the comparison code, I would trust him > to make sure that the changes were actually sensible, and trust the rest > of us to go over the code as well. If some random person submits a bug > patch, then I'm going to review it carefully whether they used AI or > not. If it's huge, then of course I'll be more skeptical, and more > careful, but that's where the size difference matters. > > Riki FWIW I agree with you. :-) -- José Abílio -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: AI contributions
> 2026/05/09 3:04、Richard Kimberly Heck のメール: > > To my mind, the key difference is between existing contributors and > submissions from people we do not know, and who have no track record. I'm > less worried about large vs small. If Pavel wanted to us Claude to help > re-write large segments of the comparison code, I would trust him to make > sure that the changes were actually sensible, and trust the rest of us to go > over the code as well. If some random person submits a bug patch, then I'm > going to review it carefully whether they used AI or not. If it's huge, then > of course I'll be more skeptical, and more careful, but that's where the size > difference matters. I also agree with the use of Claude. I sometimes rely on Google AI mode in a very small scale. It can give some inappropriate answers but still very useful. Koji-- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: AI contributions
On 5/8/26 3:14 AM, José Matos wrote: On Wed, 2026-05-06 at 23:04 +0200, Jean-Marc Lasgouttes via lyx-devel wrote: I would not object if people who know what they do use AI for such small changes. JMarc In my own opinion the question is more nuanced than that. What does qualify to be a small change? What if there is a set of small changes that when considered together make a great change? Regarding us, as a project, the issue about AI can come about the issue of the training of the model (who trusts the trustees?). Another important issue for us is the maintenance of the code. Here is here the slop affects us. My main point, regarding the objection to the "small changes argument", is that we should not trust a huge code change, at once, regardless whether it comes from AI or purely from humans (or other sentient beings). :-) FWIW I think that we in agreement here. :-) To my mind, the key difference is between existing contributors and submissions from people we do not know, and who have no track record. I'm less worried about large vs small. If Pavel wanted to us Claude to help re-write large segments of the comparison code, I would trust him to make sure that the changes were actually sensible, and trust the rest of us to go over the code as well. If some random person submits a bug patch, then I'm going to review it carefully whether they used AI or not. If it's huge, then of course I'll be more skeptical, and more careful, but that's where the size difference matters. Riki -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: AI contributions
On Wed, 2026-05-06 at 23:04 +0200, Jean-Marc Lasgouttes via lyx-devel wrote: > I would not object if people who know what they do use AI for such small > changes. > > JMarc In my own opinion the question is more nuanced than that. What does qualify to be a small change? What if there is a set of small changes that when considered together make a great change? Regarding us, as a project, the issue about AI can come about the issue of the training of the model (who trusts the trustees?). Another important issue for us is the maintenance of the code. Here is where the slop affects us. My main point, regarding the objection to the "small changes argument", is that we should not trust a huge code change, at once, regardless whether it comes from AI or purely from humans (or other sentient beings). :-) FWIW I think that we in agreement here. :-) Best regards, -- José Abílio -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: AI contributions
On Wed, May 06, 2026 at 11:04:14PM +0200, Jean-Marc Lasgouttes via lyx-devel wrote: > Le 06/05/2026 à 16:00, Pavel Sanda a écrit : > > Hi all, > > > > --- > > [TL;DR: Are you Ok with committing small-enough changes to the code, > > which were reviewed, there is clear maintenance commitment, and > > the change is transparently tagged in commit as AI-assisted? > > > > I would be for it, but community discussion is needed here.] > > --- > > I would not object if people who know what they do use AI for such small > changes. I think I feel similarly. Scott signature.asc Description: PGP signature -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: AI contributions
On Wed, 2026-05-06 at 15:38 -0400, Richard Kimberly Heck wrote: > Hi, Pavel, > > I am broadly in agreement with your analysis. Practically speaking, if > existing developers want to use AI to help them fix bugs, then I have no > problem with it. I trust all of us to review the code the same way we > usually would. It probably wouldn't hurt to have a +1 sort of policy, > the way we do just before releases, just to guarantee an additional > level of review in such cases, at least at first. It also wouldn't hurt > for people to post things, along with the patches, similar to what you > did. But I'm not sure we need to require that. I am in strong agreement with both Pavel and Riki. > Code submissions from unknown external people are a different matter. I > don't see a need to rule these out entirely, but they would need careful > review. But that's already true for contributions from such people. > Maybe review that is a bit more careful would be good. > > It's pretty freaking impressive what Claude did. I recently got sent a > paper by a colleague in which he used AI to help him prove a central > lemma. His view was that he could have done it himself, but he was a bit > rusty on certain things, and so AI made it much easier. > > Riki I also have this feeling. Yesterday I had an issue related with lambda (anonymous functions) capture in Python. For what is worth this also applies to C++ functions. Claude identified the issue and clearly stated the problem and suggested a simple solution. It is not so much that I could not do it but it would take a longer time to fix something that was tangent to the problem that I was trying to solve. My only issue with those tools is the absence, by default, of any emoticons. :-D Best regards, -- José Abílio -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: AI contributions
Le 06/05/2026 à 16:00, Pavel Sanda a écrit : Hi all, --- [TL;DR: Are you Ok with committing small-enough changes to the code, which were reviewed, there is clear maintenance commitment, and the change is transparently tagged in commit as AI-assisted? I would be for it, but community discussion is needed here.] --- I would not object if people who know what they do use AI for such small changes. JMarc -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: AI contributions
On Wed, May 06, 2026 at 03:38:45PM -0400, Richard Kimberly Heck wrote: > I am broadly in agreement with your analysis. Practically speaking, if > existing developers want to use AI to help them fix bugs, then I have no > problem with it. I trust all of us to review the code the same way we > usually would. It probably wouldn't hurt to have a +1 sort of policy, the > way we do just before releases, just to guarantee an additional level of > review in such cases, at least at first. It also wouldn't hurt for people to > post things, along with the patches, similar to what you did. But I'm not > sure we need to require that. I agree with both +1 rule and posting analysis along with the patches. > Code submissions from unknown external people are a different matter. I > don't see a need to rule these out entirely, but they would need careful > review. But that's already true for contributions from such people. > Maybe review that is a bit more careful would be good. I had similar thoughts on this. For newcomers we don't know what their "review" means and my expectations about maintenance commitment are low when the initial investment is just writing five initial prompt sentences. > It's pretty freaking impressive what Claude did. I am reasonably confident that way simpler bugs like https://www.lyx.org/trac/ticket/13260 are one prompt and 5 mins away; the review will be probably trivial. > I recently got sent a paper > by a colleague in which he used AI to help him prove a central lemma. His > view was that he could have done it himself, but he was a bit rusty on > certain things, and so AI made it much easier. :) https://www-cs-faculty.stanford.edu/~knuth/papers/claude-cycles.pdf Pavel -- lyx-devel mailing list [email protected] https://lists.lyx.org/mailman/listinfo/lyx-devel
Re: AI contributions
Hi, Pavel, I am broadly in agreement with your analysis. Practically speaking, if existing developers want to use AI to help them fix bugs, then I have no problem with it. I trust all of us to review the code the same way we usually would. It probably wouldn't hurt to have a +1 sort of policy, the way we do just before releases, just to guarantee an additional level of review in such cases, at least at first. It also wouldn't hurt for people to post things, along with the patches, similar to what you did. But I'm not sure we need to require that. Code submissions from unknown external people are a different matter. I don't see a need to rule these out entirely, but they would need careful review. But that's already true for contributions from such people. Maybe review that is a bit more careful would be good. It's pretty freaking impressive what Claude did. I recently got sent a paper by a colleague in which he used AI to help him prove a central lemma. His view was that he could have done it himself, but he was a bit rusty on certain things, and so AI made it much easier. Riki On 5/6/26 10:00 AM, Pavel Sanda wrote: Hi all, --- [TL;DR: Are you Ok with committing small-enough changes to the code, which were reviewed, there is clear maintenance commitment, and the change is transparently tagged in commit as AI-assisted? I would be for it, but community discussion is needed here.] --- I will open the question which had to come sooner or later: what should be our stance towards AI-assisted/generated code? Do you have some strong or weak opinions about that? I am asking for very practical reasons - there are some issues, which bug me for years (comparison feature troubles being the major one). I know I can fix those, at the same time I know it will be week(s) of full time to address those - and that's totally out of my reach in the foreseable future. Below I shortly summarize my stance and add some links in case you don't follow much the current frenzy. After that I am adding one particular example, to give you sample taste. To start somewhere, let's look on the landscape of AI policies in the OSS [1]. We can see wide range of approaches from outright bans (gentoo/gimp/qemu) to permissive ones (kernel/llvm/scipy). It's clear that everyone has concerns, but often for different things. I would add my (current) views while using their methodology. I will try to be brief, but can discuss at length if needed. a) Quality. Cons: AI-slop is real, if you don't have the technical know-how and push the model at the right spots, it will self-confidently lie to you without restraint. Go discuss regexps with gemini if you want to have experience. Pros: The current (2026+) agentic models are no more toys for writing syntactic sugar routines. It can correctly graps large scale logical patterns in the project, understand the API on its own and write the code, which is correct after review and with better error handling that I would (lazily) do myself. My current stance: if you can actually do proper review and have reasonable technicall background, it's valuable assitant saving lot of time. If you are technically non-competent prompt engineer blindly trusting the code you are asking for big troubles. (I have been challenged on this point by friends (competent in CS) who are in the full-vibe regime and was shown *working* projects with nontrivial codebase in computer language not known to the maintainers. I have gut feeling this is wrong, but future might have it's own plans.) b) Copyright. Many issues here (of course I am not a lawyer), outstanding: - Both US/EU will grant copyright to human output, not machine. You can claim it if your interaction/tuning with AI is nontrivial. But simple prompt is not enough - our (C) LyX Team might not apply for such code. - The AI model might have been trained on licensed code. Some output might be verbatim snippet from elsewhere. There are ongoing legal battles in what sense is training LLM tranformative enough, so it does (not) pose copyright infringement. Some paid services (like claude) grants the right to you and also give explicit umbrella legal cover in case you get sued. My current (practical) stance: - If you spent enough time with AI tuning or add 10% Transformation rule of thumb [2] (manual refactor/comments) it's ours. - If the changes are tiny targetted patches (see example below) the infringement is out of question, larger chunks can be also checked by snippet scanners (FOSSA,GitHub Copilot Guardrails). - Practicaly we could use commit tags like in other projects similar to e.g. Assisted-by: Anthropic Claude Code (Reviewed by Human) and use certificate of origin by sign-off as seen in kernel certifying that ... The contribution is based upon previous work that, to the best of my knowledge, is c
AI contributions
Hi all, --- [TL;DR: Are you Ok with committing small-enough changes to the code, which were reviewed, there is clear maintenance commitment, and the change is transparently tagged in commit as AI-assisted? I would be for it, but community discussion is needed here.] --- I will open the question which had to come sooner or later: what should be our stance towards AI-assisted/generated code? Do you have some strong or weak opinions about that? I am asking for very practical reasons - there are some issues, which bug me for years (comparison feature troubles being the major one). I know I can fix those, at the same time I know it will be week(s) of full time to address those - and that's totally out of my reach in the foreseable future. Below I shortly summarize my stance and add some links in case you don't follow much the current frenzy. After that I am adding one particular example, to give you sample taste. To start somewhere, let's look on the landscape of AI policies in the OSS [1]. We can see wide range of approaches from outright bans (gentoo/gimp/qemu) to permissive ones (kernel/llvm/scipy). It's clear that everyone has concerns, but often for different things. I would add my (current) views while using their methodology. I will try to be brief, but can discuss at length if needed. a) Quality. Cons: AI-slop is real, if you don't have the technical know-how and push the model at the right spots, it will self-confidently lie to you without restraint. Go discuss regexps with gemini if you want to have experience. Pros: The current (2026+) agentic models are no more toys for writing syntactic sugar routines. It can correctly graps large scale logical patterns in the project, understand the API on its own and write the code, which is correct after review and with better error handling that I would (lazily) do myself. My current stance: if you can actually do proper review and have reasonable technicall background, it's valuable assitant saving lot of time. If you are technically non-competent prompt engineer blindly trusting the code you are asking for big troubles. (I have been challenged on this point by friends (competent in CS) who are in the full-vibe regime and was shown *working* projects with nontrivial codebase in computer language not known to the maintainers. I have gut feeling this is wrong, but future might have it's own plans.) b) Copyright. Many issues here (of course I am not a lawyer), outstanding: - Both US/EU will grant copyright to human output, not machine. You can claim it if your interaction/tuning with AI is nontrivial. But simple prompt is not enough - our (C) LyX Team might not apply for such code. - The AI model might have been trained on licensed code. Some output might be verbatim snippet from elsewhere. There are ongoing legal battles in what sense is training LLM tranformative enough, so it does (not) pose copyright infringement. Some paid services (like claude) grants the right to you and also give explicit umbrella legal cover in case you get sued. My current (practical) stance: - If you spent enough time with AI tuning or add 10% Transformation rule of thumb [2] (manual refactor/comments) it's ours. - If the changes are tiny targetted patches (see example below) the infringement is out of question, larger chunks can be also checked by snippet scanners (FOSSA,GitHub Copilot Guardrails). - Practicaly we could use commit tags like in other projects similar to e.g. Assisted-by: Anthropic Claude Code (Reviewed by Human) and use certificate of origin by sign-off as seen in kernel certifying that ... The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license ... c) Ethics. Very briefly and unpolished: Major AI companies are in different lawsuit stages that their models were trained or pirated data (books). They also probably took all OSS on the planet regardless the exact license, trained the models on it and now making large sums of cash based on the volunteer work. Nontrivial energy/environment footprint exists. My current stance is that whether training was fair or not, the genie is irreversibly out of the bottle and we should not restrain from using the fruit - or even better to ask for something like anthropic summer of code credits as a way to give the community back ;) The other issues are real and while they do not reach my current threshold I can totally see that other people would be strictly against. [1] https://redmonk.com/kholterhoff/2026/02/26/generative-ai-policy-landscape-in-open-source/ [2] https://www.thefirewall-blog.com/2026/04/ai-code-leak-exposes-the-fault-lines-of-copyright/ - To get some taste of possible workflow I am proposing, here you go: for more than a decade w
