Re: Claude AI code audit of GNUstep core stack — 1 50 fixes, 12 perf optimizations, all available for upstream
Gregory Casamento <[email protected]> Fri, 10 Jul 2026 10:07:33 -0400
| Newsgroups | gmane.comp.lib.gnustep.devel |
|---|---|
| Message-ID | <CA+BLX-wbH1id3uWpXCOk=vuF3SNq09=N3pWGpN6=OyzD-pu3bw@mail.gmail.com> |
--000000000000a4bf2106564244d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Riccardo Mottola <riccardo.mottola@= libero.it> 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=E2=80=99t intend to triage anything else coming from your plagiaris= m 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 > > --=20 Gregory Casamento GNUstep Lead Developer / Black Lotus, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.openhub.net/languages/objective_c --000000000000a4bf2106564244d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac= e,monospace">Riccardo,</div><div class=3D"gmail_default" style=3D"font-fami= ly:monospace,monospace"><br></div><div class=3D"gmail_default" style=3D"fon= t-family:monospace,monospace">Slowing us down is hardly the concern, though= it is one factor.</div><div class=3D"gmail_default" style=3D"font-family:m= onospace,monospace"><br></div><div class=3D"gmail_default" style=3D"font-fa= mily:monospace,monospace">We have already discussed and outlined a policy r= egarding this.=C2=A0 It was discussed about 2 months ago days after a previ= ous weekend meeting, due to Fred's concerns.</div><div class=3D"gmail_d= efault" style=3D"font-family:monospace,monospace"><br></div><div class=3D"g= mail_default" style=3D"font-family:monospace,monospace">I don't think w= e should regulate HOW the code we accept is written, only the code that is = submitted to us.</div><div class=3D"gmail_default" style=3D"font-family:mon= ospace,monospace"><br></div><div class=3D"gmail_default" style=3D"font-fami= ly:monospace,monospace"><b>It is a practical impossibility to enforce your = proposal.</b>=C2=A0 Where do you draw the line between AI-Generated code an= d AI-assisted?=C2=A0 Do you ban <span aria-invalid=3D"grammar" class=3D"Lm = ng" style=3D"border-style:none;background:none">autocompleted</span>=C2=A0c= ode, refactoring, bug detection, and boilerplate code?=C2=A0 Even Emacs has= a .el extension to interface with OpenAI or Claude, etc.=C2=A0 Also, some = IDEs allow users to do code transformation.</div><div class=3D"gmail_defaul= t" style=3D"font-family:monospace,monospace"><br></div><div class=3D"gmail_= default" style=3D"font-family:monospace,monospace"><b>We have historically = judged code on quality, correctness, and maintainability.=C2=A0</b> =C2=A0I= f a patch doesn't meet these standards, it's rejected.=C2=A0 =C2=A0= If it does, how it was produced, so long as it fits the existing policy wit= h respect to AI already outlined and as long as the user discloses its use,= should not=C2=A0be an issue.</div><div class=3D"gmail_default" style=3D"fo= nt-family:monospace,monospace"><br></div><div class=3D"gmail_default" style= =3D"font-family:monospace,monospace"><b>Code review is the best quality che= ck, and requiring potential contributors to stand behind their contribution= s and be able to explain them is crucial.=C2=A0 Policing the development pr= ocess in a way that is unenforceable=C2=A0is not.</b></div><div class=3D"gm= ail_default" style=3D"font-family:monospace,monospace"><br></div><div class= =3D"gmail_default" style=3D""><font face=3D"monospace, monospace">Also, the= idea that "AI-free" is a selling point is very questionable.=C2= =A0 People adopt us because of GNUstep's=C2=A0portability, stability, a= nd API compatibility (such as it is)... not because the contributors used c= ertain tools to write the code.=C2=A0 =C2=A0</font><span style=3D"backgroun= d-color:transparent"><font face=3D"monospace">A blanket prohibition also ri= sks discouraging capable contributors who responsibly use AI-assisted tools= while still fully understanding and standing behind their code.</font></sp= an></div><div class=3D"gmail_default" style=3D"font-family:monospace,monosp= ace"><br></div><div class=3D"gmail_default" style=3D"font-family:monospace,= monospace">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.= =C2=A0 =C2=A0We accept only well-reviewed, well-engineered, and well-unders= tood code REGARDLESS of how an initial draft was produced.</div><div class= =3D"gmail_default" style=3D"font-family:monospace,monospace"><br></div><div= class=3D"gmail_default" style=3D"font-family:monospace,monospace">So your = "act now" sentiment, while understood, is hardly needed as we alr= eady acted as discussed.=C2=A0 There was a post to this mailing list regard= ing this very subject that outlined the policy.</div><div class=3D"gmail_de= fault" style=3D"font-family:monospace,monospace"><br></div><div class=3D"gm= ail_default" style=3D"font-family:monospace,monospace">Yours, GC</div></div= ><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" clas= s=3D"gmail_attr">On Fri, Jul 10, 2026 at 4:06=E2=80=AFAM Riccardo Mottola &= lt;<a href=3D"mailto:[email protected]">[email protected]= </a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:= 0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">= Hi,<br> <br> <br> David Chisnall wrote:<br> > For various ethical reasons, I would prefer that you did not.=C2=A0 I = have <br> > no desire to contribute to the various harms that these systems are <b= r> > responsible for.<br> ><br> > Given the very low signal to noise ratio from the reports so far, I <b= r> > don=E2=80=99t intend to triage anything else coming from your plagiari= sm machine.<br> <br> I perfectly understand your position and essentially share it. I am <br> mulling over this theme again and again.<br> <br> Two main uses currently on the code for AI are:<br> 1. analysis, bug hunting: essentially "discovery".<br> 2. actual vibe coding, generation. "Agentic"<br> <br> I understand that 1) causes a lot of "noise", but the bug may be = <br> legitimate. At the end it is like a super-scanner or super-analyzer. <br> Often things lack context or use the wrong contest. Still I'd consider = <br> them legitimate, the issue is drowning in them.<br> <br> ><br> > Other parts of GNUstep may have different policies.<br> <br> I would propose to forbid AI generated code in all core packages (i.e. <br> everything on <a href=3D"http://gnustep.org" rel=3D"noreferrer" target=3D"_= blank">gnustep.org</a>, in gap, gnustep-nonfsf) and proudly badge the <br> project as "coded by humans". Or "AI free".<br> I have seen this in several projects now, it could be a good selling <br> point especially in a "niche" project. For whatever ethical reaso= ns <br> (trust, ethics, ecc) more and more people are looking for non-AI things. <b= r> We could be included in such projects.<br> <br> Of course anybody using a derivative project (e.g. Ambrosia) is free to <br= > use AI, but the vice-versa is no longer true!<br> <br> <br> Other will argue that this could slow us down, but it would be good to <br> have a selling point. An interesting freedom point.<br> <br> We must "act now". We can revert the decision later, but vice-ver= sa <br> could be painful.<br> <br> Riccardo<br> <br> </blockquote></div><div><br clear=3D"all"></div><div><br></div><span class= =3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s= ignature"><div dir=3D"ltr"><div dir=3D"ltr"><div><div dir=3D"ltr"><font fac= e=3D"monospace">Gregory Casamento<br>GNUstep Lead Developer / Black Lotus, = Principal Consultant<br><a href=3D"http://www.gnustep.org" target=3D"_blank= ">http://www.gnustep.org</a> - <a href=3D"http://heronsperch.blogspot.com" = target=3D"_blank">http://heronsperch.blogspot.com</a><br></font></div></div= ><div dir=3D"ltr"><font color=3D"#888888" face=3D"monospace"><a href=3D"htt= ps://www.openhub.net/languages/objective_c" style=3D"color:rgb(17,85,204)" = target=3D"_blank">https://www.openhub.net/languages/objective_c</a></font><= /div></div></div></div> --000000000000a4bf2106564244d3--