Comment on Linus Torvalds to critics of AI coding in Linux: "Fork it. Or just walk away."
socsa@piefed.social 1 week agoYeah 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
Epp@lemmus.org 1 week ago
Based on the fact that it is now reality, and there is no alternative. Adapt or die.
Even if, moronically, Linus had followed the popular trend of banning AI tools - the only thing that would change is disclosure. The reality is, the tools will be used either way, and banning just means they won’t report the tools used.
Whether AI tools are used or not, a person is still attaching their identity to the submission. Regardless of the tools they did, or did not use, they are stamping the end result. The only feasible solution in the long term is to scrutinize those submitting PR, rather than attempting to police the tools they used to create them.
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.
Epp@lemmus.org 1 week ago
At which point, I’d reply: eliminate the verbosity. Be succinct, or I’m closing this PR and line of communication.