- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
lobsters score: 1 · tags: vibecoding
You must log in or register to comment.
This seems like a facile and biased analysis.
I actually think point 2 (the Debian position) should not be dismissed so easily. The author states that the slop will just seep in inexorably without really arguing that position.
Maybe we should take time to figure out (and spell out for would-be contributors) what exactly responsible AI entails. Maybe it means that you can use AI to find bugs, but not actually write code, for example. Or instead it could mean only optional tools can have AI contributions. So for example if you have a programming language project, the language server could be written using AI because it’s an optional tool.
score 1 · canonical
When you think about it, contributors who are completely turned away by the fact that they can’t use LLMs are probably contributors you don’t want in your project, even if you have a Debian-like “moderate use of AI” position.
If a project says, “No AI,” then I absolutely respect that. Nothing which has been touched by AI in any way will be sent to that project. This is pretty clearly what a lot of people with that policy want. They ethically object to any use of LLMs. It’s a matter of moral purity, not a practical question. I wouldn’t offer them something that involved AI at any point any more than I would offer a vegan something that had touched butter.
Let me give you an example: I was working on a distributed word frequency estimator. Before I left for a meeting, I asked Claude to check the distributed counts and see if it could find anything interesting. Claude found some weirdness in the numbers, and—completely unasked—it started digging around in one of the open source libraries I was using. It found a nasty and very subtle bug in the open source library.
So now I have a problem: I know about a serious bug. But it was found entirely using AI. As lawyers like to say, it was “fruit of the poisoned tree.” There is no way that I can retroactively remove AI from the process.
Now, that author had no policy against AI contributions. So I hand-wrote a nice bug report and offered to fix it. Fascinatingly, Claude made a subtle mistake in its proposed fix to the algorithm. But both I and the upstream author made exactly the same mistake Claude did the first times we tried to fix it. The only thing that actually fixed the bug was when I (or maybe Claude at my request?) wrote some proptests, which found a super tricky edge case. (I actually think the incomplete fix is present in some academic papers about the algorithm, IIRC. I’m still not even 100% sure that the final fix was correct, but it holds up under a quarter million randomly generated test cases checking various mathematical properties, which is a good start.)
So that’s my dilemma: Sometimes a coding agent will find bugs in someone else’s code. These may be subtle correctness bugs, or data corruption bugs, or serious security vulnerabilities. And if I discover one of these bugs, there’s a decent chance AI will be involved in some way. This is because my first reflex when someone else’s library does something weird is to ask the nearest coding agent to take a look. Life’s too short to debug things like treesitter myself when an agent will almost always find the problem in 2-5 minutes. I may have to fix the problem myself, and of course I’ll write my own commit messages and PRs.
But if you have a strict zero AI policy, then I’m going to assume that you’re doing it on moral grounds. Which puts me in the awkward position of knowing that your code is computing incorrect answers, or corrupting user data, or leaving your users vulnerable to attack. And then I have to guess whether you want to know about a bug discovered using AI. If you have a strict no-AI policy, I’m not going to hide the AI use.
In practice, if it’s a security bug, I’ll probably verify the bug carefully by hand and disclose it to you via a private channel, if I can find one. For other bugs, I may switch to another library, or just quietly fork yours. Which feels antisocial. But given how many “no AI” policies feel like ritual purity laws (nothing wrong with ritual purity laws!), I don’t want to inflict AI-discovered bugs on people who are strongly anti-AI.
On my personal projects, I actually have a mix of AI policies. I will normally close slop feature PRs without reading. Slop bug-fix PRs, well, I’ll either read them myself, or if the PR is too annoying, and confused, I’ll ask my own agent whether the “bug” is real. A few of my projects are “learning” projects, and these will forbid all AI-written code, because the point is learning. Or sometimes my policy is “trusted maintainers can use AI if they want, but we’ll reject slop feature PRs from other people.”
score 2 · canonical
AI itself is fruit of the poisoned tree.
If you pay somebody else to care for your children, you don’t get to complain if you encounter issues integrating with your children’s lives. Are you part of the family or not? Ethics isn’t one of many possible stances you can take to having a family, it is the very basis of relating to other human beings. If you choose to ignore humans in endeavours that fundamentally involve humans, then you are the problem, not the humans.
Do parents that pay for carers have a “dilemma” about being involved with their often cold and standoffish children? No. Or rather it’s disingenuous to frame it as a dilemma. The blame is squarely at the feet of the parents.
Sure, I get it, we’re so much more productive when we get a third-party to care on our behalf. But that comes at a price, one of which is losing our voice.
Open source is our child. It doesn’t demand anything other than that we acknowledge it. Copy it, sell it, change it, make it your own. All it asks is that you attribute your sources. It’s a profoundly simply contract. If you can’t even achieve that most basic of tasks, then it’s hardly surprising that you’ll be troubled by more challenging tasks further down the line.
AI does not care for the welfare of our ecosystem. That is the security issue. It is a logistical impossibility to steer a thriving and successful community towards integrating with a technology that undermines its core principles. As we should all know, attacking software takes many forms, it’s not just about exploiting bugs, it can also be about denial of service and social engineering. So to even suggest that anti-AI policies create a dilemma for pro-AI users finding bugs and vulnerabilities is a misleading framing of the reality of the situation.
You cannot both care that you find bugs in open source software and not care about the provenance of your LLM output. The consequences of not caring are entirely on you, not the ecosystem.
score 1 · canonical
Have you actually encountered someone who refuses bug reports found due to the use of LLMs?
Focusing on individuals is going to lead to outliers so maybe that looking at collectives is better. GCC refuses LLM-generated code but accepts LLM-generated testcases. Codeberg refuses LLM-generated code too and says nothing about bug reports (and non-code?!). Both cite unclear copyright status which is another indicationg that bug reports, usecases, testcases and investigations are fine.
Let’s say I object completely to the use of fossil fuel. Am I going to complain that the ambulance that takes me is using fossil fuel? Am I going to skip eating vegetables because they’ve been transported in a truck or because the farmer used a tractor? Or vegans who would refuse to talk to non-vegans?
You’ll find plenty of people who refuse to touch some stuff but basically none of them will refuse to touch what is a couple steps away already. Of course, not all of these steps are equal but you get the idea.
The people you’re wondering about basically don’t exist. Those who do are zealots; they’re a minority. I reckon that keyboards tend to turn people into zealots unfortunately so you’ll probably find more online than offline. Still, that’s going to be fairly few people and people whom you probably already didn’t want to interact with if possible.
Don’t worry. Simply mention how you found the bug and the other person will decide.
(BTW, to be clear, I don’t think you were trying to build a straw man, quite the contrary)
score 1 · canonical
Your comment is a good one and I think does a good job of highlighting that current AI policies are drawing the boundary in a weird place.
I think the distinction many teams actually want to make is: was every line in this codebase read, understood, and accepted by a human or not?
There are valid arguments in both directions:
-
Codebases where the answer is “yes” mean that there is a human who is claiming some level of accountability and responsibility for the code. Not in a legal sense for most open source licenses, of course. But in a “can I trust that a person gave a shit about this?” sense. Humans bring a whole cloud of moral and social values with them and when a human accepts some code, it means we can more likely trust it in the large diffuse sense of the term “trust”.
It is more likely that the codebase will continue to be maintained in the future because people have already invested real effort into it.
-
Codebases where the answer is “no” can grow and add features much more rapidly. I don’t think anyone knows what the long-term maintainability of vibe-coded programs is yet, but at least short-term it seems like AI can whip up a whole lot of mostly working code really fast.
So I think really where the policy line should be drawn is at code review. Does a human review every line of code or not?
The challenge is that if you have a policy that says “yes” but don’t have a policy discouraging using AI to generate code, you will rapidly overload the reviewers. So the policy line gets drawn earlier at the point of authoring to try to avoid that. But I think then it runs into all of the problems that the parent comment here are talking about where it’s not clear if a contribution or bug report is “tainted” by AI or not.
I suspect there is another approach one could take here that is a little more mechanical about the code. Maybe have a rule that says all PRs above a certain line count are auto-rejected unless a previous design discussion with maintainers has occurred.
Of course, if you object to the use of AI on moral/ethical grounds, I also think it is valid to have a policy that outright rejects all contributions tainted with AI in any way. But I think that’s a somewhat different problem being solved than AI policies that are mostly trying to deal with not overloading human reviewers.
score 2 · canonical
But I think that’s a somewhat different problem being solved than AI policies that are mostly trying to deal with not overloading human reviewers.
I don’t think it’s that clear-cut either. There are also projects that use the mechanical policies as an excuse to not have to have the ethical discussion (yet).
score 1 · canonical
as an excuse to not have to have the ethical discussion (yet)
I think you’ll find, if you look closely, that the people who have major ethical concerns about LLM usage are a vocal minority and that many projects and communities won’t be having that discussion because they don’t believe a problem worth discussing actually exists.
I’ve been digging quite a bit into how different major projects and communities have come to the conclusions they’ve come to so far and there are very stark differences there. There also seems to be a pretty interesting split with respect to whether project leadership themselves have any interest in hearing or engaging with the perspectives of non-contributors.
score 1 · canonical
What’s your basis for thinking people with ethical concerns are a vocal minority? As one data point, when Rust project members were solicited for feedback, around half of them brought up ethical and environmental concerns.
score 1 · canonical
That’s the really interesting part for me, to be honest: how clustered it is. It comes as no surprise to me that the Rust community has that big of a response to it. I say this neutrally: from an outsider that has used a number of different languages and ecosystems, the Rust community seems markedly different in their mixing of software development and social causes. Rust is a cool but small pocket in the overall software development landscape.
I’ve also looked at the minutes from some significant open source foundations’ board meetings on the topic that looked about 15 minutes long. Often one board member would raise some kind of concern (environmental, provenance, etc) and not argue too hard for it. Policy agreed to (most popular: humans take responsibility of the code, don’t submit vibecode or machine-authored PRs). Done.
And some did have quite thoughtful discussions that ultimately went one way or another. I don’t have numbers for active developers for a bunch of different languages and projects. I’d be happy to see good numbers either way.
score 1 · canonical
I say this neutrally: from an outsider that has used a number of different languages and ecosystems, the Rust community seems markedly different in their mixing of software development and social causes.
To understand your message better, what makes Rust “markedly different” here, specifically?
score 1 · canonical
I don’t mean it in any kind of derogatory way if that’s what you’re asking. The community itself is quite new compared to, say, the C++ community and baked a lot of values and governance into the project very early on. The fact that they do surveys like https://blog.rust-lang.org/2026/03/02/2025-State-Of-Rust-Survey-results/ and explicitly include metrics on different marginalized groups speaks to the fact that their objective isn’t just “make a memory-safe programming language” but to include community, inclusivity, and ethics into the core of the organization.
Other large projects are starting to do that too, but it’s usually more of a bolt-on / slow shift affair rather than having baked those values into the core from the beginning.
score 1 · canonical
-
I have this exact problem at the moment. There’s a bug in click-default-group which I opened 3 years ago and then failed to resolve without AI.
The other day I pointed Claude at it and got a simple one-line fix. Then I read the governing AI policy which made it clear that, with no exceptions, my solution that had been found with the help of AI was not welcome:
If your contribution looks like it was generated by such tools, or you attempt to obfuscate that, it will be closed and you are likely to be blocked.
I’m not going to obfuscate it - that would be unethical.
It’s a one-line fix. I’ve now seen it, so my knowledge of the fix is polluted.
So I guess I leave that issue open and hope someone else stumbles across the same fix that I did!
score 1 · canonical
It’s a one-line fix. I’ve now seen it, so my knowledge of the fix is polluted.
So I guess I leave that issue open and hope someone else stumbles across the same fix that I did!
Total madness. This highlights how with these AI policies, common sense is thrown out of the window.
score 1 · canonical
with no exceptions, my solution that had been found with the help of AI was not welcome
I don’t actually think that’s the case. This policy focuses on generated contributions more than anything else. If you read a generated description of the bug and its fix, then implement it and write the PR yourself, that isn’t explicitly banned. I don’t think that’s a shortcoming of the policy considering what I think is their primary focus:
We value contributions that are genuinely understood, created, and communicated by humans.
The overall message I get is: don’t use LLMs to substitute your own personal development (and definitely don’t use them to substitute actual communication).
I think the end of this paragraph is most relevant to this situation (emphasis mine):
If you are a new contributor, do not use LLM or AI tools to contribute at all; you do not have the trust or experience to take responsibility for what is generated. If you are someone who is familiar to the maintainers, and know that they already trust you to make high quality contributions, your contribution must still genuinely be understood and created personally by you, regardless of what tools you may use to assist you.
score 1 · canonical
Which puts me in the awkward position of knowing that your code is computing incorrect answers, or corrupting user data, or leaving your users vulnerable to attack. And then I have to guess whether you want to know about a bug discovered using AI. If you have a strict no-AI policy, I’m not going to hide the AI use.
So I guess I leave that issue open and hope someone else stumbles across the same fix that I did!
There is something quite odd about these comments.
As I understand it, the policies of an open source project do not prohibit individuals from publicising independent work. I suspect, irrespective of the policy of the open source project, if one were to find some mistake, one could fix it in a fork, one could write a blog post about it, one could comment on it (in a forum provided by the project… or even just as corroborating detail when making factual claims in other contexts on entirely other websites…) Surely there’s no need to be so coy.
score 2 · canonical
There is something quite odd about these comments.
I think there’s a disconnect which might explain some of the oddness. Let me try to explain. I have seen two types of attitudes towards AI, even here on lobste.rs:
- “Our project does not want slop PRs.” This is an entirely rational policy for many projects. I run many of my projects this way! If I really want slop PRs, I can always ask an agent myself. Slop PRs are dirt cheap, and I can get more than I want to read in an hour or two.
- “AI is morally wrong, and I don’t want it involved in my project.”
When I say “strict no AI policies”, I’m thinking about group (2).
if one were to find some mistake, one could fix it in a fork, one could write a blog post about it,
As I suggested in my original post, yes, I might quietly fork someone’s project. Or If I believed a data corruption bug affected lots of users, I might write a blog post to get the word out. Or sometimes it’s easier to switch to something else.
score 1 · canonical
If I publish a personal fork with my one-line fix am I now making it harder for that fix to make it into the upstream project? I don’t know if there are alternative fixes, and my fix was AI-assisted.
score 1 · canonical
I guess it depends on the one-line fix and the project.
Publish it and make the project aware. Let them decide. If they reject it, you have the fix. Move on.
No offence but the way you’re dealing with this doesn’t feel completely honest.
score 1 · canonical
I think everyone is getting extremely legalistic about other projects’ AI policies on their behalf. No one wants the actual output of the AI, especially unchecked. But if you read the output and actually understand it - a pretty minimal bar for a contribution - and then fix the thing yourself, it has none of the associated issues with AI PRs.
And if there’s only one possible fix, a one liner, then that’s by definition the fix you’d write yourself once you understand the issue. Write it yourself and submit it. There’s no “fruit of the poisonous tree,” this isn’t a courtroom.
score 1 · canonical
I think everyone is getting extremely legalistic about other projects’ AI policies on their behalf. No one wants the actual output of the AI, especially unchecked. But if you read the output and actually understand it - a pretty minimal bar for a contribution - and then fix the thing yourself, it has none of the associated issues with AI PRs.
Well great, then they can write that in their policy instead of “absolutely no AI”!
score 1 · canonical
To avoid arguing with strawmen let’s stick with the actual example Simon provided. The word “absolutely” doesn’t appear anywhere. Here are some quotes:
Pallets is affected by a large increase in low quality contributions generated with LLM (large language model) or “AI” (artificial intelligence) tools.
There’s the motivating problem behind the ban. It’s certainly one we can all understand, right?
We strongly encourage everyone to participate and contribute without using LLM or AI tools.
That’s a “strongly encourage,” not an “absolutely no,” which seems intentionally weakened to provide a tiny bit of space for exercising judgement.
This policy applies to all interactions with our projects and community, not only code and pull requests. This includes code, documentation, tests, PR descriptions, comments, reviews, answers, and all other interactions.
“Interactions with our projects and community” - note that they are specifying interactions between people here. You shouldn’t subject other people to AI output under this policy. It says nothing about using them to help you understand something. The requirement to understand is still there, as it should be.
When you choose to use an LLM tool to generate output, you look like every other person who did so, rather than a unique contributor. Therefore, you inherit the distrust maintainers have based on every prior low quality interaction that looked exactly like yours.
So actually the vast majority of the policy is explaining the harm caused by generated output. We’ve all seen large chunks of generated output and know exactly what they mean.
In most cases a lot of work goes into crafting these policies, which are extremely controversial right now, and they are very descriptive, tell you what problems they’re solving, and are nuanced. That effort seems wasted when people argue with a caricature of them instead of what they actually say.
score 2 · canonical
For a one line easy fix I sort of agree, but I don’t think this is true in general. I don’t think if I write a patch with LLM help. Then put it away and recreate the exact same patch this time “without help” that I’m following the spirit of a ban.
For many maintainers I’ve talked to the point is to ban anyone who might be using LLM related tools from being a contributor.
score 1 · canonical
this isn’t a courtroom
It is not.
In fact, perhaps one might even go so far as to suggest that where an open source project’s policy disagrees with an individual’s preferences, the necessary reaction does not seem to be wounded antagonism. Surely when the project authors set policy, they are aware that they may exclude some desirable contributions; that project may be disinterested in certain contributions, does not require one to make a show of withholding (completed) work under the pretense of following established policy.
The project is, as we all agree, free to set policy as it sees fit.
Irrespective of said policy, nothing enjoins an individual from, say, posting publicly—“here’s a mistake I found”; “here’s a one line-fix I found.” (In fact, as I recall, websites hosting independently maintained patches were quite common prior to wide-spread use and centralisation around version control tooling…)
In fact, I would suggest that if one were to disagree with a project’s policies, and if one were to firmly believe that these policies were detrimental, then maintaining a site with all of the excluded contributions would be very strong corroborating evidence. I use an LLM frequently in my own work and studies, so I know that generating a Github-hosted
<html><body><ul><li><a href="patches/some-fix.diff">Fix for … issue in some-project</a></li></ul></body></html>is well within their capabilities… (In fact, if you write it by hand, you can even skip some of the closing tags!)Altogether, I think the original comments we are replying to are still quite odd.
score 1 · canonical
I love how every one of these articles will have a straw man like:
Developing your project become increasingly dependent of on expensive and completely proprietary software over which you have no control.
I guess the position comes from the fact that anti LLM crowd doesn’t actually use or understand how this tech works. So, they’re just constructing arguments in the abstract based on how they think this tech works and what it can do.
The reality is that you can run a model like a Qwen 3.8 on a laptop, and it can do plenty of real world work without you being dependent on any expensive and completely proprietary software. You run a tool on your machine that you have full control over. But of course, if you just ignore the technology you’re discussing, then you can come up with all sort of nonsense to base your argument on.
score 1 · canonical
The crux of the issue is that the line between tool and collaborator is becoming blurred by LLMs; we don’t expect our collaborators to be open source.
score 1 · canonical
Because human minds aren’t open to inspection in the way open source software is, and that was the only kind of collaborator up until a few years ago (or less).
score 1 · canonical
I’m still not following the point I’m afraid, and how the tool being open to inspection is relevant here.
score 1 · canonical
The reality is that you can run a model like a Qwen 3.8 on a laptop, and it can do plenty of real world work without you being dependent on any expensive and completely proprietary software.
Can you understand and modify that Qwen model? Can you retrain it yourself to accomodate an ever-changing world?
If not, yes, it is still proprietary. Whether or not it depends on some external website. You also wouldn’t call Windows “open source” just because you can download an ISO from microsoft.com.
score 2 · canonical
Slightly horrifyingly, given that both internally and externally a typical LLM (within the same architecture) is fine-tuned not retrained from scratch, and yes it happens a lot externally, I am not even sure that «preferred form of the work for making modifications» (the definition of source code from GPL) is not yet the weights.
Microsoft does recompile Windows from source code regularly, though.
score 1 · canonical
Microsoft does recompile Windows from source code regularly, though.
FWIW It’s not helping.
score 1 · canonical
Well, we don’t know how much more crash-prone it would be otherwise! Although maybe it would break some of the advertisement integrations too, and it would be better overall?
Anyway, the definition talks about preferences of those who have the choice, not about existence of evidence of their good judgement.
But yeah, of course there are drawbacks to codebases that have passed the point of «can anyone understand what they are modifying» years ago then sped up.
score 1 · canonical
To me, “Fine-tuning” seems like roughly the same bucket as hex-editing the binary directly. Source code or bust.
score 1 · canonical
I mean it’s a neural network where you adjust weights. How else would you propose going about it? The engines, like llama.cpp and vllm, that run the models are open source.
score 1 · canonical
An alternative aproach would be to re-weight/augment the dataset and retrain from scratch. And maybe with a better-in-training-efficiency design it would be used.
I do agree that revealed preferences of those who do have the choice point towards «weights are the preferred form for modification» today, though.
score 1 · canonical
The architecture would have to be a lot more efficient for that to be practical. Training a large model from scratch takes a huge amount of resources, and even big labs tend to use foundational models to build on because of that.
And in practical terms there’s not much advantage to retraining the general knowledge part of the model. I’ve trained LoRAs for Qwen, and if you can drastically change the behavior of the model by training higher layers on your own dataset.
score 1 · canonical
I agree that you can get a lot from fine-tuning. I think we don’t really know what options would be open if full retraining were implemented at a much higher efficiency, though.
score 1 · canonical
No one understands it. But yes we can modify it.
But also you’re not reliant on it. That’s the reason people still use this tools to assist in authoring code and not just tell the model to do things directly. The code is still code and humans are still part of the process of authoring it and if every LLM went away tomorrow the humans could keep going.
score 1 · canonical
The code is still code and humans are still part of the process of authoring it and if every LLM went away tomorrow the humans could keep going.
That’s the case with current AI models but I wouldn’t be surprised if future AI models are trained to generate subtly human-unfriendly code. AI labs have an incentive to do this.
score 1 · canonical
I think you are constructing a pretty large strawman here.
Understanding how the tech works != understanding how a particular model “works” != being able to modify that particular model.
I can understand how hybrid kernel GUI-first operating systems work without understanding the entirety of Windows. Humanity can understand how nuclear fusion works without being able to build a second Sun.
score 1 · canonical
Can you retrain it yourself to accomodate an ever-changing world?
You can fine-tune it, but it turns out that’s mostly a waste of time. To accommodate an ever-changing world you can tell it what changed. You can get a model to write an entirely new programming language that’s not part of its training by dumping in a few KBs of examples of the new language and telling it to start writing more code like that.
score 1 · canonical
More importantly, rejecting AI will not alienate any users. Nobody in the world is saying “I’m refusing to use this software because it was made by humans”.
I’ve seen enough now that I am less likely to trust the security posture of an “absolutely no AI allowed” project than one that uses the latest AI models for security review.
I’ve run AI security audits against my own code written pre-AI and turned up a whole bunch of obscure issues (and it’s the obscure issues that get you). I thought I was pretty good at writing secure code; I was not.
score 1 · canonical
Have you run LLM-security audits against your LLM-assisted projects? Are they more secure overall?
score 1 · canonical
While every study on the subject tends to conclude that using LLMs is actually slower than writing code yourself
Really?
People who don’t want to contribute without LLMs are probably not able to review and understand the code by themselves (or they will lose that ability soon enough)
Really?
score 2 · canonical
The second one is true. Properly reviewing and understanding a project takes time, most people pushing quick AI PRs are doing so after the agent decided to use the project and “found a bug”, which might be just a hallucination.
score 1 · canonical
People who don’t want to contribute without LLMs are probably not able to review and understand the code by themselves (or they will lose that ability soon enough)
most people pushing quick AI PRs
You’re arguing against a specific form of this and I feel like that specific form is what’s causing projects to adopt alienating policies. I’ve been doing this for 30 years, I am an AI-skeptic who has been exploring these tools for the last 6 months and am blown away by some of their capabilities. I don’t yolo slop to prod, it gets carefully reviewed, refined, sometimes thrown away and redone. If I find a bug in a software package, ask an LLM to put together a map for me of how that feature works and where the likely issue would be, use that map to manually inspect the source and figure out what’s going on and put together a patch from that… some projects’ policies state that they would rather not have my patch because I used an LLM in the creation of it.
score 1 · canonical
some projects’ policies state that they would rather not have my patch because I used an LLM in the creation of it.
How much does this bother you? Enough to maintain a fork? It is quite interesting that people complain about this in place of doing what they are allowed to.
score 1 · canonical
In this specific case? Yes, maintaining a private fork is straightforward. Yay git! We’re pinned to a specific version anyway for reasons.
It doesn’t bother me at all. That’s the joy of open source. I’ve got access to the source, I can fix bugs and add features if I want to. The project may not want my patches but I don’t need them to accept my patches in order to accomplish my goals. Like you said, it’s one of the things I’m allowed to do.
score 1 · canonical
When I see someone make the first claim, my trust in their writing drops as precipitously as if I realized it were LLM slop.
score 1 · canonical
I love METR but that study has done massive damage to the discourse. (Through very little fault of METR, to be clear.)
score 1 · canonical
This article made a decision at the start and tried to hide it in a list of pros and cons sadly.
When you think about it, contributors who are completely turned away by the fact that they can’t use LLMs are probably contributors you don’t want in your project
When this is the premise, what did you expect to find with the exercise? I have pretty severe unmedicated ADHD, onboarding on a project is an incredibly hard task for me. Agents have vastly improved this for me by being able to ask questions about a codebase as a starting point and poke and prod at the system through natural language. It allows me to cross validate style, abstractions through the codebase and explore possible solutions that fit the codebase a lot quicker. I’m not going to vibe code a solution to this unless its for a private fork or something but I am vastly faster in understanding things because I can zoom in and out in a way I couldn’t before.
increasingly dependent of on expensive and completely proprietary software over which you have no control
I don’t think this follows for two reasons. The initial moat worry of 15 monts ago is mostly all gone. Anthropic and OpenAI pushed the envelope and are now being chased closely by open weights labs. I’ve done several projects with deepseek v4 family of models, an open weights model that is at most 2-3 months behind the sota and I think I’ve topped up $10 twice. So all in all around $20 of usage, or about 4 months of the smallest DO droplet. Second, why would it become dependent? At worst you are back to the levels of today.
I think there are moral reasons for choosing not to use LLMs, but I think those are leaking into the arguments after supposedly ignoring them at the start of the article.
score 1 · canonical
I chuckled a little bit at this from the article:
“I’m refusing to use this software because it was made by humans”
I can, with very little imagination required, come up with reasons why that could be a valid position in the near future. Especially extended to:
“I’m refusing to use this software because it was made by humans without AI support”
For a while, I was writing C++ code that had pretty serious reliability requirements. Not safety-critical but even short (like 10 seconds) downtime was quite expensive. I used a decent chunk of open source tools for doing static analysis, but also leaned pretty hard on a paid Sonar license to double-check my work. It did an excellent job and I wouldn’t hesitate to get a license again if I was working on similar stuff in the future. That cost money and it was money well-spent.
Same goes for Claude Code. It helps me find bugs. Like simonw above, that tool has helped me find multiple white whale bugs that have followed me around for years, a few of them in upstream RTOS code. I don’t use it for writing code much, other than throwaway analysis scripts and things like that. Not sure if I’m going to go through the effort of rewriting the bug analysis to put together PRs that are “human authored”. I’ve read through the couple line fixes, I’ve tested the crap out of them, and it’s unclear if my effort is actually wanted or not.
score 3 · canonical
I really have a hard time understanding the comments on this post - it feels like deliberate misrepresentation to try to make projects with AI policies look absurd.
that tool has helped me find multiple white whale bugs that have followed me around for years
Ok, awesome, but
Not sure if I’m going to go through the effort of rewriting the bug analysis to put together PRs that are “human authored”
…for your “white whale,” your nemesis over literal years, writing it up yourself is suddenly too much effort?
score 3 · canonical
Yes. If I have to go through an entire parallel construction effort to pretend that the bug wasn’t actually found by Claude Code while I was out for a walk with my wife, when I have a perfectly good walkthrough report already that wasn’t human authored but has been seriously human-reviewed… that’s not effort that my employer would encourage me to spend.
And it was found by Claude Code, yes, but that was informed by both my human intuition and my large collection of not-fit-for-human-consumption Markdown notes that I’ve collected over the last 3 years about the issue. The bug was ultimately found when CC was working on something entirely unrelated to the bug and had something like this in the output:
FYI, when I flashed this build it seemed like the processor locked up. I reflashed it and it worked fine. There weren’t any errors either time.
Which made me think “oh, shit, I think this might be that bug and I’ve never been able to repro it on this debug board… nice” and set in motion a whole other session to nail it down with all of the context I’d gathered over the years.
“Remember that bug we finally fixed last week boss? I want to submit it upstream but to do that I have to rewrite the report and patches by hand otherwise the upstream project will reject the fix.” isn’t an easy sell, unfortunately.
score 1 · canonical
“Remember that bug we finally fixed last week boss? I want to submit it upstream but to do that I have to rewrite the report and patches by hand otherwise the upstream project will reject the fix.” isn’t an easy sell, unfortunately.
Is WONTFIX the easier sell? I don’t get it, what do you want? The permission to ignore other peoples wishes? You can either leave the bug, fork the project and shoulder the maintenance, switch to a different project or work with the project. You can’t make everything serve you like CC does.
score 1 · canonical
shrug I don’t think there’s any kind of good answers here in the short term but to wait it out and see how things shake out.
My gut feeling is that the open source projects who flat-out reject contributions because of how those contributions were made (rather than rejecting the content of the contributions) are, over time, going to find themselves with fewer and fewer contributions.
score 1 · canonical
Private small-delta soft-fork is often an easy sell, yes.
I don’t get it, what do you want?
For people not to say that full blanket AI ban costs neither users nor quality contributions. Because it is not true.
score 1 · canonical