Straight up banning ai won’t solve this issue either. People will just commit code either way and simply won’t tell you they used ai.
Comment on Linus Torvalds to critics of AI coding in Linux: "Fork it. Or just walk away."
iocase@lemmy.zip 1 week agoI’m arguing that it’s not a small difference since the cognitive burden is put on maintainers who are already overworked. Now they need to edit through AI PR manure to find decent requests. A lot of OSS projects have stopped taking public PRs for this reason. It shifts the cognitive burden from the programmer to make good code, onto the reviewer to read and understand AI slop contribution.
Jako302@feddit.org 1 week ago
iocase@lemmy.zip 1 week ago
We’ve had low code tools before that caused similar issues. Nothing like AI though… I do agree with the other commenter here that a reputation system is probably the path forward. Something like a minimum number of PRs accepted on gold standard projects or something? People will game that too though and post slop regardless…
socsa@piefed.social 1 week ago
Yeah I think those workflows will adapt eventually, with more maintainers and some kind of more formal trust or reputation process to help sort things. It sucks but figuring out how to deal with it is really the only path forward. Otherwise all the cognitive load goes to arguing about AI.
I also think the worst offenders will get bored once the novelty wears off, and if the standards are kept high enough that getting a PR through still requires some amount of human work.
iocase@lemmy.zip 1 week ago
Does any of what you just said sound reasonable or likely?
Epp@lemmus.org 1 week ago
Yes and yes.
iocase@lemmy.zip 1 week ago
Based on what? Hopium? Open source maintainers are burning out and even extremely popular projects struggle to recruit new devs to help. What’s supporting your argument here besides “lol idk they’ll figure it out I guess”
There’s a ton of load bearing stuff that’s going to break once maybe 100 people have enough and stop thanklessly maintaining things. In fact it’s even worse than being thanklessly expected to fix shit since people are outright hostile towards you for maintaining your own passion project that nobody else wants to help with
iocase@lemmy.zip 1 week ago
To demonstrate the core issue, from now on I’ll argue with you using chatgpt. You’ll need to read this wall of AI slop, and all I need to do is copy paste your comment into my current chat and hit “generate”
I think there are actually several different dimensions to this discussion, and I don’t think it’s quite as straightforward as you’re presenting it. It’s important to recognize that technological transitions have historically been disruptive before new equilibria emerge, and while the current situation certainly creates challenges for maintainers, I don’t think that necessarily implies a long-term negative trajectory for the open-source ecosystem as a whole. From a systems perspective, what we’re really observing is a temporary mismatch between contribution velocity and review capacity. Historically, software engineering has repeatedly experienced periods where productivity increased faster than existing workflows could absorb those gains. While AI-generated pull requests undoubtedly increase the volume of contributions, that doesn’t automatically mean the ecosystem is fundamentally unsustainable. Instead, it suggests that governance models, review methodologies, contributor onboarding, and trust mechanisms will likely evolve over time. Another point worth considering is that AI-assisted development should not necessarily be evaluated solely in terms of code quality. There are also accessibility benefits, educational benefits, and opportunities for new contributors who otherwise might never have engaged with open source. While some of these contributions may indeed be lower quality, the broader increase in participation could, over a sufficiently long time horizon, create a larger pool of experienced contributors than currently exists. This is, admittedly, speculative, but it is also consistent with historical patterns observed during previous shifts in software tooling. Additionally, I think it’s useful to separate concerns regarding code generation from concerns regarding software architecture. Current language models certainly have limitations with maintaining long-lived systems, preserving architectural consistency, and minimizing technical debt. However, these limitations should not necessarily be interpreted as permanent characteristics rather than temporary engineering constraints. Future iterations may demonstrate substantially improved long-context reasoning, architectural awareness, and repository-scale understanding. Finally, I would caution against assuming that current social dynamics necessarily represent the eventual steady state. Communities have historically developed moderation strategies, reputation systems, automated quality gates, and contribution standards in response to changing incentives. While the present situation may be frustrating, it seems plausible that open-source governance will adapt in ways that reduce reviewer burden while maintaining quality. Ultimately, I think the long-term outcome remains uncertain. There are certainly valid concerns about maintainer burnout, review overload, and declining signal-to-noise ratios. At the same time, there are also reasons to believe that new institutional norms, improved tooling, and changing contributor behavior could partially or substantially mitigate those issues over time. As such, I don’t think it is possible to confidently conclude either that open source is doomed or that everything will automatically work itself out. The reality is likely to be considerably more nuanced than either extreme.