Live data from Hacker News

AI tooling must be disclosed for contributions

github.com

141–150 of 482 posts

Re: AI tooling must be disclosed for contributions

#141
post #78

Earlier quoted context omitted.

I've been struggling to apply AI on any large scale at work. I was beginning to wonder if it was me. But then my wife sort of handed me a project that previously I would have just said no to, a particular Android app for the family. I have instances of all the various Android technologies under my belt, that is, I've used GUI toolkits, I've used general purpose programming languages, I've used databases, etc, but wit…

> try it in a language and environment you know nothing about and so aren't tempted to keep taking the wheel. That's a good insights. Its almost like to use AI tools effectively, one needs to stop caring about the little things you'd get caught up in if you were already familiar and proficient in a stack. Style guidelines, a certain idiomatic way to do things, naming conventions, etc. A lot like how I've stopped orga…

How do you know the code is correct, isn’t insecure, and performant, without caring about the code?

Re: AI tooling must be disclosed for contributions

#142
post #26

There is also IP taint when using "AI". We're just pretending that there's not. If someone came to you and said "good news: I memorized the code of all the open source projects in this space, and can regurgitate it on command", you would be smart to ban them from working on code at your company. But with "AI", we make up a bunch of rationalizations. ("I'm doing AI agentic generative AI workflow boilerplate 10x gettin…

Courts (at least in the US) have already ruled that use of ingested data for training is transformative. There’s lots of details to figure, but the genie is out of the bottle. Sure it’s a big hill to climb in rethinking IP laws to align with a societal desire that generating IP continue to be a viable economic work product, but that is what’s necessary.

Training an AI model is not the same as using an AI model.

Re: AI tooling must be disclosed for contributions

#143

I’m loving today. HN’s front page is filled with some good sources today. No nonsense sensationalism or preaching AI doom, but more realistic experiences. I’ve completely turned off AI assist on my personal computer and only use AI assist sparingly on my work computer. It is so bad at compound work. AI assist is great at atomic work. The rest should be handled by humans and use AI wisely. It all boils down back to hu…

Today, I read the following in the concluding sentence of Frederik P. Brooks' essay “No Silver Bullets, Refired"[0]. I am quoting the entire chapter in full because it is so apt and ends with a truly positive message.

> Net on Bullets - Position Unchanged

> So we come back to fundamentals. Complexity is the business we are in, and complexity is what limits us. R. L. Glass, writing in 1988, accurately summarizes my 1995 views:

>> So what, in retrospect, have Parnas and Brooks said to us? That software development is a conceptually tough business. That magic solutions are not just around the corner. That it is time for the practitioner to examine evolutionary improvements rather than to wait—or hope—for revolutionary ones.

>> Some in the software field find this to be a discouraging picture. They are the ones who still thought breakthroughs were near at hand.

>> But some of us—those of us crusty enough to think that we are realists—see this as a breath of fresh air. At last, we can focus on something a little more viable than pie in the sky. Now, perhaps, we can get on with the incremental improvements to software productivity that are possible, rather than waiting for the breakthroughs that are not likely to ever come.[1]

[0]: Brooks, Frederick P.,Jr, The mythical man-month: essays on software engineering (1995), p. 226

[1]: Glass, R. L., "Glass"(column), System Development, (January 1988), pp. 4-5.

Re: AI tooling must be disclosed for contributions

#144

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?”

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

Re: AI tooling must be disclosed for contributions

#145

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?

I guess it's just different kinds of people. I have used Copilot to generate code I barely understand (stuff for a microcontroller project, nothing important) but I wouldn't in a thousand years say I wrote it. I broadly understand how it works, and like, if someone wanted to see it, I'd show them. But like... how can you take pride in something you didn't make?

Not making the thing is a point in favor of LLMs for some of these people I suspect. So the pride in work thing is just not high on the list of incentives.

I don’t get it at all. Feels like modernity is often times just inventing pale shadows of things with more addictive hooks to induce needlessly dependent behavior.

Re: AI tooling must be disclosed for contributions

#146

Earlier quoted context omitted.

The sheer amount of entitlement on display by very pro-AI people genuinely boggles the mind.

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?

That's just not true. I have 20 years of dev experience and also am using these tools. I won't commit slop. I'm open to being transparent about my usage of AI but tbh right now there's so much bias and vitriol coming from people afraid of these new tools that in the haze of their fear I don't trust people will actually take the time to neutrally determine whether or not the code is actually slop. I've had manually written, well thought through, well conceived, rough around the edges code get called "AI slop" by a colleague (who I very much respect and have a good relationship with) who admittedly hadn't had a chance to thoroughly understand the code yet.

If I just vibe-coded something and haven't looked at the code myself, that seems like a necessary thing to disclose. But beyond that, if the code is well understood and solid, I feel that I'd be clouding the conversation by unnecessarily bringing the tools I used into it. If I understand the code and feel confident in it, whether I used AI or not seems irrelevant and distracting.

This policy is just shoving the real problem under the rug. Generative AI is going to require us to come up with better curation/filtering/selection tooling, in general. This heuristic of "whether or not someone self-disclosed using LLMs" just doesn't seem very useful in the long run. Maybe it's a piece of the puzzle but I'm pretty sure there are more useful ways to sift through PRs than that. Line count differences, for example. Whether it was a person with an LLM or a 10x coder without one, a PR that adds 15000 lines is just not likely to be it.

Re: AI tooling must be disclosed for contributions

#147

How does this not lead to a situation where no honest person can use any AI in their submissions? Surely pull requests that acknowledge AI tooling will be given significantly less attention, on the grounds that no one wants to read work that they know is written by AI.

Good point. That's the point exactly. Don't use AI for writing your patch. At all. Why are you surprised? Do companies want to hire "honest" people whose CVs were written by some LLM?

I don't know if future generations will agree with this sentiment, in which case we lock ourselves out of future talent (i.e. those that use AI to assist, not to completely generate). The same arguments were made about Photoshop once upon a time.

> Do companies want to hire "honest" people whose CVs were written by some LLM?

Unfortunately yes, they very much seem to. Since many are using LLMs to assess CVs, those which use LLMs to help write their CV have a measured advantage.

Re: AI tooling must be disclosed for contributions

#148

Earlier quoted context omitted.

> try it in a language and environment you know nothing about and so aren't tempted to keep taking the wheel. That's a good insights. Its almost like to use AI tools effectively, one needs to stop caring about the little things you'd get caught up in if you were already familiar and proficient in a stack. Style guidelines, a certain idiomatic way to do things, naming conventions, etc. A lot like how I've stopped orga…

How do you know the code is correct, isn’t insecure, and performant, without caring about the code?

Not a solved problem yet, admittedly. Performance can be measured externally, but ideally we'll get to a point where certain criteria can be automatically tested/AI output be checked without manual intervention, or even before the AI actually puts text to editor.

Re: AI tooling must be disclosed for contributions

#149
post #28
post #26

There is also IP taint when using "AI". We're just pretending that there's not. If someone came to you and said "good news: I memorized the code of all the open source projects in this space, and can regurgitate it on command", you would be smart to ban them from working on code at your company. But with "AI", we make up a bunch of rationalizations. ("I'm doing AI agentic generative AI workflow boilerplate 10x gettin…

Also ban StackOverflow and nearly any text book in the field. The reality is that programmers are going to see other programmers code.

There's a reason why clean-room reverse engineering exists and it's to ensure that you can't commit copyright infringement by knowing about the code you are trying to reimplement.

Re: AI tooling must be disclosed for contributions

#150

Earlier quoted context omitted.

> I can generate 1,000 PRs today against an open source project using AI. Then perhaps the way you contribute, review, and accept code is fundamentally wrong and needs to change with the times. It may be that technologies like Github PRs and other VCS patterns are literally obsolete. We've done this before throughout many cycles of technology, and these are the questions we need to ask ourselves as engineers, not sti…

I don't think throwing out the concept of code reviews and version control is the correct response to a purported rise in low-effort high-volume patches. If anything it's even more required.

Heck, let's throw out QA, too :-))
Post reply on HN