Live data from Hacker News

AI tooling must be disclosed for contributions

github.com

371–380 of 482 posts

Re: AI tooling must be disclosed for contributions

#371

Earlier quoted context omitted.

In the West you are free to make something that everyone thinks is a “derivative piece of trash” and still call it yours; and sometimes it will turn out to be a hit because, well, it turns out that in real life no one can reliably tell what is and what isn’t trash[0]—if it was possible, art as we know it would not exist. Sometimes what is trash to you is a cult experimental track to me, because people are different.…

There's an whole genre of musicians focusing only on creating royalty free covers of popular songs so the music can be used in suggestive ways while avoiding royalties. It's not art. It's parasitism of art.

> There's an whole genre of musicians focusing only on creating royalty free covers

There is no such thing as a “royalty free cover”. Either it is a full on faithful cover, which you can perform as long as license fees are paid, and in which case both the performer and the original songwriter get royalties, or it is a “transformative cover” which requires negotiation with the publisher/rights owner (and in that case IP ownership will probably be split between songwriter and performer depending on their agreement).

(Not an IP lawyer myself so someone can correct me.)

Furthermore, in countries where I know how it works as a venue owner you pay the rights organization a fixed sum per month or year and you are good to go and play any track you want. It thus makes no difference to you whether you play the original or a cover.

Have you considered that it is simply singers-performers who like to sing and would like to earn a bit of money from it, but don’t have many original songs if their own?

> It's parasitism of art

If we assume covers are parasitism of art, by that logic would your comment, which is very similar to dozens I have seen on this topic in recent months, be parasitism of discourse?

Jokes aside, a significant number of covers I have heard at cafes over years are actually quite decent, and I would certainly not call that parasitic in any way.

Even pretending they were, if you compare between artists specialising in covers and big tech trying to expropriate IP, insert itself as a middleman and arbiter for information access, devalue art for profit, etc., I am not sure they are even close in terms of the scale of parasitism.

Re: AI tooling must be disclosed for contributions

#372
post #362

Earlier quoted context omitted.

OP is not blaming the AI - did you read the post? AI does enable shitty humans to open PRs with code they have no comprehension of, wasting precious time donated by a skilled maintainer. That is a new thing that wasn’t possible without AI.

Using AI to generate code in a PR does not necessarily mean however that the user has not taken time to understand the changes and is not willing to learn. There are AI users who generate whole files without understanding the contents, and then there are AI users who generate the exact same files but have known in advance what they want, and merely use AI as a tool to save typing. The intention here seems to be to fi…

> The intention here seems to be to filter out low quality submissions for which the only purpose is to only pimp Github resume for having contributions in highly starred repo. Not sure if the people doing that will be disclosing use of AI anyway.

That is a fair way to see it, and I agree that it is a losing battle if your battle is enforcing this rule.

However, from a different perspective - if one sees it more as a gentlemen agreement (which it de facto is) - it fosters an environment where like-minded folks can cooperate better.

The disclosure assists the reviewer in finding common issues in AI generated code, the specificity of the disclosure even more so.

For example, a submitter sends a PR where they disclose a substantial amount of the code was AI assisted but all tests were manually written. The disclosure allows the reviewer to first look at the tests to gauge how well the submitter understands and constrained the solution to their requirements, the next step being to then look at the solution from a high-level perspective before going into the details. It respects the reviewer time, not necessarily because the reviewer is above AI usage, but because without disclosure the whole collaborative process falls apart.

Not sure how long this can work though, it's still easy to distinguish bad code written by a human from AI slop. In the first case your review and assistance is an investment into the collaborative process, in the latter it's just some unread text included in the next prompt.

Re: AI tooling must be disclosed for contributions

#373

> 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 I really appreciate this point from mitchellh. Giving thoughtful constructive feedback to help a junior developer improve is a gift. Yet it would be a waste of time if the PR submitter is just going to pass it to an AI without learning from it.

Junior developers are entering a workforce where they will never not be using AI

Yes, in the same way junior pilots are entering a workforce where they will never not be using an autopilot.

Re: AI tooling must be disclosed for contributions

#374

Provenance matters. An LLM cannot certify a Developer Certificate of Origin ( https://en.wikipedia.org/wiki/Developer_Certificate_of_Origi... ) and a developer of integrity cannot certify the DCO for code emitted by an LLM, certainly not an LLM trained on code of unknown provenance. It is well-known that LLMs sometimes produce verbatim or near-verbatim copies of their training data, most of which cannot be used witho…

Or you know, they just feel like code should be free. Like beer should be free.

We didn't have this whole issue 20 years ago because nobody gave a shit. If your code was public, and on the internet, it was free for everyone to use by definition.

Re: AI tooling must be disclosed for contributions

#375

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.

I contribute to an open-source game with decades of legacy and employing many unusual patterns.

Two weeks ago someone asked me to review a PR, which I did pointing out some architectural concerns. The code was not necessarily bad, but it added boilerplate to a point it required some restructuring to keep the codebase maintainable. I couldn't care less if it was written by AI or not in this case, it was not necessarily simple but was straightforward.

It took considerable effort to conjure a thoughtful and approachable description of the problem and the possible solutions. Keep in mind this is a project with considerable traction and a high amount of contributions are from enthusiasts. So having a clear, maintainable and approachable codebase is sometimes the most important requirement.

They asked for a second pass but it took two weeks for me to get around it, in the meantime they sent 3 different PRs, one closed after the other. I found it a bit strange, then I put some effort to review the last iteration. It had half baked solutions where for example there would be state cleanup functions but state was never written in the first place, something that would never go through normally, I gave the benefit of the doubt and pointed it out. I suspected it was AI generated most likely.

Then they showed me another variation of the PR where they implement a whole different architecture, some incredibly overengineered fluent interface to resolve a simple problem with many layers of indirection that reflects complete indifference to the more nuanced considerations relevant to the domain and project, that I tried to impair. The code might work, but even if it does it's obvious that the change is a net negative to the project.

What I suspected indeed was the case, as they finally disclosed the use of AI, but that is not necessarily the problem, as I hope to convey. The problem is that I was unable to gauge the submitters commitment to perform the humble job of _understanding_ what I proposed. The proposal, in the end, just becoming mere tokens for inclusion into a prompt. Disclosure wouldn't necessarily have caused me to not take the PR seriously, instead I would invested my time in the more productive effort of orienting the submitter on the tractability of achieving their goal.

I would rather have known they didn't intend or gauged their capacity beforehand. It would have been better for both of us: they would have had their initial iteration merged (which was fine, I would just have shrugged the refactor for another occasion) and I wouldn't have lost time.

Re: AI tooling must be disclosed for contributions

#376

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).

It’s not just common courtesy to disclose, it’s outright fraud not to disclose.

That's nonsense. It's like feeling you need to disclose that your IDE has autocomplete. Nobody discloses that, since it's ridiculous. You only disclose that you used Claude Code if you are not certain of the result (e.g. you think it is correct, but the maintainer might be a better judge).

If it's exactly the same as what you'd have written manually, and you are confident it works, then what's the point of disclosure?

Re: AI tooling must be disclosed for contributions

#377

Earlier quoted context omitted.

Agreed -- this requirement feels less like an actually useful requirement and more a silly and performative one, which is trying to make some kind of commentary on AI use as a whole.

Spending at minimum five minutes would tell you why maintainers are implementing this change. It's because people using LLMs are spamming open source repos with fake issues, incredibly low quality but high effort to review PRs and shutting down the active communication process between reviewer and reviewee by not even understanding their own code.

Nothing stopping these low effort contributors from lying and saying no LLMs were used - especially in the world of AI slop where such contributions are not welcome.

Re: AI tooling must be disclosed for contributions

#378
post #375

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.

I contribute to an open-source game with decades of legacy and employing many unusual patterns. Two weeks ago someone asked me to review a PR, which I did pointing out some architectural concerns. The code was not necessarily bad, but it added boilerplate to a point it required some restructuring to keep the codebase maintainable. I couldn't care less if it was written by AI or not in this case, it was not necessaril…

Your story highlights the clash of two mindsets regarding open source development. On one side there are artisans who treat programming as a craft and care about every line of code. On the other side, vibe-coders who might not even seen the code LLMs have generated and don't care about it as long as the program works.

And of course there is everything in between.

Re: AI tooling must be disclosed for contributions

#379
post #375

Earlier quoted context omitted.

I contribute to an open-source game with decades of legacy and employing many unusual patterns. Two weeks ago someone asked me to review a PR, which I did pointing out some architectural concerns. The code was not necessarily bad, but it added boilerplate to a point it required some restructuring to keep the codebase maintainable. I couldn't care less if it was written by AI or not in this case, it was not necessaril…

Your story highlights the clash of two mindsets regarding open source development. On one side there are artisans who treat programming as a craft and care about every line of code. On the other side, vibe-coders who might not even seen the code LLMs have generated and don't care about it as long as the program works. And of course there is everything in between.

Some context: it is a tightly knit community, where I interact with the contributors often in a conversational manner.

I know their intent is to push the project forward and well-meaning, I don't care about whether they are vibe-coding. I care about knowing they are vibe-coding so I can assist them to vibe-code in a way they can actually achieve their goal, or help them realize early that they lack the capacity to contribute (not of their own fault necessarily, maybe they just require orientation on how to reason about problems and solutions or their use of the tools).

Re: AI tooling must be disclosed for contributions

#380
post #364

Earlier quoted context omitted.

Spending at minimum five minutes would tell you why maintainers are implementing this change. It's because people using LLMs are spamming open source repos with fake issues, incredibly low quality but high effort to review PRs and shutting down the active communication process between reviewer and reviewee by not even understanding their own code.

Why would these people disclose their use of AI? These are not responsible and thoughful users of AI. The slop producers won't disclose, and the responsible users who produce high quality PRs with AI will get the "AI slop" label. At this point, why even disclose if the AI-assisted high-quality PR is indistinguishable from having been manually written (which it should be)? No point.

> Why would these people disclose their use of AI?

Because lying about your usage of AI is a good way to get completely kicked out of the open source community once caught. That's like asking 'why should you bother with anti-cheating measures for speedruns'. Why should we have any guidelines or regulations if people are going to bypass them? The answer I hope should be very obvious.

> high quality PRs with AI will get the "AI slop" label. At this point, why even disclose if the AI-assisted high-quality PR is indistinguishable from having been manually written (which it should be)? No point.

Then obviously the repository in question doesn't want people using AI and you should go elsewhere. They're not even against LLM tooling for this repo but people are freaking out because how dare you ask me to disclose what tools I'm using.

Post reply on HN