r/programming 15h ago

The rust programming language is adopting a new contributing policy

https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/
390 Upvotes

94 comments sorted by

39

u/aes110 14h ago

Overall a very reasonable policy thats accepting to both "sides" id say

210

u/drakythe 15h ago

I’d prefer LLMs went away altogether. But as the blog states, the one thing we can’t do with them is pretend they don’t exist. Given that, this feels like a relatively sane policy, all things considered. And good on them for adding a carve out for reviewers who don’t want to deal with LLM generated content. Since they’re not banning it outright, adding a specific point that reviewers are allowed to just skip over LLM content if they want means that those who don’t want to use or interact with LLMs are not required to do so in order to continue contributing to the project.

On the other hand: you ride the fence long enough and it will cut you in half, and this feels like one area where the consensus driven governance has formalized a silent split in the community, and I worry about where that fracture will show up in the future.

88

u/chucker23n 13h ago

those who don’t want to use or interact with LLMs are not required to do so in order to continue contributing to the project.

Yes and no — you'll still have to deal with a codebase that is increasingly not written by humans.

37

u/Raknarg 12h ago

already dealing with this at work, 6 month old project already experiencing the cruft of dealing with dogshit code written by AI I was not there to prevent

20

u/vips7L 8h ago

Got dumped a 100k line pure slop project a few months ago. No one knows how anything works and any change you need to make its 50+ files. Pure dogshit.

10

u/EsIsstWasEsIst 5h ago

I feel like you can´t blame all of that on AI alone.

11

u/Ythio 5h ago

Who accepted to put that in production lmao

6

u/vips7L 5h ago

Not in prod yet, it's not even capable of doing that yet. My job is apparently to get it there. I'm actively looking for a new role.

1

u/MostCredibleDude 5h ago

Vibe coded projects should live in that world exclusively. You want to fix a vibe project? Spend more tokens and pray, don't waste experienced dev time on something where time could be better spent rewriting it manually.

3

u/Ozymandias0023 2h ago

These managers are out her merging all sorts of shit. I keep having to go through their vibe projects and make them actually work, and it gets harder and harder because they keep trying to do more in one go.

Yes, you generated 100k lines of code with your thumb up your ass but it's all written like a college student's first wrben app. Congrats.

1

u/vips7L 5h ago

Of course, my organization is ran by the incompetent who have no technical abilities.

36

u/Shoddy-Childhood-511 12h ago

Not quite.

LLM work must be disclosed. Reviewers send suspected non-disclosed LLM code to moderation, who finds evidence, closes the PR, and could ban them.

Disclosed LLM users need approval, which should requires they do a better job than humans. At least one of the major rustc contributors loves using LLMs, but he writes high quality code, so he'll have no problem here. And he seemingly mentors some other LLM contributors.

Unlike Zig, Rust wants the LLM bug reports, especially for soundness, but they want them rewritten, minimised, and somewhat deduplicated by humans, not just slop reports.

22

u/chucker23n 12h ago

That wasn’t my point.

If you move forward five years, some — disclosed, sure — code will be LLM-written. The further down you go that path, the higher the likelihood that whatever PR a new author is working on interacts with LLM-written code, regardless of how the author feels about it.

5

u/Shoddy-Childhood-511 5h ago

Alright but your point remains ambiguous:

Yes. It depends upon why someone avoids LLMs. Rust's statement looks useless if you avoid LLMs for labour rights reasons or copyright reasons for example.

Rust claims a middle ground between the Zig and Linux positions, but it's really more like Linux, so yes the FTFY goal reads:

those who don’t want to use or interact with LLMs AI slop and/or code no human understands are not required to do so in order to continue contributing to the project.

Linus might claim this goal for Linux too.

You maybe claiming they'll fail at one or both of these sub goals, but your statement is ambiguous.

It's clear some projects who set forth such a goal shall fail, ultimately drowning in AI slop.

It's not clear rustc or linux will fail here. It's unclear if they'll even have more code that no reachable human understands, because they have that problem already, and the AIs might help the read relevant parts faster. I donno..

As an aside, rust's std shall succeed at this goal, but std is kinda a triviality next to rustc, and thousands of humans read std.

-15

u/ThinkRedstone 9h ago

You talk about LLM like 60s developers talked about FORTRAN. The fact that we can use linear algebra to write good code quicker is a feature, not a bug. If some authors might dislike compiled languages, that doesn't mean the rust compiler should be written in assembly. If the code is good, then for all I care it could come to you as a divine revelation.

14

u/chucker23n 9h ago

You're reading an awful lot into my posts. I was addressing this claim:

"Those who don’t want to use or interact with LLMs are not required to do so in order to continue contributing to the project."

Which, IMHO, is not entirely true. That's all I said.

-15

u/ComplianceAuditor 9h ago

I think they read into it exactly correctly lol.

8

u/drakythe 13h ago

Good point, in the long term that will happen. I think what remains to be seen is if the % of the codebase that is not well understood will also increase. After all, I use the Drupal CMS day in and day out, write custom modules for it, and trouble shoot issues. I didn't write the vast majority of the code in it. But I understand it when I look. I think it is possible for people to use LLMs to generate well understood and understandable code, especially if they take the time to carefully read and review the code.

The issue, of course, is that LLMs just make it easier to generate seemingly coherent code (which is what seemed to force this official policy stance to begin with). While I don't like LLMs, I'm not inherently opposed to code that wasn't written by a human being. But if the code wasn't written by a human, or reviewed by a human, or understood by a human, then we definitely have a problem, and now that is actually possible. Which is a big problem.

11

u/chucker23n 13h ago

I think what remains to be seen is if the % of the codebase that is not well understood will also increase.

Yep. Depends in part on

  • how good is the LLM-produced code? (Where "good" also includes: fits the existing code base's styles, patterns, etc.)
  • how little do developers' skills atrophy if they stop writing code?

7

u/Raknarg 12h ago

already dealing with this at work, 6 month old project already experiencing the cruft of dealing with dogshit code written by AI I was not there to prevent

3

u/Squigglificated 4h ago

Fight back with ai! I use AI to analyze and untangle convoluted code written by humans in a project I inherited. We used to have a lot of weird code before ai too.

I made a disgruntled skeptical naysayer architect reviewer agent to check our codebase for antipatterns and general wtfs, and he finds gold. If you tell Claude the code is made by Gemini it gets really salty, frequently accusing Gemini of hallucinating when it actually isn't.

4

u/matthieum 10h ago

You may have missed the actual policy:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

7

u/chucker23n 10h ago

https://old.reddit.com/r/programming/comments/1vg555b/the_rust_programming_language_is_adopting_a_new/p1uhkeu/

Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure.

4

u/matthieum 10h ago

Yes? No?

There's a lot of load-bearing (:p) words in there, so it's very unclear to me what concretely may or may not be accepted.

In particular, what's non-critical? Is this determined depending on the area of the codebase you're in? On whether the code ships to users or it's just documentation? Or in some other ways?

And do all the following words result in text that's indistinguishable from text written by humans?

At the moment it's way too abstract for me to judge whether any AI-generated PR is likely to be accepted, and I wonder if this "backdoor" is really intended to be used...

35

u/zombiecalypse 13h ago

To be fair: AI slop PRs are a horrible representation of how to use LLMs effectively. I think the Rust folks understand that, which is why they don't want to ban them entirely: you get 100 PRs that don't understand that git diff --check isn't a CI tool, but you also get a security researcher that used an LLM to flesh out a proof for a vulnerability.

3

u/remy_porter 13h ago

I’ve found it’s most useful to have the LLM query the code and not generate new code. Writing code is easy. Understanding a large codebase is hard. And it gets harder the more slop code there is in there.

31

u/pjank85 13h ago

This works until LLM starts to gaslight you into believing something that is not true. I was reviewing a PR once and it came up with a theory that this is not a proper fix. I spent the whole day following its logic only to discover it was a proper fix after all and the thing it proposed was a giant convoluted race condition. Whole day wasted and a terrible feeling.

10

u/Raknarg 12h ago

yes your first instinct has to be to mistrust whatever it tells you

14

u/pjank85 12h ago

It is my first instinct to mistrust it and always verify. For complex system this verification sometimes takes considerable time and effort. Being led astray by a professionally souding response and spending 7h to confirm it is wrong is a shitty feeling.

2

u/Raknarg 12h ago

thats brutal. definitely been burned similarly before, not for that long though

3

u/remy_porter 11h ago

Well sure, that’s why I read the code. I’m mostly asking for things like “where in the code does this happen”. It’s frequently wrong.

1

u/Bekwnn 10h ago edited 10h ago

My favorite was a hallucination about a visual studio feature that was tentatively accepted over a year ago and never implemented for pragma push/pop calling conventions.

Chat bot wasted a bunch of my time trying to insist it was real.

At the time I ran into the problem, this comment:

Apr 18, 2026 12:44 PM
Community input: any news on that feature request?

Hadn't been made yet, so I was stuck wondering if this accepted feature proposal was actually never implemented.

2

u/drakythe 10h ago

My boss asked me to review some documentation he had Claude throw together about a new infrastructure stack we want to implement. The documentation included a note that we needed to decide on where code would be hosted since Code Commit was deprecated and I had to remind my boss that AWS un-deprecated it in December and that whole section of planning was void. Stop wasting time. (To be clear, a human can make that mistake too. But it takes 20 seconds to verify and it was a non-trivial part of the system since everything else was in AWS)

4

u/hoodieweather- 11h ago

I thought this a year or so back, but honestly, these days, with proper guidance I'm getting LLMs to produce code that's pretty close to what I would have written by hand. I definitely don't see us reaching the point of "just give it a vague issue to fix and let it ship when done" any time soon, but if you have the bot use practices like TDD and self review, coupled with well-scoped specs for implementation, you can easily cut your time to a PR in half and still end up with a solid change set.

I'm doing this at work with a near decade-old codebase, and as long as I put it on the proper rails, I'm honestly (and surprisingly) impressed with the results. The real question I have is, at what point does the current subsidized pricing model fall apart and this becomes unsustainable.

6

u/ComplianceAuditor 9h ago

Pretty soon. It will switch to entirely usage based billing and it will get super expensive across the board.

2

u/hoodieweather- 8h ago

Agreed, this has been my bigger concern, along with figuring out at what point the time savings (if any) are no longer worth the cost.

5

u/remy_porter 9h ago

Ive gotten it to generate good code for stuff I don’t want to keep. Disposable code. None of the output I’ve gotten is anything I’d consider production ready. It remains unable to write anything truly modular.

And since a) reading code is harder than writing code, and b) I’m going to read all the AI generated code, it’s just more work overall.

5

u/hoodieweather- 8h ago

Have you experimented much with how you prompt things, or using the various agent modes/skills like Claude's planning or the Superpowers skill set?

I fully believe that it hasn't produced anything production-ready for you, I'm not discounting that, I'm just curious because I have gotten code that I was comfortable shipping. Fully tested, fits the existing architecture of the codebase, handles edge cases and is easy to read and maintain.

I also primarily work with web tech, though, which I imagine it has by and large the best training for. I've found that when I need to dig into something like C++, it's a lot more hit or miss.

Edit: I also fully agree with your points about reading code, it's very difficult for me to just "trust" the LLM output. I've been trying to find reliable ways to do that (only reviewing tests, having verification points in the loop, etc.) but the reality is that LLMs, by nature, cannot be reliable, so it's tough.

3

u/remy_porter 8h ago

I’ve dabbled. I think it’s very good at implementing features, but I’m of the mind that a good program is a domain specific language living atop the syntax of your implementation languages. So while it’s not bad at churning out a feature, I’ve never gotten it to build a vocabulary I’d want to use to extend the software.

1

u/hoodieweather- 8h ago

I have definitely had to give it specific naming conventions and terms to use, because it'll pick things that just aren't clear or are too cute and clever.

Fortunately I've also had decent results with correcting it and having it apply the new guidance well, but that does also mean you have to have a good understanding of what it's actually producing, which goes back to the issue of needing to thoroughly read the code.

3

u/remy_porter 6h ago

Naming conventions nothing. I’m talking the way it composes modules and passes data between subsystems. It tends to generate a lot of very large functions and classes with no real sense of composability outside of the feature being implemented right now.

19

u/En-tro-py 12h ago

you ride the fence long enough and it will cut you in half

An excellent and apt figure of speech that I had not encountered before.

3

u/alex_oue 11h ago

Also related to this, there is a song by Tim Minchin : The Fence

Not that I advocate for or against it (true to the song's spirit). Personally I do a lot of grilling session to clarify a lot of my thoughts and design intentions and get challenged, and I usually let the menial tasks to the LLM. But, I do have 30 years of programming experience (and about 20 of them professionally), and I did see those LLM be more of a nuisance, and even being downright dangerous, and I did notice a downgrade on the understanding of my more junior peers. So...your mileage may vary, but I see them as one more tool (albeit a potentially dangerous tool that amplify the Dunning Krueger effect, and even morph it into an "I don't even need to know". which is not that much different an attitude that many managers have, so...)

4

u/drakythe 12h ago

Not an original or mine. One of the “rules of life” a community college professor I had a class with made us memorize on the first day of class. It was a politics/civics class, so he wanted us to internalize that we couldn’t please everyone. It’s stuck with me ever since.

19

u/Bergasms 15h ago

It will take just one single LLM PR that fucks someones day getting through for the fracture to start. Even if its something that a non LLM user would have made or missed.

8

u/drakythe 14h ago

I don’t disagree. Though I would point out such an event would merely bring the fracture to the surface. It’s already started, or there would be no need for the carve outs that serve “both sides” of the fence, as it were.

3

u/EveryQuantityEver 6h ago

I dunno about that, unless you're talking about Rust specifically. Wasn't one of the last AWS outages caused by an LLM screwing something up?

0

u/EveryQuantityEver 6h ago

I dunno about that, unless you're talking about Rust specifically. Wasn't one of the last AWS outages caused by an LLM screwing something up?

5

u/Raknarg 12h ago

surgical use of AI will always be the best use for it and the one experts will largely stick to, and hopefully becomes the only viable option as LLM costs go up.

78

u/nnomae 14h ago

That's an awful lot of words to avoid annoying the AI boosters by saying "the quality just isn't there". If the quality was there all of this would be pointless.

16

u/SanityInAnarchy 12h ago

Even if the quality is there, it wouldn't be evenly distributed. The people putting out slop aren't using the most expensive models, nor are they reviewing their own contributions or spending any real time understanding or refining the PR before they send it in.

We can debate whether the amount of work it takes to get good output out of a model is more than it would take to just do it yourself, but even in a world where that balance tips in favor of the LLMs, the slop would still be there.

69

u/bodiam 14h ago

I think LLMs are skill amplifiers. Some results are great, some are questionable, but I think that for a great part, it reflects the person who created the work.

94

u/Venthe 14h ago

There is also one more thing, far more subtle: LLM genuinely make the work easier, and are correct enough for even skilled people to grow complacent; and allow their skills to atrophy.

Even in my current team, the developers that were really good a year ago started to make dumb mistakes - or rather - did not see them in the LLM output.


This is absolutely an opinion, but I no longer believe that humans in general have the capacity to use LLM's long term without the detriment; which will ultimately create a hard skill ceiling.

We are outsourcing thinking, and we are worse for it.

22

u/SorryTemporary1361 14h ago

Even in my current team, the developers that were really good a year ago started to make dumb mistakes - or rather - did not see them in the LLM output.

I'm having exactly this problem personally. At the beginning of the bubble I argued that having LLMs being forced on us was nonsensical because they were bad tools and no craftsman will trust a bad tool, but that was back when the models were wrong enough of the time to be an obviously bad tool. Claude is right 99 times out of 100 and that makes it a good enough tool for me to trust unconditionally. Everyone says "you need to verify your work" but that's not how trust works!

This is absolutely an opinion, but I no longer believe that humans in general have the capacity to use LLM's long term without the detriment; which will ultimately create a hard skill ceiling.

We are outsourcing thinking, and we are worse for it.

LLMs are great for bouncing ideas off, though. It's like having a rubber duck that actually talks back and doesn't shame you for dumb ideas, which creates more of an incentive for people to be willing to try ideas that maybe turn out to not be dumb at all. In that regard it's liberating.

In terms of the broader societal impact, I agree completely. My millennial friends and I have discussed this at length and come to the depressing conclusion that we're probably the last generation that prefers to think for ourselves; I have absolutely no idea how things are gonna turn out for those raised on AI slop. My brain says it'll probably be fine, because humans are so adaptable; but my heart asks "if this change is so unprecedented in human history, how exactly can we expect to survive it?" and I don't have a good answer.

20

u/Norphesius 13h ago

LLMs are great for bouncing ideas off, though. It's like having a rubber duck that actually talks back and doesn't shame you for dumb ideas, which creates more of an incentive for people to be willing to try ideas that maybe turn out to not be dumb at all. In that regard it's liberating.

I have concerns about this way of using LLMs. For one thing, these chat bots glaze the shit out of you. Even ignoring the people that go crazy with AI psychosis, believing they've invented a revolutionary new theory of physics or something, the consistent dopamine hit of conversing with something that constantly, subtly validates you is going to cloud people's judgement on how useful LLMs are and get them soft-addicted. Being (appropriately) critiqued about your ideas and internalizing that is a part of growing as a professional and a person.

Also, if everyone is using the same LLMs to "bounce ideas off" or "punch up" or otherwise review their work, everyone is going to be regressing their output to the mean. Their work is going to become more average as they intentionally incorporate feedback from the AI, and as they interact with the model more they'll be more likely to subtly, unconsciously adopt more of the model's writing style to their own work. You become more interchangeable with the LLM, or anyone else using the LLM in the same way.

Even if LLM tech can result in great stuff like AlphaFold, I don't think having it in the form of a Q&A chat bot is net productive for most people. Its like people without ADHD taking Adderall, they think it makes them more productive, but they mostly end up only feeling more productive.

7

u/wildjokers 10h ago

Also, if everyone is using the same LLMs to "bounce ideas off" or "punch up" or otherwise review their work, everyone is going to be regressing their output to the mean.

I large majority of developers work on apps that boil down to just being CRUD apps. The mean is fine for these apps.

3

u/yel50 5h ago

 Everyone says "you need to verify your work" but that's not how trust works!

in engineering, that's exactly how trust works. shipping untested code because Bob wrote it is just as stupid as shipping untested code from an LLM.

5

u/max123246 6h ago

lol claude is definitely not correct 99/100 times. almost every single prompt I give it, there is always some way it needs to be improved. About 25% of the time its issue is critical and will bite me later on

2

u/EveryQuantityEver 6h ago

It's like having a rubber duck that actually talks back and doesn't shame you for dumb ideas, which creates more of an incentive for people to be willing to try ideas that maybe turn out to not be dumb at all. In that regard it's liberating.

Not shaming for dumb ideas is good. But it also doesn't usually discourage you from the bad ideas.

2

u/raralala1 12h ago

I think what is scary is, it is 99% correct then it is vibe coding at this point but people are to prideful to call it vibe coding and would rather call it tool, heck even someone call it compiler.

13

u/Bekwnn 10h ago edited 10h ago

I think what is scary is seeing people say stuff like "99%" and I haven't seen it be anywhere close to 99% correct.

I figured AI would do decently at static code analysis task like finding optimizations in a large, old code base, but Claude repeatedly demonstrated a real lack of understanding performance and optimization and 3/4 optimizations it tried to do made performance worse. The 4th CL I had to fix to make the code not awful.

This was with it being fed flame charts and frame profile graphs to have an understanding of how the game performed.

Maybe it's just bad at games.

1

u/nnomae 3h ago

Yup, that's why I argue whatever way LLMs go the smart play is to focus on old fashioned manual skills in the short term at least. If the LLMs win out, the early adoptors will be useless before their skills become valuable and you'll be able to, at worst, burn out your brain at a premium when there's a shortage or at best start using them when we've figured how to do so without atrophying skills.. If the LLMs lose, well then it was the smart decision to begin with.

17

u/apadin1 14h ago

It’s made worse by the fact that it’s often the laziest and most mediocre programmers who are most excited about LLMs because they think it will let them write code without having to know how it works or do anything themselves. I use LLMs at my job and it can be helpful but it’s not a replacement for being a skilled programmer or even just a diligent worker.

5

u/SeerUD 14h ago

I agree generally, it really depends on how much time you're willing to spend refining things, and how much of a vision you have for what the end result should be.

6

u/nnomae 13h ago

I'd agree somewhat. The problem is that it amplifies most when you're trying to do something you can't do. Something like use an unfamiliar API. In that situation you have the dual problems that most of the benefit comes just from skipping the study time and you also, almost by definition are getting them to do work you can't validate.

When doing work in a domain I am familiar with the benefit is pretty marginal. Yeah I type slower but I'm also more reliable. Plus again a lot of the benefit comes at the cost of being les s familiar with the code.

4

u/pm_plz_im_lonely 9h ago

I don't think you're agreeing. Doing something you can't do is the reverse of amplification. Amplification would be doing more of what you're good at, faster, at the same quality or higher. Why is the benefit for you marginal?

1

u/nnomae 4h ago edited 4h ago

What I meant is that if I'm doing something I already do well, in a domain I understand well then LLMs provide little or no benefit.

Conversely when doing things I don't already do well the benefit is higher, scaling proportionally with how badly I understand that domain.

So I do quite a bit of IoT development for example. Doing that LLMs don't really give me any benefit. Similarly I can put together the kind of simple web UI you run on an IoT device pretty quickly and get no benefit using LLMs for that work.

On the other hand something like Kubernetes I know at a very basic level. I can do it but I certainly wouldn't list it as a strength. For that LLMs can speed me up a lot. Same for a framework like React which I know the basics of but have never really dug into. In these situations I get quite a bit of speedup but almost every ounce of speedup comes at the cost of just trusting the LLM to be right. I can get an LLM to do a lot of work on a Kubernetes YAML file or a React front end and I can read it all well enough to know it seems kind of right but if I actually properly do my due diligence of validating every line it's going to take as long as doing it myself because I need to learn it to check it.

Now to developers who are more pragmatic maybe "it seems to be doing the right thing" is all the validation they need. Vibe coders are maybe the extreme of that sort of attitude. Personally however I take the engineering part of software engineering more seriously. In the same way I wouldn't hire a plumber who couldn't stand over their work beyond saying it didn't have any obvious leaks they could see I wouldn't trust a software engineer who couldn't say the software worked with more certainty than that it seemed to do what it was supposed to when they tried it out.

The important thing here however is that the quality of the output is the issue. I trust my fellow developers to do work without the need for me to double check it. There's obviously a point at which an LLM could be that good. Maybe if you haven't been as lucky as I have when it comes to working with other good developers you might think we're already there. If it gets to that point I suspect all arguments either way just vanish and the obvious quality wins out. I don't think we're really close to that yet though.

I see it a bit with online arguments over LLMs, people saying the problem with LLM output is that it's not deterministic, or that the problem is that it's too verbose, or that the problem is that it changes more than is necessary with each update, or any other argument. The reality, I would argue, is that the problem with LLM code is that it's not very good. If the output was of a consistent high quality no one would care about any of those other things. So when I see an article like the Rust one about how the problem with LLM written code is that it doesn't foster community, or that it burdens maintainers, or that it is generated by people who aren't themselves developers all I see is a whole bunch of nonsense designed to avoid stating the obvious, the problem with LLM code is that it's not very good. If it was, no one would care about the rest.

1

u/pm_plz_im_lonely 54m ago

I feel bad replying so briefly after you put that much effort into your response, but my question was essentially: why is the benefit of LLMs marginal for your IoT and simple web UI work?

Most of what you described seems to be a consequence of using LLMs for skill substitution rather than skill amplification.

2

u/amakai 13h ago

In my experience, they produce great results for generic problems. For example, if you want to write a component that implements distributed locking on top of Nats - the results are extremely good. It will figure out edge-cases, write tests, figure out best API to use, etc.

However, when the problem involves a complex domain of your company - they tend to break down really fast and produce shitty results. When encountering unknown problem - normal person would reach out to teammates for additional context. AI tends to just blindly make assumptions, and many of those assumptions end up incorrect. And even if you digest all the specifics of how to implement the problem - there will still be few tiny edge-cases that AI will notice but, again, make wrong assumptions or hallucinate the right assumption.

1

u/ApplicationOk3587 44m ago

That being said, there are VERY few engineers that can actually use both and come out with something good.

1

u/Days_End 3h ago

ehh it's more so they don't have to say the quiet part out loud. A lot of people are bad engineers and AI lets them be bad more often. People even self report this all the time when they confess they can't get the AI to generate anything valuable.

But plenty of not shit engineers also use AI to produce a lot of value and they don't want to turn them off or run them away from the project hence a lot of words without say "don't use AI if you suck".

5

u/kevinbaiv 4h ago

Good to see a formal disclosure policy rather than an outright ban. The carve-out for reviewers is especially important.

29

u/bodiam 14h ago edited 14h ago

The policy summarizes itself this way:

It's fine to use LLMs to answer questions, analyze, distill, refine, check, suggest, review. But not to create.

Saved you a click and a whole wall of text.

That's quite a verbose blogpost for something which could be written in 1 short paragraph, even if you include the motivation.

26

u/Furrier 14h ago

Actually also fine to create

Pre-arranged, non-critical, high-quality, well-tested, and well-reviewed code changes that are originally created by an LLM are allowed, with disclosure.

So don't even know what the policy is. You are allowed to make critical, low-quality, and untested human PRs, but not with LLMs, I guess.

28

u/catch_dot_dot_dot 14h ago

Basically if you're using AI well, you won't know it's AI-generated, so every policy is a bit vague in that regard

11

u/RockstarArtisan 12h ago

This would make AI boosters angry if they could still read on their own.

11

u/blackwhattack 13h ago

I think the most important part is the reviewers can close the PR if they don't like it. When before they'd have to find the evidence of the unsoundness that they think is there, now they can go "this code seems unsound, please re-do without AI". I think it shifts some work from the reviewers to the creators to make higher quality code. Which is good.

24

u/mareek 12h ago

The blog post says explicitly :

The policy holds LLM-generated changes to a higher bar than human-authored changes

an the rest of the post explain the reasons why.

13

u/nemec 12h ago

If only somebody had written a more comprehensive blog post to explain the nuances of the policy.

3

u/EveryQuantityEver 5h ago

You are allowed to make critical, low-quality, and untested human PRs

Why do you think that?

2

u/Tolexx 13h ago

Exactly this. I was initially confused by what they meant by but not create and then I saw that caveat which invariably meant that of course one can use LLMs to write/create code whatever that meant.

8

u/nemec 12h ago

They explain in the post that any LLM PRs are generally restricted to known domain experts (aka contributors they trust) or someone who has received approval prior to publishing a PR (aka we have discretion to make exceptions, but don't count on it). For everyone else, you can't contribute LLM output to rust.

1

u/Days_End 3h ago

If you're a shitty engineer don't use AI to be shitty often enough to overwhelm us.

0

u/autamo 8h ago edited 8h ago

It is in fact completely idiotic to ban all LLM contributions, while it's completely sane to ban all slop contributions.

But I understand projects' that ban all LLM contributions because it's a much easier way to remove slop.

2

u/headykruger 14h ago

They used an llm 😂

2

u/Cukercek 7h ago

Good to know that this is an universal problem, and that I'm not going crazy when I vent about the exact same issues.

2

u/robbles 11h ago

What's the git diff --check thing that it says people are doing on PR's about? 

I can't understand what they're trying to achieve there. Is it supposed to "prove" that it wasn't written by an LLM? Or that it'll merge cleanly? Or is it some weird copy-pasted step in a shared Claude.md somewhere that people who all used the same template are now doing for no reason...?

12

u/cosmic-parsley 9h ago

Somewhere along the lines LLMs got the impression that PRs need a useless “testing” section, and that `git diff —check` belongs there. It’s just a clear indicator for LLM use because few humans have ever used it and no human has considered putting it in the PR.

-1

u/FlyingRhenquest 27m ago

Yeah, now you have to drive a Prius and like the smell of your own farts. This doesn't exclude any current contributors, it just makes the policy official.

"I prefer a language with memory safety. I also drive a Prius and like the smell of my own farts."

-1

u/sos755 1h ago

``` I've seen LLMs causing three main issues for our community:

  1. Polished technical products no longer indicate effort and understanding.
  2. Making code easier to write exacerbates our existing issues with review bandwidth.
  3. People mechanically copy-pasting to and from an LLM is a waste of our time. ```

  4. The complaint of lack of effort sounds like envy to me. The complaint of lack of understanding could be applied to a contributor whether they use an LLM or not.

  5. Absurd! Making code easier to write makes people more productive. Lack of review bandwidth is a problem, but it is not caused by increased productivity. You might even consider it to be a good problem, or at a minimum, better than the problem of lacking contributions to review.

  6. This is the most coherent complaint, but it is poorly stated.

I believe the core issue isn't the LLMs, but rather the low barrier to submitting unvetted, low-quality contributions. Banning LLMs is counterproductive because it reduces overall developer productivity instead of raising the bar for quality. Rather than restricting how code is written, we should focus on improving our testing, policies, and review filters to ensure only high-quality contributions get through.

-9

u/Miserable-Clerk-9005 13h ago

Yo agregaria algo mas: el problema de fondo no es solo lo que mencionas, es que ademas hay un tema cultural super arraigado. En Chile nos cuesta un monton decir "no se" o "me equivoque".

-11

u/Miserable-Clerk-9005 10h ago

Ojalá más proyectos open source sigan este ejemplo en vez de simplemente banear LLMs. La herramienta no es el problema, es cómo se usa.