Replies: 25 comments 108 replies
|
We don't currently have a policy but there have been more and more PRs and other interaction (comments, issues, etc.) that seem LLM-generated so I think it's getting time to adopt one. @archseer and I were discussing this the other day and we like Ghostty's policy: https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md. I think LLMs are good at certain tasks like building timelines or helping you dig into unfamiliar code. But it's very easy to abuse them to waste peoples' time. And I find the output quality pretty questionable most of the time. |
|
I have used helix for all of a month, specifically because it was not tainted by LLM shenanigans, so if it's tainted, I'll just stop using it... |
|
I've been using Helix for the better part of a few months. It's the editor that finally got me to give up emacs keybindings for modal editing, and I haven't looked back. LSP integration makes sense as an extensibility model -- it's as powerful, but not nearly as magical as Sublime or emacs (in a good way). Others above have already addressed how LLM corps are having negative impacts on the environment and open commons. I'll merely state that I do my best, as an individual to avoid LLM-contaminated work on ethical grounds... ... but there's a far more pragmatic reason to reject them: AI code contributions are not a good sign for the health of a project. Creating maintainable code (that is, maintainable without shelling out for a Claude/Gemini/etc... subscription) with an AI is presently hard. Numerous projects have complained about the maintenance overhead of trying to sort through AI slop pushes. Just cut it off at the source. There's also this well sourced list of complains. |
|
I have used helix for almost a year. I think rejecting AI contributions of any kind is the right call. |
|
I'll just add another vote in favor of standing against generative AI contributions because of the negative social and environmental impacts of the current wave of generative AI products. |
|
I really hope we can stand against AI contributions. I love Helix but if LLM contributions are not blocked I'll just have to move on to another editor. |
|
As a long time helix user who tries to avoid LLM poisoned code as much as practicable, I would be sad to see anything except a hard no-LLM stance from this wonderful project. The points I would make to support this have already been made above so I won’t repeat them, but one thing I would like to add: Just as with asbestos there were even many people trying to do the right thing, but didn’t know yet about all the harm it causes. With LLM generated text that looks like code we’ve already found many harms today, the low hanging fruit, the long term harm will only become visible later and I would love to see helix survive long-term. thanks ❤️ |
|
i heard that asbestos comparison in a tsoding stream, do you also watch? also sorry for unnecessary comment, delete it or tell me to delete it if its not welcome. |
|
I feel it would be completely unacceptable for the project to endorse GenAI in any way. This technology is deeply unethical and should be avoided as much as possible. At the very least, the project shouldn't allow GenAI contributions. Even better would be to be clearly against it in its entirely. I've already made a post at #15408 (reply in thread) but as there still has not been any response, I'm making a top-level one. |
|
Helix is now listed on open slopware. They have a procedure for getting delisted:
|
|
500 Internal Server Error |
|
The open slopware repository has moved: https://codeberg.org/ethical-foss/open-slopware Not sure why it's not redirecting, maybe be a Forgejo/Codeberg bug. |
|
ah yea that works |
|
just to add to the general sentiment here, i was very saddened to learn my previously favorite editor is open to being tainted. i hate to see it go, but without a clear and decisive anti-slop stance - helix cannot stay on my machines. |
|
… Fork it, then? Even if your fork is simply current main’s latest commit and never merges any (hand-picked non-LLM) PR ever again, that ought to be sufficient, no? It’s FOSS after all, and I’m not really sure why there’s so many people demanding something from the contributors when they themselves (for the most part) haven’t contributed anything. Just take Helix and make it your own as you please, if you hold such stark moral convictions. |
Or how about the people who want to dump LLM code into it fork it and dump the slop into their fork? |
Who said anything about slop? If that weren’t the case anymore, of course we’d have to lead a different discussion, one in which I’d actually agree with you. |
Slop is still slop even if a human looks at it and decides it's good enough. I mean, all the awful slop images posted online, someone looked at each of those and thought "Yeah, that's good enough, I'll post that". |
|
Is there a good reason not to reject LLM generated content? Edit 2026-07-16: |
|
I started looking into Helix when I learned Vim had accepted LLM commits. If y'all don't ban LLMs, I guess I'll have to keep looking. LLM coding isn't a long-term competitive advantage, and you're not going to be left behind without it. On the other hand, if you DO accept LLM commits, you're going to be left behind by any informed person with a conscience. |
|
Same here, I'm trying to decide what to use going forward. There's "Vim Classic" and Evi, but I'm not sure which will get better ongoing maintenance. So I thought I'd look at helix, but I'm not going to spend time learning a new editor if it's going to go the same route as Vim. |
|
I think the maintainer’s view is correct. Whether the code is written by AI doesn’t really matter — we can see it as an advanced form of automation. Over the years, many such tools have emerged, and we haven’t rejected them, have we? What matters is who takes responsibility for the code. Maintainers have already proven their ability through their contributions, and I believe AI is an enhancement for them. As for ordinary contributors, as long as they understand what the code does and take responsibility for it, I don’t see it as a big problem. Admittedly, allowing AI‑generated contributions may lead to a flood of low‑quality PRs, but we can handle this in various ways — for example, using AI tools for review, or setting up contribution tiers. New contributors’ PRs would be strictly reviewed, and after they build up a certain level of trust, the scrutiny can be relaxed appropriately. What I want to say is that AI has already changed the way software is developed. We should embrace it and figure out how to work with it. Simply rejecting it will only lead to being left behind. |
It's far from clear whether AI does actually reduce work burden the way AI promoters claim: https://archive.is/8wZZF
This is a full-on AI company talking point. I strongly suggest that you refrain from regurgitating those if you want polite responses. |
|
Sorry again, I will be more careful with my wording. |
While what you're saying here is definitely true, this is "AI" company propaganda, I feel this is worded a bit too strongly. I don't think @huxeon has any bad intentions. Anyone could fall for their propaganda. |
|
Chiming in to respond to the common talking point that GenAI is "just another tool." Lumping claude etc in with macros, autocomplete, snippets, linters, and the like really fails to engage with the problems people raise about their use. First, none of those other tools have the environmental, political, or ethical issues of GenAI, which immediately puts it into a separate category. |
Is the Helix team also a
…, which is what the study’s findings are limited on? |
|
With rsync recently facing numerous regressions after years of none of that, coinciding with the maintainer (a very competent and thorough person) beginning to use claude, i don't think there is such a thing as "using it well". If helix falls to this garbage, I will be version-locking it just like most of my system at this point. Like most software I use, helix is, when it comes to features i need, finished. It is usable as it is right now. The moment that is no longer guaranteed because randomly generated code is welcomed as long as it "looks good", I will gladly give up further bug fixes (even security fixes) and features for something stable. |
|
Maybe it would be a good idea to fork it, if we end up doing this. Revert all slop and then maintain it ourselves. Would prefer if it didn't come to this, however. |
|
I wouldn't mind using a fork if it comes to this, but I will only be switching if I see a need, I'm perfectly fine with a version lock for most things I use - again, most of my system at this point is version locked (which is a bit funny considering how much I despise debian and other "stable" distros). |
|
From a commenter on a similar thread: "simple question - why do you need AI in the <project>? are you not literate? this can be solved without AI…" Good thing I have by now found a way to version-lock arch linux entirely. Updates may or may not be missed. |
btw the mark of shame here is not removable, even if the commit is reverted later on. many people i know have blocked claude in order to get this exact warning and will not use projects where it appears.
helix has also already been listed on open-slopware with this new commit as evidence. |
|
Instead of constantly replying to this thread, reiterating the same thing a million times and threatening to not use helix anymore, you guys could you know, just not use helix if you think it's 'tainted.' |
|
If you go back and read carefully, you'll find that the arguments against GenAI are not that any one PR will crush the codebase -- that's your strawman. People have said that over time GenAI will create worse a codebase that is more difficult to maintain. They have also raised the many well established environmental and ethical harms of the production and use of GenAI. Many people (myself included) feel that the only good way to address these issues is to have an unambiguous "no llm" policy. That's what this discussion is about. Let's try to stay on track. |
|
I‘m not against the "no LLM" policy, if that is what the maintainers and the community expect. What I want to say is that @TudbuT , based on a single LLM-related commit, absolutely denies the value of this project and chooses to leave in a threatening manner—I don’t think that is the right attitude for a discussion. Some replies claim that AI will significantly reduce code quality, but no relevant data is provided. Instead, what I see is just emotional expression. Personally, I also dislike AI companies mindlessly hyping up its value, and I believe some people share a similar view. This is a discussion, and I hope it can be conducted in a more friendly and rational way. |
|
Eh, the downsides of LLM assistance are already being constantly debated elsewhere. I mainly just came to this thread to say "hey, I was planning on using some newfound free time to use and contribute to this cool helix project, but I was disappointed by the LLM commits and now I won't touch it until they're banned." And clearly, I'm not the only one reacting this way. |
|
@huxeon im not denying the value of the project. The project is very valuable to me, otherwise i wouldn't be here. But I am also saving myself the headache of dealing with LLM-generated code, by not updating when a project has it. I have brought up rsync before. Rsync is also a tool i value, and the versions following 3.4.1 have been full of regressions after introduction of much more LLM generated code, despite the dev being extremely competent. Before this happened, I hadn't version locked anything, I assumed it would be fine to trust the maintainers. It wasn't. |
The question, however, is whether the regressions were actually caused by the use of chatbots? Or is there another cause that just happens to coincide with the period since chatbots have been in use? According to the developer of rsync, he blames himself (https://lwn.net/Articles/1076479/). In addition, he was apparently flooded with reports of problems that he couldn’t handle on his own due to the sheer volume. I therefore see it as entirely possible that regressions would have occurred in rsync even if he hadn’t used chatbots. |
|
This is all great discussion, but I'm wondering where the maintainers are on establishing a GenAI/LLM policy. @the-mikedavis suggested on March 14 that helix should have a GenAI policy, and clearly a lot of people agree. Helix's governance structure remains a bit unclear to me. What are the processes for making this kind of decision? Whichever stance the policy ends up taking it would be good to have it established soon. If Helix comes down on a policy like that of ghostty, then those of us who want a hard line against GenAI can start looking for alternative solutions and contributors who are OK with it would have clear guidelines on what's acceptable and what's not. But as it is, there is a de facto policy of "sort of allowing GenAI but not necessarily any GenAI and whether GenAI use is declared is up to the PR author" which is I think not what anybody wants 😸 |
|
Just to preface, I am not a maintainer and my views do not reflect that of the team. My 5¢: the linked commit is very minimal and easily verifiable—the kind of thing that probably belongs in Clippy. The concerns that Helix will be filled with low-quality LLM-generated code do not correlate with what was actually merged into the codebase. Rejecting the PR would have meant having a human essentially copy-paste the exact same edit to accomplish the same performance benefit. That doesn’t provide any value. And regarding ethical concerns about AI—fair, but the Rust compiler itself accepts AI-generated code (as was recently demonstrated by them using Anthropic’s Mythos). So there would be an ethical compromise either way. I am personally in favor of Ghostty’s policy. Whether you are concerned about AI’s competency or have ethical concerns about AI, that genie’s out of the bottle and you’re not going to be able to put it back. That’s just the reality of the times we live in. Developers can refuse to use AI and consumers can refuse to adopt products developed with AI assistance, but I personally don’t see how that is going to go anywhere in the long-term compared to discussing how AI can be used ethically/responsibly (and criticizing when it’s not). Again, just my personal opinion. |
|
No more arguments left i see. Its personal beliefs all the way down, youd have had to disengage from the start |
|
I propose that this thread is closed at this point. |
Saying "open weight" is like saying "open binary". You don't have the sources, you only have the processed binary data. It's an openwashing phrase invented by the AI companies. |
There is no need for ad hominem attacks. Please be respectful just as I have respected your input. Discussion is healthy. I disengaged because I realized that I’ve already laid out my perspective, and that further engagement saw disagreement on a more fundamental level—such as our respective ethics on how to responsibly develop and use machine learning models, or even how we weigh harm versus good. Not because I had nothing more to say; I did! It might seem lame, but I’m a programmer. I want to be programming instead of continuing to research and debate. I don’t have the bandwidth for this discussion beyond the scope of what I originally intended. |
|
That wasnt ad hominem, but i digress. This extended reasoning for your disengagement does seem more reasonable. |
|
I think we're asking the wrong question. Whether AI wrote the first draft matters a lot less than whether the team understands the change they're merging. That's the part I worry about. As code generation gets cheaper, understanding the impact of a change becomes more valuable, not less. |
|
Ignores the massive ethical, environmental, social, political, etc reasons. The potential short-term development speed arguments don't hold a candle against these massive humanitarian issues. |
|
Also ignores the fact that you cannot properly understand LLM-written code. No matter how much you try to twist it, its still randomly generated code at the core, even though it is trained to "look good" - and it is very good at looking good. |
|
IMO prohibition means that people will still use GenAI to write their code and just conceal it's use, effectively doing what buildpl8 suggests in only merging understandable and manageable code. I agree that there are ethical, environmental, social and political reasons to debate about the proliferation of LLMs, but this seems like this is attacking the symptom and not the disease. If the maintainers only allow understandable and manageable code, then for instance society decides all LLMs should be unplugged, you're still left with a manageable codebase. The people can and IMO will use still GenAI to create PRs even if it's just for autocomplete suggestions when they are writing. |
|
Sure, some may lie, that's just life, and it shouldn't affect the policy. The important part is the rejection of this unethical technology, and joining the growing movement against it. Having a policy like this will also scare people who want to use GenAI away and they can go make their own slop text editor. |
|
I actually think that's the engineering challenge we're going to spend the next few years solving. Whether the code was written by a human or an AI, someone eventually has to understand how it fits into the rest of the system before it's merged. As generation gets faster, understanding becomes the bottleneck. That's the part I find interesting. |
|
I am not a professional programmer, instead I am just a random guy that did an Demy course to learn how to code in Rust and other computer related things. In this case, I cannot judge if the output of the LLM's are really good or acceptable, but reading the comments of @the-mikedavis , maybe it is not. And this view coincide with my view on my field, when I see that the contend generated by LLM's is low-level and easily spotted as slop and non-sense. @lumi-me-not raised a lot of serious questions about ethics, social, etc. These concerns are all extremely important, but actually most of people don't give a damn about them (not a surprise if you see the actual state of things). In my argument, I just want to point out that code made entirely by people is much more readable and easy to follow. Even me as a noob, when I go to repositories that are all human made code, I can at least understand the basics and get an idea of how things work. On the other hand, the same does not apply to LLM's repositories. For example, I was reading Helix code to understand better the internals, I could understand a lot of things. But, when I tried to do the same thing in Zed, it was impossible, because of tons and tons of LLM's slop and complexity added. If we start to accept LLM slop, this can easily get out of control and make the codebase impossible to read and understand. About the policy, I saw some people mention the Ghostty policy, but here is a big problem: everybody (especially noob's) think that they are "under control" of the LLM. So they will submit their slop anyway. The actual Ghostty way to do things is this: the core team uses LLM and they ban people to the hell in their GitHub (because their "permissive" AI policy bring a lot of "vibe-coders"). Also, we need to remember that Ghostty is a project of a billionaire that can do anything with his time, different for most of us that have to work to earn money and just dedicate time for Helix in our very limited free time. With so limited resources, I really doubt that it will be a good idea to spend time to "understand" and "identify" LLM code. From this point of view, I would suggest to adopt the same policy as Alacritty, to ban any kind of LLM use. This very restrictive and prohibited policy will keep away all the vibe-coders to enter here and destroy our codebase. Maybe in the future, with improvements and better regulations of the so-called AI Industry, we could review our position, but in the actual state of things, it is better to take a more restrictive approach. |
|
Well, throwing my two cents as someone who codes for a living: we're spending more and more time fixing the messes left behind by vibe coders than doing actual, useful work. |
|
chiming in as a long-time helix user, i was really disappointed to see the claude banner on the repo and if a strict no-llm policy is not established i'm afraid i'll have to find another editor, which i'm deeply not looking forward to. |
|
Considering we still don't have an answer from the maintainers, I'm glad someone's taking the initiative in forking. I will keep a close eye on this, thank you 👀 |
|
If they're not budging, we have to take things into our own hands and create an ethical fork of Helix. I love Helix, and I do not want to switch away. So this is the answer we've chosen. Feel free to tell other interested parties about this, so we can get the ball rolling. :) |
|
@lumi-me-not The hard fork hasn't happened yet, right? Because I can't find it in the repos lists. Btw, very cool project there! Will probably join the Zulip :) |
|
The fork is here: https://codeberg.org/polyphony/volute |
|
thank you, might switch to the fork if i end up needing anything beyond what my versionlock can give me |
|
Helix is my main editor nowadays, has been for the good part of three years now. And as much as I love it, personally I would drop it in a heartbeat if the project adopted a pro-AI policy, for the reasons better elaborated on by people in the comments above. I urge the project leader(s) and maintainers to reconsider. |
|
Adding my pitchfork and torch in support for anti-slop policy. I use Helix as my daily driver, it's a reliable tool and I hope it will stay this way. |
|
I, too, would like to see a no AI policy be adopted. |
|
Linus Torvalds has spoken: "[In response to a comment: It seems like [1] expresses a very anti-LLM position in general"] Yes. And no, that's not the position of the Linux kernel. I realize that some people really dislike AI, but this is an area where I'm willing to absolutely put my foot down as the top-level maintainer. Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away. AI is a tool, just like other tools we use. And it's clearly a useful one. It may not have been that "clearly" even just a year ago, but it's no longer in question today. There are other questions around AI (like what the economy of it will actually look like in the end), but "is it useful" is no longer one of those questions. Anybody who doubts that clearly hasn't actually used it. Yes, it can also be a somewhat painful tool, both for maintainer workloads and just from a "it keeps finding embarrassing bugs" standpoint. But the solution is not to put your head in the sand and sing "La La La, I can't hear you" at the top of your voice like some people seem to do. The solution is to make sure those LLM tools help maintainers instead of just causing them pain. There's no question on that side. We're not forcing anybody to use it, but I will very loudly ignore people who try to argue against other people from using it. And no, AI isn't perfect. But Christ, anybody who points to the problems at AI had better be looking in the mirror and pointing at themselves at the same time. Because it's not like natural intelligence is always all that great either. The kernel project has been and will continue to be about the technology. Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that's a side benefit, not the point of the project. This is NOT some kind of "social warrior" project, never has been, and never will be. In the kernel community we do open source because it results in better technology, not because of religious reasons. And so we make decisions primarily based on technical merit. Not fear of new tools. Linus" |
|
|
You know, I asked the original question in the manner I did so that it wouldn’t attract this kind of argument. Not because I don’t have an opinion on it (I do), but because it’s unfortunately almost certainly a waste of time to do so in this space. As far as I know, Helix still doesn’t have a policy on this. I’d rather not unsubscribe from the thread I created in the event that a policy is ever created. I’m not going to bother to reproduce every argument against LLMs I’ve had to make just to satisfy someone’s straw man argument for it because I’ve already had to do that, a million times, on social media. Please take this argument elsewhere. |
Gladly, and i already have. my kernel is on version 6.19.8-arch1-1 and staying there, and similarly helix is on version 25.07.1. If maintainers value their work little enough to support LLMs (which openly violate the license of their work for training data), i will follow in their footsteps and not value the updates "they" "make" (quotes because LLM use is not creation). After all, they acknowledged that worthlessness themselves. |
You can't be serious about not updating your kernel because Torvalds decided not to outright ban LLM usage? He didn't even say the kernel was adopting it, they just it wouldn't be banned outright. How is this not paranoia? |
How would it be? The kernel works perfectly fine as is and all the exploits that LLMs keep finding so far have been nothing burgers in my usecase. I don't need to concern myself with the code quality issues that come from using these things (and yes, i have tried them quite recently, both on existing projects with careful screening, and in the form of true vibe coding) if I can simply unlink myself from the impact of their use on software entirely. Plus, why would I want to use something that its own dev judged not worth their time? |
|
There have been a lot of important things brought up already, and believing those points have been made, I want to focus in on what I believe to be the poor fit for the project in general. Lack of ReviewersSome PRs have been open for years with no real direction or feedback on them. This has already been talked about elsewhere, but an inevitable influx of AI enthusiasts, should an Allow-AI stance be taken, who start to open PRs would just further take already starved reviewer time. From the many articles I have read, and from my own small bits of experimentation, the code produced from an LLM is maybe only 40% of the way there, as far as the shape it should actually have. And it often seems to have trouble with surrounding context, sometimes even for simple things. If a wave of PRs come in, which are only 40% along, rather than say 80% along, that's a lot of invested time to try to get those PRs ready. This is not to say there isn't a real problem to be solved, and that an LLM couldn't find bugs, but the "solutions" they provide are often very convoluted and have no "reasoning" besides the prompt that was given. Pro-AI projects invest a lot of time in their SKILLS or AGENTS files, to try to describe the constraints of the project, but I think time would be better served for us to invest in the current ARCHITECTURE/CONTRIBUTION files with more detailed information of the project. The quality of the normal hand-written PRs could go up, which in turn could make it easier on maintainers to review and merge. LLMs Are Bad With Deeply Integrated SystemsAlso from articles, videos, and my own experimentation, having LLMs try to make changes for multi-dimensional integrated systems, where there is more context than just the code provides, and where side-effects are important, the inability for them to "reason" about them, like a human would, is a huge drawback for these kinds of projects, which helix is (user UX, terminal environment, multi-OS, remote and local, LSP + Tree-Sitter integrated, etc.). Its similarly bad at systemic refactors. An Editor Is a Human InterfaceEven if there was a policy of just bug reports from LLM reviews, with a no generated code policy, this still misses the point of the human-natured aspect of the editor. Behavior (as mentioned above) is not well encoded; The reasons why matter just as much as how it's implemented. LLMs are bad at "reasoning" about these things. LLMs have no clue of the subtly of how helix is used. Helix is praised for the things that LLMs are bad at. ClosingUltimately, I think any kind of pro-AI policy doesn't help the project at all, and only leaves avenues to hurt it. The project would seem be better off on-boarding new reviewers, with a larger investment in documenting project constraints and behavior, than adding something that exacerbates present problems. The main things, to me, that the project needs most are not an influx of PRs adding some brand new shiny features, but around cleaning up the organic growth that happens as a project goes on in years; code is often just placed where convenient, and not where it ideally should be. This is something LLMs are bad at. In all, I think the project should try to avoid AI as much as possible, as it's a poor fit, and none of the benefits AI could provide help us all that much. If people use AI to try to understand something better, like I did when trying to figure out what part of the LSP spec covers hierarchical document symbols, cool, but as far as implementation, I believe we should ban LLM code and issues, which is effectively a no LLM policy. |
|
I think this recent Jon Gjengset video has an excellent part (which the link starts at) which touches the issues with LLM code. #16073 was recently opened that shows the issues of being unable to "reason" about side-effects of the code being generated. This is something that would take a lot to get to a reasonable state, which goes into my point about sinking reviewer time. In both cases, its not that there isn't an issue to solve, its that the implementation is suspect. There have been even more extreme versions of this on the project (like #13953) but I would hope that those are the outliers, and what I expect more are the 40%s.
This might be true for a single good person, but a projects needs are often not constrained to just one kind of contributor. I would think this would be understood, but I might as well state it plainly. I stand by my reasoning that allowing the use of LLMs is not a good fit for helix. Generating code is not a bottleneck for this project. Its mostly about having a philosophy of how users will interact/use things, and overall about how different systems will interact, and this needs reviewer time as well as dogfooding. These are often subtle, but an avid user, and someone who was exposed to the early process, can mostly arrive by themselves. From my own experience, one that I have seen others share, is that the early shapes of the code (first 20-30%) are where the final shape is discovered. Using an LLM for this stage just discards this process. It wont discover anything, as it does not learn, but instead just tries to bolt its solution on to the existing shape. Google just put out a blog which describes this process as "prefactoring". This is something LLMs are pretty bad at, as stated above. |
|
@RoloEdits Regarding:
Like many of the points above, this point is true if the coding agent is used in a certain basic way. I've learned with coding agents, like with any tool, the quality of the output relies on how well the human can use it, not on the quality of the tool. I know we programmers pride ourselves on our craftsmanship, but I'd venture to say that most programmers just don't know how to use coding agents well yet. It's a difficult learning process. From experience, I know that the right prompts can steer the coding agent away from the above pitfall. Furthermore, you can automate a coding agent's general strategy with AGENTS.md (or CLAUDE.md, etc) file in a repo so that it does the right thing even when someone doesn't give all the right context in a single session. But crafting those instructions takes care and trial and error. I'm not invested in Helix except as a casual user, but I'm a long-time programmer who prides myself on well-crafted code. I'm deeply into integrating coding agents into my coding flow at this point, and I think this project could benefit from them. This project may already be getting many quality coding agent-assisted PRs, they just might be missing what you think of as the tell-tale signs. Some things I've seen help with project PR management:
|
|
No true scotsman, or something like that. I think that this thread would benefit from keeping it on topic. Many people expressed the desire to adopt a stance. You may not agree with that stance, however the description of your process is off topic. |
|
#16135 was opened with what I think many would deem a "trivial" change ( This is why I think a full ban would be best. LLMs are just a bad fit for a project which has many subtle interactions. |
|
It's not like open source software is a competition. Just because you feel like "it's falling behind" is not at all a reason to start taking shortcuts. |
|
Stop this crap discussion! And push an update... |
|
“rust-lang/rust is adopting an LLM policy”
Seems similar to the Ghostty policy, at least philosophically. From a purely pragmatic perspective, I don’t know how to enforce a ban on LLM-generated code. I don’t believe it would stop people submitting it. It would only stop them being open about having used an agent. Most of the obvious tells are trivially prompted away. Personally, I’d rather dispense with the pretence and at least know where it came from. |
|
From a purely pragmatic perspective, I don’t know how to enforce a ban on stolen proprietary code. I don’t believe it would stop people submitting it. It would only stop them being open about having stolen it. Copyright messages are trivially removed. Personally, I’d rather dispense with the pretense and at least know it was stolen. |
|
Call it what you like. What’s your plan for detecting it? |
|
It's weird that this keeps being framed as if maintainers and PR contributors are inherently adversaries. It's not necessary to have an ironclad system for detecting LLM-generated PRs, because contributors using LLMs will often just tell you, or they'll see the policy and understand that their help isn't welcome here, and be disincentivized from contributing. That messaging is part of the value of a policy like this. But yes, some contributors ARE adversarial. There are many ways to spot them, and seeing slop code is just one of them. In any case, social rules do not require bulletproof detection mechanisms to be useful. See e.g. almost any law ever written. |
|
@elbowo is exactly right. If contributers are trying actively and surreptitiously to undermine a project or break its rules, then that is a separate issue from the specific rules that are made. It is also not a problem that will be solved by technical measures like detection. To the degree that open source models of software development do work, their functioning relies as much on social mechanisms as it does on technical ones. Trust, reputation, norms of interaction, and the ability to assume good faith are load-bearing for open source development. Discussions around genai tend to move immediately to an assumption of adversarial contributers -- especially by those who are promoting the use of genai. I think that tendency can tell us something important about the kind of contributions and community generative ai suports. |
and others
Uh oh!
There was an error while loading. Please reload this page.
Hello!
I've just been checking out Helix recently, and I quite enjoy what I've seen so far! It's fast, intuitive, ships a lot of nice defaults, and works well with what I've used it for thus far!
I apologize if this has been asked before (I was unable to find anything discussing it previously); I was curious if the project had any specific guidelines on whether it would be utilizing LLMs as part of the development process, or whether the project would accept PRs that had involved Claude, CoPilot, ChatGPT, etc, in some fashion?
(My own personal interest in asking is that I am actively disinterested in using software stacks that incorporate the usage of LLMs anymore than I am forced to).
Thank you!
All reactions