[sheepscreek]

Precisely. “AI” contributions should be seen as an extension of the individual. If anything, they could ask that the account belong to a person and not be a second bot only account. Basically, a person’s own reputation should be on the line.

[SlinkyOnStairs]

Reputation isn't very relevant here. Yes, for established well known FOSS developers, their reputation will tank if they put out sloppy PRs and people will just ignore them.

But the projects aren't drowning under PRs from reputable people. They're drowning in drive-by PRs from people with no reputation to speak of. Even if you outright ban their account, they'll just spin up a new one and try again.

Blocking AI submissions serves as a heuristic to reduce this flood of PRs, because the alternative is to ban submissions from people without reputation, and that'd be very harmful to open source.

And AI cannot be the solution here, because open source projects have no funds. Asking maintainers to fork over $200/month for "AI code reviews" just kills the project.

[hombre_fatal]

Well, the problem you just outlined is a reputation (+ UI) problem: why are contributions from unknown contributors shown at the same level as PRs from known quality contributors, for example?

We need to rethink some UX design and processes here, not pretend low quality people are going to follow your "no low quality pls i'm serious >:(" rules. Rather, design the processes against low quality.

Also, we're in a new world where code-change PRs are trivial, and the hard part isn't writing code anymore but generating the spec. Maybe we don't even allow PRs anymore except for trusted contributors, everyone else can only create an issue and help refine a plan there which the code impl is derived?

You know, even before LLMs, it would have been pretty cool if we had a better process around deliberating and collaborating around a plan before the implementation step of any non-trivial code change. Changing code in a PR with no link to discussion around what the impl should actually look like always did feel like the cart before the horse.

[bombcar]

Because until now, unknown contributors either submitted obvious junk which could be closed by even an unskilled moderator (I've done triage work for OS projects before) or they submitted something that was workable and a good start.

The latter is where you get all known contributors from! So if you close off unknown contributors the project will eventually stagnate and die.

[SlinkyOnStairs]

In the long distant past of 4-5 years ago, it simply wasn't a problem. Few projects were overwhelmed with PRs to begin with.

And for the major projects where there was a flood of PRs, it was fairly easy to identify if someone knew what they were talking about by looking at their language; Correct use of jargon, especially domain-specific jargon.

The broader reason why "unknown contributor" PRs were held in high regard is that, outside of some specific incidents (thank you, DigitalOcean and your stupid tshirts), the odds were pretty good of a drive by PR coming from someone who identified a problem in your software by using it. Those are incredibly valuable PRs, especially as the work of diagnosing the problem generally also identifies the solution.

It's very hard to design a UX that impedes clueless fools spamming PRs but not the occasional random person finding sincere issues and having the time to identify (and fix them) but not permanent project contribution.

> and the hard part isn't writing code anymore but generating the spec

My POV: This is a bunch of crap and always has been.

Any sufficiently detailed specification is code. And the cost of writing such a specification is the cost of writing code. Every time "low code" has been tried, it doesn't work for this very reason.

e.g. The work of a ticket "Create a product category for 'Lime'" consists not of adding a database entry and typing in the word 'Lime', it consists of the human work of calling your client and asking whether it should go under Fruit or Cement.

[sheepscreek]

I don’t know why you got downvoted. Those are good points.

Contrary to popular belief, I believe open-source projects are poised for a significant windfall. If a project lacks the ability to transform a good problem into an advantage, that’s their prerogative, but it shouldn’t be the norm (I hope not).

I like to think of it as a stranger/volunteer using their tokens to give the project maintainers a choice. Imagine each issue having 3-4 PRs - it’s a brave new world that demands new solutions!

From a place of scarcity - to now picking from multiple PRs, not a bad problem to have. This is turning into a signal vs noise optimization problem. Could it be solved with agents specially fine-tuned for this use-case? Maybe. Why not?

Also many projects on GitHub do have discussions (typically in a long Issues thread) before someone opens a PR.

[bityard]

> because the alternative is to ban submissions from people without reputation, and that'd be very harmful to open source.

Hmmm, no? That's actually very common in open source. Maybe "banning" isn't the right word, but lots of projects don't accept random drive-by submissions and never have. Debian is a perfect example, you are very unlikely to get a nontrivial patch or package into Debian unless you have some kind of interaction or rapport with a package maintainer, or commit to the process of building trust to become a maintainer yourself.

I have seen high profile GitHub projects that summarily close PRs if you didn't raise the bug/feature as an issue or join their discord first.

[SlinkyOnStairs]

Setting aside "make an issue first" because those too are flooded with LLMs.

> you are very unlikely to get a nontrivial patch or package into Debian unless you have some kind of interaction or rapport with a package maintainer

I did mean the "trivial" patches as well, as often it's a lot of these small little fixes to single issues that improve software quality overall.

But yes, it's true that it's not uncommon for projects to refuse outside PRs.

This already causes massive amounts of friction and contributes (heh) heavily to what makes Open Source such a pain in the ass to use.

Conversely, many popular "good" open source libraries rely extensively on this inflow of small contributions to become comprehensively good.

And so it's a tradeoff. Forcing all open source into refusing drive-by PRs will have costs. What makes sense for major security-sensitive projects with large resources doesn't make sense for others.

It's not that we won't have open source at all. It's that it'll just be worse and encourage further fragmentation. e.g. One doesn't build a good .ZIP library by carefully reading the specification, you get it by collecting a million little examples of weird zip files in the wild breaking your code.

[LtWorf]

You can literally just attach a patch to a bugreport on debian…

[dudeinhawaii]

I don't see why we can't have AI powered reviews as a verification of truth and trust score modifier. Let me explain.

1. You layout policy stating that all code, especially AI code has to be written to a high quality level and have been reviewed for issues prior to submission.

2. Given that even the fastest AI models do a great job of code reviews, you setup an agent using Codex-Spark or Sonnnet, etc to scan submissions for a few different dimensions (maintainability, security, etc).

3. If a submission comes through that fails review, that's a strong indication that the submitter hasn't put even the lowest effort into reviewing their own code. Especially since most AI models will flag similar issues. Knock their trust score down and supply feedback.

3a. If the submitter never acts on the feedback - close the submission and knock the trust score down even more.

3b. If the submitter acts on the feedback - boost trust score slightly. We now have a self-reinforcing loop that pushes thoughtful submitters to screen their own code. (Or ai models to iterate and improve their own code)

4. Submission passes and trust score of submitter meets some minimal threshold. Queued for human review pending prioritization.

I haven't put much thought into this but it seems like you could design a system such that "clout chasing" or "bot submissions" would be forced to either deliver something useful or give up _and_ lose enough trust score that you can safely shadowban them.

[SlinkyOnStairs]

The immediate problem is just cost. Open Source has no money, so any fancy AI solution is off the table immediately.

In terms of your plan though, you're just building a generative adversarial network here. Automated review is relatively easy to "attack".

Yet human contributors don't put up with having to game an arbitrary score system. StackOverflow imploded in no small part because of it.

[lich_king]

> Precisely. “AI” contributions should be seen as an extension of the individual.

That's an OK view to hold, but I'll point out two things. First, it's not how the tech is usually wielded to interact with open-source software. Second, your worldview is at odds with the owners of this technology: the main reason why so much money is being poured into AI coding is that it's seen by investors as a replacement for the individual.

[sheepscreek]

I know. But the irony is, agents, that is AI, need to collaborate with other agents, so other AI, to get any work done. Collaboration is at the core of how work takes place. As humans or as machines. So I don’t necessarily think Open Source will disappear. It will evolve and turn into something very different and more powerful.

[aerodexis]

Interesting argument for AI ethics in general. It takes the form of "guns don't kill people - people kill people".

[glhaynes]

An argument that I have some sympathy for, while still being moderately+ in favor of gun control (here in the USA where I'm a citizen).

It seems that gun control—though imperfect—in regions that have implemented it has had a good bit of success and the legitimate/non-harmful capabilities lost seem worth it to me in trade for the gains. (Reasonable people can disagree here!)

Whereas it seems to me that if we accept the proposition that the vast majority of code in the future is going to be written by AI (and I do), these valuable projects that are taking hard-line stances against it are going to find themselves either having to retreat from that position or facing insurmountable difficulties in staying relevant while holding to their stance.

[estebank]

> these valuable projects that are taking hard-line stances against it are going to find themselves either having to retreat from that position or facing insurmountable difficulties in staying relevant while holding to their stance.

It is the conservative position: it will be easier to walk back the policy and start accepting AI produced code some time down the road when its benefits are clearer than it will be to excise AI produced code from years prior if there's a technical or social reason to do that.

Even if the promise of AI is fulfilled and projects that don't use it are comparatively smaller, that doesn't mean there's no value in that, in the same way that people still make furniture in wood with traditional methods today even if a company can make the same widget cheaper in an almost fully automated way.

[duskdozer]

The AI hype machine is pushing the "inevitability" and "left behind" sentiments to make it a self-fulfilling prophecy, like https://en.wikipedia.org/wiki/Pluralistic_ignorance, and they have the profit and power incentives to do so and drive mass adoption. It is far from certain that AI will be indispensable or that people will "fall behind" for not using it.

Why would the AI-fans even care if others who decide not to use it fall behind? Wouldn't they get to point and laugh and enjoy the benefits of "keeping up"? Their fervor should be looked at with suspicion.

[glhaynes]

If you're addressing this to me: you need to separate my description of how I perceive things from any effort/desire on my part to make that come to pass. I don't expect to stand to gain if AI continues to get better at coding — most likely just the opposite; this is the first time in my career that I've ever felt much anxiety about whether I'd be able to find work in my field in the future.

There are many others like me who share this expectation, and, while we certainly may be wrong, it's not because of some sinister plan to make the prophecy come true. (There are certainly some who do have sinister/profit-seeking motives, of course!)

[datsci_est_2015]

> It seems that gun control—though imperfect—in regions that have implemented it has had a good bit of success and the legitimate/non-harmful capabilities lost seem worth it to me in trade for the gains.

This is even true despite the fact that there are bad actors only a few minutes drive away in many cases (Chicago->Indiana border, for example).

[jazzyjackson]

Unfortunately ChatGPT turned “text continuation” into “separate entity you can talk to”

[aerodexis]

The desire to anthropomorphize LLMs is super interesting. People naturally anthropomorphize technology (even printers: "why are you not working!?"). It's a natural and useful heuristic. However, I can easily see how chatGPT would want to intensify this tendency in order to sell the technology's "agency" and the promise that it can solve all your problems. However, since it's a heuristic, it papers over a lot of details that one would do well to understand.

(as an aside - this reminds me of the trend of Object Oriented Ontology that specifically /tried/ to imbue agency onto large-scale phenomena that were difficult to understand discretely. I remember "global warming" being one of those things - and I can see now how this philosophy would have done more to obscure the dominion of experts wrt that topic)

[dataflow]

I don't think any side on the issue of gun ownership has ever claimed that statement is false, so I'm not sure what your point is.

[johnnyanmac]

The point is thst this is a common pro-gun argument to deflect from the fact that making guns harder to own does in fact reduce gun violence. Which is how much of the rest of the world works.

But post Sandy Hook, it's clear which side prevailed in this argument.

[dataflow]

Except it seems to be arguing in the exact opposite direction, and about the other side of the problem?

Those in favor of gun control aren't trying to lower human responsibility, they're trying to place stricter limits on the guns than the status quo. Those against gun control are trying to loosen limits on the guns.

Here this person is proposing making individual responsibility stricter compared than what it is today. And they're not arguing for loosening limits on the tech either.

Isn't that practically the opposite of your analogy?