Live data from Hacker News

AI tooling must be disclosed for contributions

github.com

231–240 of 482 posts

Re: AI tooling must be disclosed for contributions

#231

Earlier quoted context omitted.

They genuinely believe their use of chatbots is equivalent to multiple years of production experience in a language. They want to erase that distinction (“democratize”) so they can have the same privileges and status without the work. Otherwise, what’s the harm in saying AI guides you to the solution if you can attest to it being a good solution?

Democratize X via boiling our oceans!!

https://youtu.be/klW65MWJ1PY?t=3234

https://youtu.be/klW65MWJ1PY?t=1320

X sucks and should not be allowed to proceed with what they're doing in Memphis. Nor should Meta be allowed to proceed with multiple Manhattan sized data centers.

Re: AI tooling must be disclosed for contributions

#232

Earlier quoted context omitted.

Agreed. As someone who uses AI (completion and Claude Code), I'll disclose whenever asked. But I disagree that it's "common courtesy" when not explicitly asked; since many people (including myself) don't mind and probably assume some AI, and it adds distraction (another useless small indicator; vaguely like dependabot, in that it steals my attention but ultimately I don't care).

If you don't disclose the use of - books - search engines - stack overflow - talking to a coworker then it's not clear why you would have to disclose talking to an AI. Generally speaking, when someone uses the word "slop" when talking about AI it's a signal to me that they've been sucked into a culture war and to discount what they say about AI. It's of course the maintainer's right to take part in a culture war, but…

> then it's not clear why you would have to disclose talking to an AI.

It’s explained right there in the PR:

> The disclosure is to help maintainers assess how much attention to give a PR. While we aren't obligated to in any way, I try to assist inexperienced contributors and coach them to the finish line, because getting a PR accepted is an achievement to be proud of. But if it's just an AI on the other side, I don't need to put in this effort, and it's rude to trick me into doing so.

That is not true of books, search engines, stack overflow, or talking to a worker, because in all those cases you still had to do the work yourself of comprehending, preparing, and submitting the patch. This is also why they ask for a disclosure of “the extent to which AI assistance was used”. What about that isn’t clear to you?

Re: AI tooling must be disclosed for contributions

#233
post #227

There's a lot of discussion about the ethics of AI disclosure going on here, but this maintainer is writing this from a place I recognize - community-driven, participatory development by people who enjoy programming, talking about it, and teaching each other how to do it. Not every software project needs to attempt to maximize productivity. Not every software project is a business. Some are just created by people who…

100%

This project was literally born from a place of "because I want to".

Re: AI tooling must be disclosed for contributions

#234

Earlier quoted context omitted.

The observation that inspired this policy is that if you used AI, it is likely you don't know if the code, the documentation or tests are good or appropriate.

What if you started with good documentation that you personally wrote, you gave that to the agent, and you verified the tests were appropriate and passed?

I'd extrapolate that the OP's view would be: you've still put in less effort, so your PR is less worthy of his attention than someone who'd done the same without using LLMs.

That's a pretty nice offer from one of the most famous and accomplished free software maintainers in the world. He's promising not to take a short-cut reviewing your PR, in exchange for you not taking a short-cut writing it in the first place.

Re: AI tooling must be disclosed for contributions

#235
post #23

Earlier quoted context omitted.

It does matter how and where a PR comes from, because reviewers are fallible and finite, so trust enters the equation inevitably. You must ask "Do I trust where this came from?" And to answer that, you need to know where it come from. If trust didn't matter, there wouldn't have been a need for the Linux Kernel team to ban the University of Minnesota for attempting to intentionally smuggle bugs through the PR process…

[flagged]

Being more trusting of people’s code simply because they didn’t use AI seems as naive as distrusting code contributions simply because they were written with the assistance of AI.

It seems a bit like saying you can’t trust a legal document because it was written on a computer with spellcheck, rather than by a $10 an hour temp with a typewriter.

Re: AI tooling must be disclosed for contributions

#236
post #23

I’m not a big AI fan but I do see it as just another tool in your toolbox. I wouldn’t really care how someone got to the end result that is a PR. But I also think that if a maintainer asks you to jump before submitting a PR, you politely ask, “how high?”

It does matter how and where a PR comes from, because reviewers are fallible and finite, so trust enters the equation inevitably. You must ask "Do I trust where this came from?" And to answer that, you need to know where it come from. If trust didn't matter, there wouldn't have been a need for the Linux Kernel team to ban the University of Minnesota for attempting to intentionally smuggle bugs through the PR process…

> "Do I trust where this came from?"

In an open source project I think you have to start with a baseline assumption of "trust nobody." Exceptions possibly if you know the contributors personally, or have built up trust over years of collaboration.

I wouldn't reject or decline to review a PR just because I don't trust the contributor.

Re: AI tooling must be disclosed for contributions

#237

Earlier quoted context omitted.

> I wouldn’t really care how someone got to the end result that is a PR. I can generate 1,000 PRs today against an open source project using AI. I think you do care, you are only thinking about the happy path where someone uses a little AI to draft a well constructed PR. There's a lot ways AI can be used to quickly overwhelm a project maintainer.

In that case a more correct rule (and probably one that can be automatically enforced) for that issue is a max number of PRs or opened issues per account.

I think this is sane, although possibly not sufficient. Asking people to self-disclose AI usage is not going shield maintainers from a flood of undisclosed AI submissions.

Re: AI tooling must be disclosed for contributions

#238
Hot take: if you can't spot any issues in the code review it's either good code, code that needs further changes, or review was not done properly. I don't see how "I used LLMs" fit here, because it means nothing to the quality of the code submitted.

If such mention would mean increased reviewer attention, then every code review should include it.

Re: AI tooling must be disclosed for contributions

#239

I’m not a big AI fan but I do see it as just another tool in your toolbox. I wouldn’t really care how someone got to the end result that is a PR. But I also think that if a maintainer asks you to jump before submitting a PR, you politely ask, “how high?”

It's not just about how you got there. At least in the United States according to the Copyright Office... materials produced by artificial intelligence are not eligible for copyright. So, yeah, some people want to know for licensing purposes. I don't think that's the case here, but it is yet another reason to require that kind of disclosure... since if you fail to mention that something was made by AI as part of a co…

> if you fail to mention that something was made by AI as part of a compound work you could end up losing copyright over the whole thing

The source you linked says the opposite of that: "the inclusion of elements of AI-generated content in a larger human-authored work does not affect the copyrightability of the larger human-authored work as a whole"

Re: AI tooling must be disclosed for contributions

#240
post #225

Earlier quoted context omitted.

"Every piece of feedback you give to an LLM is like screaming into the void - it wastes your time, and doesn't change the LLM one iota." I think you just haven't gotten the hang of it yet, which is fine... the tooling is very immature and hard to get consistent results with. But this isn't a given. Some people do get good, steerable LLM coding setups.

Steering via prompting isn't the same as fundamentally changing the LLM by teaching, as you can do with humans. I think OP understands this better than you.

Can't tell if you're responding in earnest or not here?

LLMs are trained to be steerable at inference time via context/prompting. Fine tuning is also possible and often used. Both count as "feedback" in my book, and my point is that both can be effective at "changing the LLM" in terms of its behavior at inference time.

Post reply on HN