Re: Claude AI code audit of GNUstep core stack — 1 50 fixes, 12 perf optimizations, all available for upstream

--00000000000059d8ed064f5c7322
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Ricardo,

This first pass was very much meant as a test of Claude Code against a well
optimized codebase - GNUStep has many hours of work by those "Skilled in
the art...". Unlike assessing an early career programmer's code, our
internal expectation was that this would be a real test for Claude (as
compared to a first pass through some "vibe coding" script build) given how
much runtime GNUStep has had over the years. Internally we use GNUStep for
high performance computational biology in multithreaded environments with
CUDA code.  My colleague Tom MacSween and I have been coding in Objective-C
since the NeXT days.

The intention of this experiment was to see what it would find and suggest
in a few passes. The first pass (which I presented above) was Claude Opus
4.6's initial instrumentation test. We checked the changes to ensure they
compile and pass basic unit and performance metrics tests. As some of you
noted, and most of us would agree, that is not the same as being exercised
in real production code environments.

The next pass, which we are working through now is actually performance
testing these changes in our own internal tests to see if we see any
performance increases. As we are montioring it, Claude is finding
situations where it is saying "Oh, I think I made a mistake... need to
revert my change." - so it will be interesting to see where it ends up.

What we will do is, as Richard asked, break each change out if it passes
our internal testing, and make them seperate commits if we can, then it can
be assessed individually by the maintainers for suitability to the project
repos. We have made the first pass available just to make you aware of what
the experiment is showing so far. For us internally, multi-threaded
performance and server-side considerations are our goal, but we are going
to take a reasonable pass through the GUI tools as well and see what it
thinks - but we won't be aggressively testing them ourselves. At David's
direction - we'll not submit anything for libobjc2.

Regards,

Todd


On Mon, Apr 13, 2026 at 2:32=E2=80=AFPM Riccardo Mottola <riccardo.mottola@=
libero.it>
wrote:

> Hi Todd,
>
> Todd White wrote:
> >
> > https://github.com/DTW-Thalion/gnustep-audit
> >
> > I wanted to share what we found and offer to contribute any or all of
> > the changes back upstream.
>
> Thanks for the work.
> I would best prefer to have separate PR-s so that each one can be
> analyzed, refuted, reworked or changed on.
> At a first glance, I cherry-picked a couple of commits in base and gui,
> there are interesting points to be analyzed.
>
> LLM generated suggestions are a hot topic these days, also among our
> community. On one side the question about ethics, on the other the noise
> they generate. Some members feel pressed by the generation of requests.
> Some project have banned them completely. I hope we don't bring GNUstep
> to that point, but keep a good line of usage.
>
> I have seen other attempts in AI usage with some fellow coders here, the
> advantage of here that the commits are retained atomic and so easier to
> single-check, refute or rewrite.
>
> I find it interesting that the whole codebase was checked.
>
>
> Question: Are any of these issues you found directly related to real
> bugs you found and open issues? Are you actively using GNUstep code?
> Or are the bugs found only by AI itself.
>
> I see some choices debatable, e.g. enlarging cache and buffer values,
> without hard data. Or using certain atomics function: this might work in
> specific environments, but break others. Having separate commits makes
> it easier to test, including running our own test suite (as limited as
> it currently is, though, in terms of architectures)
>
> Regards,
>
> Riccardo
>

--00000000000059d8ed064f5c7322
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:arial,sa=
ns-serif">Hi Ricardo,</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,sans-serif">This first pass was very much meant as a test of Cla=
ude Code against=C2=A0a well optimized codebase - GNUStep has many hours of=
 work by those &quot;Skilled in the art...&quot;. Unlike assessing an early=
 career programmer&#39;s code, our internal expectation was that this would=
 be a real test for Claude (as compared to a first pass=C2=A0through some &=
quot;vibe coding&quot; script build) given how much runtime GNUStep has had=
 over the years. Internally we use GNUStep for high performance computation=
al biology in multithreaded environments with CUDA code.=C2=A0 My colleague=
 Tom MacSween and I have been coding in Objective-C since the NeXT days.=C2=
=A0</div><div class=3D"gmail_default" style=3D"font-family:arial,sans-serif=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,sans-se=
rif">The intention of this experiment was to see what it would find and sug=
gest in a few passes. The first pass (which I presented above) was Claude O=
pus 4.6&#39;s initial instrumentation test.=C2=A0We checked the changes to =
ensure they compile and pass basic unit and performance metrics tests. As s=
ome of you noted, and most of us would agree, that is not the same as being=
 exercised in real production code environments.</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,sans-serif"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,sans-serif">The next pass, which we a=
re working through now is actually performance testing these changes in our=
 own internal tests to see if we see any performance increases. As we are m=
ontioring it, Claude is finding situations where it is saying &quot;Oh, I t=
hink I made a mistake... need to revert my change.&quot; - so it will be in=
teresting to see where it ends up.<br><br>What we will do is, as Richard as=
ked, break each change out if it passes our internal testing, and make them=
 seperate commits if we can, then it can be assessed individually by the ma=
intainers for suitability to the project repos. We have made the first pass=
 available just to make you aware of what the experiment is showing so far.=
 For us internally, multi-threaded performance and server-side consideratio=
ns are our goal, but we are going to take a reasonable pass through the GUI=
 tools as well and see what it thinks - but we won&#39;t be aggressively te=
sting them ourselves. At David&#39;s direction - we&#39;ll not submit anyth=
ing for libobjc2.</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,sans-serif"><br></div><div class=3D"gmail_default" style=3D"font-family=
:arial,sans-serif">Regards,</div><div class=3D"gmail_default" style=3D"font=
-family:arial,sans-serif"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,sans-serif">Todd</div><div class=3D"gmail_default" style=
=3D"font-family:arial,sans-serif"><br></div></div><br><div class=3D"gmail_q=
uote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, A=
pr 13, 2026 at 2:32=E2=80=AFPM Riccardo Mottola &lt;<a href=3D"mailto:ricca=
[email protected]">[email protected]</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">Hi Todd,<br>
<br>
Todd White wrote:<br>
&gt;<br>
&gt; <a href=3D"https://github.com/DTW-Thalion/gnustep-audit" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/DTW-Thalion/gnustep-audit</a><br=
>
&gt;<br>
&gt; I wanted to share what we found and offer to contribute any or all of =
<br>
&gt; the changes back upstream.<br>
<br>
Thanks for the work.<br>
I would best prefer to have separate PR-s so that each one can be <br>
analyzed, refuted, reworked or changed on.<br>
At a first glance, I cherry-picked a couple of commits in base and gui, <br=
>
there are interesting points to be analyzed.<br>
<br>
LLM generated suggestions are a hot topic these days, also among our <br>
community. On one side the question about ethics, on the other the noise <b=
r>
they generate. Some members feel pressed by the generation of requests. <br=
>
Some project have banned them completely. I hope we don&#39;t bring GNUstep=
 <br>
to that point, but keep a good line of usage.<br>
<br>
I have seen other attempts in AI usage with some fellow coders here, the <b=
r>
advantage of here that the commits are retained atomic and so easier to <br=
>
single-check, refute or rewrite.<br>
<br>
I find it interesting that the whole codebase was checked.<br>
<br>
<br>
Question: Are any of these issues you found directly related to real <br>
bugs you found and open issues? Are you actively using GNUstep code?<br>
Or are the bugs found only by AI itself.<br>
<br>
I see some choices debatable, e.g. enlarging cache and buffer values, <br>
without hard data. Or using certain atomics function: this might work in <b=
r>
specific environments, but break others. Having separate commits makes <br>
it easier to test, including running our own test suite (as limited as <br>
it currently is, though, in terms of architectures)<br>
<br>
Regards,<br>
<br>
Riccardo<br>
</blockquote></div>

--00000000000059d8ed064f5c7322--