Riccardo, Slowing us down is hardly the concern, though it is one factor.
We have already discussed and outlined a policy regarding this. It was discussed about 2 months ago days after a previous weekend meeting, due to Fred's concerns. I don't think we should regulate HOW the code we accept is written, only the code that is submitted to us. *It is a practical impossibility to enforce your proposal.* Where do you draw the line between AI-Generated code and AI-assisted? Do you ban autocompleted code, refactoring, bug detection, and boilerplate code? Even Emacs has a .el extension to interface with OpenAI or Claude, etc. Also, some IDEs allow users to do code transformation. *We have historically judged code on quality, correctness, and maintainability. * If a patch doesn't meet these standards, it's rejected. If it does, how it was produced, so long as it fits the existing policy with respect to AI already outlined and as long as the user discloses its use, should not be an issue. *Code review is the best quality check, and requiring potential contributors to stand behind their contributions and be able to explain them is crucial. Policing the development process in a way that is unenforceable is not.* Also, the idea that "AI-free" is a selling point is very questionable. People adopt us because of GNUstep's portability, stability, and API compatibility (such as it is)... not because the contributors used certain tools to write the code. A blanket prohibition also risks discouraging capable contributors who responsibly use AI-assisted tools while still fully understanding and standing behind their code. If we want a selling point, I'd say we stick with the one we already discussed on the mailing list previously with respect to review. We accept only well-reviewed, well-engineered, and well-understood code REGARDLESS of how an initial draft was produced. So your "act now" sentiment, while understood, is hardly needed as we already acted as discussed. There was a post to this mailing list regarding this very subject that outlined the policy. Yours, GC On Fri, Jul 10, 2026 at 4:06 AM Riccardo Mottola <[email protected]> wrote: > Hi, > > > David Chisnall wrote: > > For various ethical reasons, I would prefer that you did not. I have > > no desire to contribute to the various harms that these systems are > > responsible for. > > > > Given the very low signal to noise ratio from the reports so far, I > > don’t intend to triage anything else coming from your plagiarism machine. > > I perfectly understand your position and essentially share it. I am > mulling over this theme again and again. > > Two main uses currently on the code for AI are: > 1. analysis, bug hunting: essentially "discovery". > 2. actual vibe coding, generation. "Agentic" > > I understand that 1) causes a lot of "noise", but the bug may be > legitimate. At the end it is like a super-scanner or super-analyzer. > Often things lack context or use the wrong contest. Still I'd consider > them legitimate, the issue is drowning in them. > > > > > Other parts of GNUstep may have different policies. > > I would propose to forbid AI generated code in all core packages (i.e. > everything on gnustep.org, in gap, gnustep-nonfsf) and proudly badge the > project as "coded by humans". Or "AI free". > I have seen this in several projects now, it could be a good selling > point especially in a "niche" project. For whatever ethical reasons > (trust, ethics, ecc) more and more people are looking for non-AI things. > We could be included in such projects. > > Of course anybody using a derivative project (e.g. Ambrosia) is free to > use AI, but the vice-versa is no longer true! > > > Other will argue that this could slow us down, but it would be good to > have a selling point. An interesting freedom point. > > We must "act now". We can revert the decision later, but vice-versa > could be painful. > > Riccardo > > -- Gregory Casamento GNUstep Lead Developer / Black Lotus, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.openhub.net/languages/objective_c
