And in practice that means that I won’t take “The AI did it” as an excuse. You have to stand behind the work you did even if you used AI to help.
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.
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).
A terrifying number of people seem to think that the damn thing is magic and infallible.
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.
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.
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.
If you write bad code that creates a bug, I expect you to own it when possible. If you can't and the root cause is bad code, then we probably need to have a chat about that.
Of course the goal isn't to be a jerk. Lots of normal bugs make it through in reality. But if the root cause is true negligence, then there's a problem there.
AI makes negligence much easier to achieve.
It's not going to be enough to say - "I don't use LLM's".
First: Somebody hired these people, so are they really "lazy and incompetent"?
Second: There is no one who's "job" is to yell at incompetent or lazy workers.
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 some people view it as a seperate entity that writes code for you. And if you view AI like that, then “The AI did it” becomes an excuse that they use.
If you're illiterate and can't read maybe don't submit the text someone has written for you if you can't even parse the letters.
Taking responsibility for outcomes is a powerful paradigm but I refuse to be held responsible for things that are genuinely beyond my power to change.
This is tangential to the AI discussion though.
If the toaster is defective, not using it, identifying how to use it if it’s still usable or getting it replaced by reporting it as defective are all well within the pay grade of a sandwich pusher as well as part of their responsibilities.
And you’re still responsible for the sandwich. You can’t throw up your arms and say “the toaster did it”. And that’s where it’s not tangential to the AI discussion.
Toaster malfunctioning is beyond your control, but whether you serve up the burnt sandwich is absolutely within your control, which you will be and should be held responsible for.
Accountability and IP protection is probably the only thing saving someone in that situation.
I'm dreading the day the hammer falls and there will be AI-use metrics implemented for all developers at my job.
It doesn't take long for shitty small companies to copy the shitty policies and procedures of successful big companies. It seems even intelligent executives can't get correlation and causation right.
At the moment it's "We don't need more contributors who aren't programmers to contribute code," which is from a reply and isn't representative of the original post.
The HN guidelines say: please use the original title, unless it is misleading or linkbait; don't editorialize.
A human in the loop that doesn't understand what is going on but still pushes isn't only useless, but actively harmful.
Many beginners or aspiring developers swallow this whole and simply point an AI to a problem and submit the generated slop to maintainers.
They are responsible for it.
However, here's a different situation:
If the company you're working for requires you to use LLMs to code, I think it's 100% defensible to say "Oh, the AI did that" when there's a problem because the company required its usage. You would have done it better if the company hadn't forced you to cut corners.
I especially like the term "extractive contribution." That captures the issue very well and covers even non-AI instances of the problem which were already present before LLMs.
Making reviewer friendly contributions is a skill on its own and makes a big difference.
We use plenty of models to calculate credit risk, but we never let the model sign the contract. An algorithm can't go to court, and it can't apologize to a bankrupt family.
"Human in the Loop" isn't just about code quality. It's about liability. If production breaks, we need to know exactly which human put their reputation on the line to merge it.
Accountability is still the one thing you can't automate.
I don’t want to interact with hidden chat bots on HN. The irony of this comment about accountability is also frustrating.
I am responsible for ensuring copyright has not been violated with LLM generated code I publish. However, proving the negative, i.e. the code is not copyrighted is almost impossible.
I have experienced this - Claude came up with an almost perfect solution to a tricky problem, ten lines to do what I've seen done in multiple KLOC, and I later found the almost identical solution in copyrighted material.
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.
I can't find the specific article now, but I am extremely careful to avoid anything GPL or LGPL.
It's unlikely to be a problem until an app is highly successful, but once that happens people will grasp at whatever straws they can, e.g. https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America%2....
// bytes are added to the buffer until a value of bitwidth is available
for _ in 0..<bitWidth {
let byte = try UInt8(parsing: &input)
buffer |= UInt64(byte) << bitsInBuffer
bitsInBuffer += 8
// Values of bitwidth are right-shifted off the buffer.
while bitsInBuffer >= bitWidth && outPos < numValues {
let value = Int(buffer & mask)
out[outPos + outOffset] = value
outPos += 1
buffer >>= bitWidth
bitsInBuffer -= bitWidth
}
}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.
> I am responsible for ensuring copyright has not been violated with LLM generated code I publish
Your comment:
> If you had some LLM puke out the code for you, well, then you have no idea. So you can't contribute that puke.
That's not true. You can if it's not violating copyright. That "puke" as you put it comes in many flavours.
Requiring people who contribute to "able to answer questions about their work during review." is definitely reasonable.
The current title of "We don't need more contributors who aren't programmers to contribute code" is an entirely different discussion.
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.
With little icons of rocket ships and such.
One thing I didn't like was the copy/paste response for violations.
It makes sense to have one. Just the text they propose uses what I'd call insider terms, and also terms that sort of put down the contributor.
And while that might be appropriate at the next level of escalation, the first level stock text should be easier for the outside contributor to understand, and should better explain the next steps for the contributor to take.
1. It shifts the cognitive load from the reviewer to the author because now the author has to do an elevator pitch and this can work sort of like a "rubber duck" where one would likely have to think about these questions up front.
2. In my experience this is a much faster to do this than a lonesome review with no live input from the author on the many choices they made.
First pass and have a reviewer give a go/no-go with optional comments on design/code quality etc.
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.
In addition, 1:1 contact can speed up things immensely in such situations because most activity on a change happens very soon after the first change is made and that initial voluminous back and forth can be faster than typing to have a back and forth on github for a PR.
Reading through the (first few) comments and seeing people defending the use of pure AI tools is really disheartening. I mean, they’re not asking for much just that one reviews and understands what the AI produced for them.
I would never have thought that someone could actually write this.
“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 also recently wrote a similar policy[0] for my fork of a codebase. I had to write this because the original developer took the AI pill, and starting committing totally broken code that was fulled of bugs, and doubled down when asked about it [1].
On an analysis level, I recently commented[2] that "Non-coders using AI to program are effectively non-technical people, equipped with the over-confidence of technical people. Proper training would turn those people into coders that are technical people. Traditional training techniques and material cannot work, as they are targeted and created with technical people in mind."
But what's more, we're also seeing programmers use AI creating slop. They're effectively technical people equipped with their initial over-confidence, highly inflated by a sense of effortless capability. Before AI, developers were once (sometimes) forced to pause, investigate, and understand, and now it's just easier and more natural to simply assume they grasp far more than they actually do, because @grok told them this is true.
[0]: https://gixy.io/contributing/#ai-llm-tooling-usage-policy
[1]: https://joshua.hu/gixy-ng-new-version-gixy-updated-checks#qu...
[2]: https://joshua.hu/ai-slop-story-nginx-leaking-dns-chatgpt#fi...
"To critique the fortress is not enough. We must offer a blueprint for a better structure: a harbor. A harbor, unlike a fortress, does not have a simple binary function of letting things in or keeping them out. It is an active, intelligent system with channels, docks, workshops, and expert pilots, all designed to guide valuable cargo safely to shore, no matter the state of the vessel that carries it. This is the model we must adopt for open source in a post-AI world. The anxiety over “extractive” contributions is real, but the solution is not a higher wall; it is a smarter intake process."
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.
There needs to be a label which designates such open source projects that is so important and adopted throughout the industry that not anyone can throw patches to it without understanding what it does, and why they need it.
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.
Was the worst thing to happen to programming, computer science I have seen, good for prototypes but not production software, and especially for important projects like LLVM.
It is good to gatekeep this slop from LLVM before it gets out of control.
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.
Just like everything else these days the responses skew towards both extremes on the spectrum and people hand waving away the advancements is just as annoying as those who are zealots on the other end.
This seems like a curious choice. At my company we have both Gemini and cursor (I’m not sure which model under the hood on that) review agents available. Both frequently raise legitimate points. Im sure they’re abusable, I just haven’t seen it
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.