• monkyyy (10/10) Jun 26 If the upstream devs is going to start using ai, this should be
• Adam Wilson (11/16) Jun 27 This is entirely impossible to do in practice. Under your
• monkyyy (25/29) Jun 27 No matter how much you use ai, you will not effect libcurl or

monkyyy <crazymonkyyy gmail.com> writes:

If the upstream devs is going to start using ai, this should be 
preemptively segmented into a new namespace, perhaps `bracca`. 
Rather then trying to clean up a mess later, in the event 
copyright law suddenly declares you must back pay if you used ai 
trained on gnu code.

So if someday someone hooks up a full agent ai, people anti this 
move can do things like write lint rules to ban that import, or 
different standards could be used for ai vs human code; the 
quality difference could be easier to measure and see.

etc. etc. etc.

Adam Wilson <flyboynw gmail.com> writes:

On Friday, 26 June 2026 at 19:34:37 UTC, monkyyy wrote:
 If the upstream devs is going to start using ai, this should be 
 preemptively segmented into a new namespace, perhaps `bracca`. 
 Rather then trying to clean up a mess later, in the event 
 copyright law suddenly declares you must back pay if you used 
 ai trained on gnu code.

This is entirely impossible to do in practice. Under your 
proposal, anybody who lets LLM's touch any part of code base 
would force that module into the "LLM segment" of the StdLib. 
Which means that in short order all of the StdLib would end up in 
the "LLM segment" and you have no StdLib to use as an anti-LLM 
person.

The harsh reality is that LLM's are here to stay. And we need to 
figure out how to incorporate them into our workflows. And "ban 
them" isn't a valid long-term answer.

Is what it is. Probably better to just accept it now.

monkyyy <crazymonkyyy gmail.com> writes:

On Saturday, 27 June 2026 at 11:12:27 UTC, Adam Wilson wrote:
 
 This is entirely impossible to do in practice. The harsh 
 reality is that LLM's are here to stay

No matter how much you use ai, you will not effect libcurl or 
ssl; when they throw mythical ai at curl they find 1 bug, if we 
look at the the wrapper of curl in d it gots 3 patches in 2024 
https://github.com/dlang/phobos/commits/v2.112.0/std/net/curl.d I 
hope they continue to be human written and rare.

If you rewrite curl with ai; your bad at your job.

---

Separation of concerns has always been part of api design; no 
only is it possible that security code is segmented, apparently 
we've luckly had someone preemptively structure things to make it 
hard to change that, lest we see your clawdbot attempt a rust 
rewrite "inevitably".

The world hasnt adapted yet, but ai can make all the websites for 
all I care, but there should be more nist-cyptro contests that 
get as much care and attention as the hoover dam; for being what 
they are, infrastructure.

Ai cant lay a foundation. A human written core of 100 lines of 
code and a few rants surrounded by 1000000 lines of ai slop can 
do allot but protecting that core is important.

I would suggest not allowing any rust rewrites of any part of the 
d std no matter what your clawbot says its inevitably, the 
future, safe, or mandated by the chips act or the europe 
equivalent. Hot take.

 And "ban them" isn't a valid long-term answer.

I quite explicitly did not say to ban it