The difference I see between a company dealing with this as opposed to an open source community dealing with this is that the company can fire employees as a reactive punishment. Drive-by open source contributions cost very little to lob over and can come from a wide variety of people you don't have much leverage over, so maintainers end up making these specific policies to prevent them from having to react to the thousandth person who used "The AI did it" as an excuse.

>I neither tell people to use AI, nor tell them not to use it, and in practice people have not been using AI much for whatever that is worth.

I find this bit confusing. Do you provide enterprise contracts for AI tools? Or do you let employees use their personal accounts with company data? It seems all companies have to be managing this somehow at this point.

Shouldn't this go without saying though? At some point someone has to review the code and they see a human name as the sender of the PR. If that person sees the work is bad, isn't it just completely unambiguous that the person whose name is on the PR is responsible for that? If someone responded "but this is AI generated" I would feel justified just responding "it doesn't matter" and passing the review back again.

And the rest (what's in the LLVM policy) should also fall out pretty naturally from this? If someone sends me code for review, and have the feeling they haven't read it themselves, I'll say "I'm not reviewing this and I won't review any more of your PRs unless you promise you reviewed them yourself first".

The fact that people seem to need to establish these things as an explicit policy is a little concerning to me. (Not that it's a bad idea at all. Just worried that there was a need).

Some people who just want to polish their resume will feed any questions/feedback back into the AI that generated their slop. That goes back and forth a few times until the reviewing side learns that the code authors have no idea what they're doing. An LLM can easily pretend to "stand behind its work" if you tell it to.

A company can just fire someone who doesn't know what they're doing, or at least take some kind of measure against their efforts. On a public project, these people can be a death by a thousand cuts.

The best example of this is the automated "CVE" reports you find on bug bounty websites these days.

What good does it really do me if they "stand behind their work"? Does that save me any time drudging through the code? No, it just gives me a script for reprimanding. I don't want to reprimand. I want to review code that was given to me in good faith.

At work once I had to review some code that, in the same file, declared a "FooBar" struct and a "BarFoo" struct, both with identical field names/types, and complete with boilerplate to convert between them. This split served no purpose whatsoever, it was probably just the result of telling an agent to iterate until the code compiled then shipping it off without actually reading what it had done. Yelling at them that they should "stand behind their work" doesn't give me back the time I lost trying to figure out why on earth the code was written this way. It just makes me into an asshole.

That only works if those colleagues care about what you think of them

> At my company I just tell people “You have to stand behind your work”

Since when has that not been the bare minimum. Even before AI existed, and even if you did not work in programming at all, you sort of have to do that as a bare minimum. Even if you use a toaster and your company guidelines suggest you toast every sandwich for 20 seconds, if following every step as per training results in a lump of charcoal for bread, you can’t serve it up to the customer. At the end of the day, you make the sandwich, you’re responsible for making it correctly.

Using AI as a scapegoat for sloppy and lazy work needs to be unacceptable.

But "AI did it" is not immediate you are out thing? If you cannot explain why something is made the way you committed to git, we can just replace you with AI right?

The smartest and most sensible response.

I'm dreading the day the hammer falls and there will be AI-use metrics implemented for all developers at my job.

Seconded, the original title ("We don't need more contributors who aren't programmers to contribute code") caricatured what seems like an eminently measured and sensible policy change.

Additionally, it comes across as pretty hostile toward new contributors, which isn’t the intent of the article at all.

I'll say it as it is: if you can't read code, but have a friend write it for you, you are in fact the wrong person to submit it, since you are the most exhausting person to deal with.

A human in the loop that doesn't understand what is going on but still pushes isn't only useless, but actively harmful.

My original link was to a comment in this thread which I quoted that from. The link's now been changed to the main thread.

I'd like to know why the title hasn't been fixed.

It’s happening a lot with me at work. I am a programmer working largely with a hardware team and now they’re contributing large changes that I’m supposed to just roll with the punches. Management loves it

People who are smart enough to think that far ahead are also smart enough not to fall into the “ai can do all jobs perfectly all the time and just need my divine guidance” trap.

Not if they're not programmers!

I think it's part of the "AI replacing software developers" hype.

Many beginners or aspiring developers swallow this whole and simply point an AI to a problem and submit the generated slop to maintainers.

People who rely on a computer algorithm to literally think for them are not going to be very smart.

> You would have done it better if the company hadn't forced you to cut corners.

I assume (hope to god) you're being hyperbolic, but I feel it important to point out to everyone who doesn't get it. This is just the CS version of "just following orders". And deserves the exact same amount of respect and fairness.

And so did the slop.

You also have a second responsibility with LLM generated code you publish: it must not be copyrighted.

I’m curious have you ever been burnt or seen anyone burnt by copyright infringements in code?

Sometimes it’s super obvious because a game company steals code from a previous employer, but I have never seen this play out in entreprise software.

> However, proving the negative, i.e. the code is not copyrighted is almost impossible.

Nonsense, it's trivially easy if you wrote the code yourself. You hold the copyright.

If you had some LLM puke out the code for you, well, then you have no idea. So you can't contribute that puke.

Copyright is for creative work so if it really is the best way to do it, you should be safe even if the AI copied the idea from somebody else. You can't use copyright to restrict access to useful technology like a patent.

Is it tho?

If you don't speak Hungarian and you have a Hungarian friend write a text for you that you submit to a collection of worthy Hungarian poetry, do you really think you are the correct person to answer questions about the text that was written?

You know what is supposed to be in it, but that's it. You can't judge the quality of the text and how it is fitting the rest at all. You can only trust your friend. And it is okay if you do, just don't pull others into it.

IMO it is extremely rude to even try to pull this off and if you do, shame on you for wasting peoples time.

This account seems like LLM slop looking at the post history. Who starts every post ‘from Japan’?

I don’t want to interact with hidden chat bots on HN. The irony of this comment about accountability is also frustrating.

> jump on a call with the reviewer

Have you ever done that with new contributors to open source projects? Typically things tend to be asynchronous but maybe it's a practice I've just not encountered in such context.

I get this at work, frequently.

“Oh, cursor wrote that.”

If it made it into your pull request, YOU wrote it, and it it’ll be part of your performance review. Cursor doesn’t have a performance review. Simple as

I’ve seen a bunch of my colleagues say this when I ask about the code they’ve submitted for review. Incredibly frustrating, but likely to become more common

See this thread from a while back: https://news.ycombinator.com/item?id=46039274

I don't know how it is for you, but I find it rather easy to tell when someone doesn't actually understand what they're talking about.

At least that's much better than not being able to answer them. If LLMs are truly intelligent enough to justify their contributions (including copyrights!), why should we treat them differently from human contributions?

For what it's worth, this is essentially the policy my current and most recent previous workplace followed. (My employers before that were pre-LLMs.)

If you are the one with your name on the PR, it's your code and you have to understand it. If you don't understand it at least well enough to speak intelligently about it, you aren't ready to submit it for review. If you ask Copilot, Cursor, or whatever to generate a PR for you, it still must be reviewed and approved by you and another engineer who acts as your reviewer.

I haven't heard a lot of pushback on this; it feels like common sense to me. It's effectively the same rules we'd use if somebody who wasn't an engineer wanted to submit code; they'd need to go through an engineer to do it.

LLM usage has increased our throughput and the quality of our code thus far, but without these rules (and people following the spirit of them, being bought in to their importance), I really don't think it would.

I encourage you to raise this policy with your management, if you think you can get them to listen, and demonstrate how it might help. I would be very frustrated if my colleagues were submitting AI-generated code without thinking it through.

This is why gcc and linux use mailing lists instead of github pull requests.

In the gcc/linux flow, convincing the rest of the mailing list to not ignore their message is the submitter's job.

In the github flow, keeping the "unresolved PR count" (displayed right beneath your project's title) low is the developers' job.

I think it's great that this AI slop fatigue happened so quickly.

Now we can still identify them easily, and I am maintaining bookmarks of non slop codebases, so that I know which software to avoid.

I encourage everyone to do the same because the slopcode fallout will be inevitable, and likely be the most harmful thing that ever happened to open source as a philosophy.

We need to change our methodology of how to develop verifiable and specdriven software, because TDD isn't good enough to catch this. Something that is able to verify logical conclusions and implications (aka branches) and not only methods and their types/signatures.

one reason i can imagine for this choice is that human review distributes new knowledge among human maintainers. Automated review might discourage that valuable interaction.

The comment is an artefact of an inherently valuable process, not the sole objective. So I'd prefer code is reviewed by a human who maybe initiates a discussion with an agent. I'd hope this minor workflow detail encourages the human to take a more active lead, rather than risk mere ceremonial approval.

An LLM is a plausibility engine. That can't be the final step of any workflow.

The policy isn’t about whether those tools raise good points. It’s about not letting agents act autonomously in project spaces. Human reviewed, opt in use is explicitly allowed.