←back to thread

Define policy forbidding use of AI code generators

(github.com)
493 points todsacerdoti | 7 comments | 25 Jun 25 23:26 UTC | HN request time: 1.859s | source | bottom
Show context
benlivengood ◴[26 Jun 25 00:21 UTC] No.44383064[source]▶
Open source and libre/free software are particularly vulnerable to a future where AI-generated code is ruled to be either infringing or public domain.

In the former case, disentangling AI-edits from human edits could tie a project up in legal proceedings for years and projects don't have any funding to fight a copyright suit. Specifically, code that is AI-generated and subsequently modified or incorporated in the rest of the code would raise the question of whether subsequent human edits were non-fair-use derivative works.

In the latter case the license restrictions no longer apply to portions of the codebase raising similar issues from derived code; a project that is only 98% OSS/FS licensed suddenly has much less leverage in takedowns to companies abusing the license terms; having to prove that infringers are definitely using the human-generated and licensed code.

Proprietary software is only mildly harmed in either case; it would require speculative copyright owners to disassemble their binaries and try to make the case that AI-generated code infringed without being able to see the codebase itself. And plenty of proprietary software has public domain code in it already.

replies(8): >>44383156 #>>44383218 #>>44383229 #>>44384184 #>>44385081 #>>44385229 #>>44386155 #>>44387156 #
AJ007 ◴[26 Jun 25 00:53 UTC] No.44383229[source]▶
I understand what experienced developers don't want random AI contributions from no-knowledge "developers" contributing to a project. In any situation, if a human is review AI code line by line that would tie up humans for years, even ignoring anything legally.

#1 There will be no verifiable way to prove something was AI generated beyond early models.

#2 Software projects that somehow are 100% human developed will not be competitive with AI assisted or written projects. The only room for debate on that is an apocalypse level scenario where humans fail to continue producing semiconductors or electricity.

#3 If a project successfully excludes AI contributions (not clear how other than controlling contributions to a tight group of anti-AI fanatics), it's just going to be cloned, and the clones will leave it in the dust. If the license permits forking then it could be forked too, but cloning and purging any potential legal issues might be preferred.

There still is a path for open source projects. It will be different. There's going to be much, much more software in the future and it's not going to be all junk (although 99% might.)

replies(16): >>44383277 #>>44383278 #>>44383309 #>>44383367 #>>44383381 #>>44383421 #>>44383553 #>>44383615 #>>44383810 #>>44384306 #>>44384448 #>>44384472 #>>44385173 #>>44386408 #>>44387925 #>>44389059 #
amake ◴[26 Jun 25 01:01 UTC] No.44383278[source]▶
> #2 Software projects that somehow are 100% human developed will not be competitive with AI assisted or written projects

Still waiting to see evidence of AI-driven projects eating the lunch of "traditional" projects.

replies(4): >>44383368 #>>44383382 #>>44383858 #>>44386542 #
viraptor ◴[26 Jun 25 01:18 UTC] No.44383368[source]▶
It's happening slowly all around. It's not obvious because people producing high quality stuff have no incentive at all to mark their changes as AI-generated. But there are also local tools generated faster than you could adjust existing tools to do what you want. I'm running 3 things now just for myself that I generated from scratch instead of trying to send feature requests to existing apps I can buy.

It's only going to get more pervasive from now on.

replies(2): >>44383499 #>>44384560 #
alganet ◴[26 Jun 25 01:44 UTC] No.44383499[source]▶
Can you show these 3 things to us?
replies(4): >>44383630 #>>44383710 #>>44383844 #>>44384062 #
WD-42 ◴[26 Jun 25 02:12 UTC] No.44383630[source]▶
For some reason these fully functional ai generated projects that the authors vibe out while playing guitar and clipping their toenails are never open source.
replies(6): >>44383999 #>>44384026 #>>44384847 #>>44385049 #>>44386161 #>>44387603 #
TeMPOraL ◴[26 Jun 25 07:26 UTC] No.44385049[source]▶
Going by the standard of "But there are also local tools generated faster than you could adjust existing tools to do what you want", here's a random one of mine that's in regular use by my wife:

https://github.com/TeMPOraL/qr-code-generator

Built with Aider and either Sonnet 3.5 or Gemini 2.5 Pro (I forgot to note that down in this project), and recently modified with Claude Code because I had to test it on something.

Getting the first version of this up was literally both faster and easier than finding a QR code generator that I'm sure is not bloated, not bullshit, not loaded with trackers, that's not using shorteners or its own URL (it's always a stupid idea to use URL shorteners you don't control), not showing ads, mining bitcoin and shit, one that my wife can use in her workflow without being distracted too much. Static page, domain I own, a bit of fiddling with LLMs.

What I can't link to is half a dozen single-use tools or faux tools created on the fly as part of working on something. But this happens to me couple times a month.

To anchor another vertex in this parameter space, I found it easier and faster to ask LLM to build me a "breathing timer" (one that counts down N seconds and resets, repeatedly) with analog indicator by requesting it, because a search query to Google/Kagi would be of comparable length, and then I'd have to click on results!

EDIT: Okay, another example:

https://github.com/TeMPOraL/tampermonkey-scripts/blob/master...

It overlays a trivial UI to set up looping over a segment of any YouTube video, and automatically persists the setting by video ID. It solves the trivial annoyance of channel jingles and other bullshit at start/end of videos that I use repeatedly as background music.

This was mostly done zero-shot by Claude, with maybe two or three requests for corrections/extra features, total development time maybe 15 minutes. I use it every day all the time ever since.

You could say, "but SponsorBlock" or whatever, but per what GP wrote, I just needed a small fraction of functionality of the tools I know exist, and it was trivial to generate that with AI.

replies(1): >>44385640 #
alganet ◴[26 Jun 25 09:24 UTC] No.44385640[source]▶
Your QR generator is actually a project written by humans repackaged:

https://github.com/neocotic/qrious

All the hard work was made by humans.

I can do `npm install` without having to pay for AI, thanks.

replies(1): >>44386366 #
ben_w ◴[26 Jun 25 11:33 UTC] No.44386366[source]▶
I am reminded of a meme about musicians. Not well enough to find it, but it was something like this:

  Real musicians don’t mix loops they bought.
  Real musicians make their own synth patches.
  Real musicians build their own instruments.
  Real musicians hand-forge every metal component in their instruments.
  …
  They say real musicians raise goats for the leather for the drum-skins, but I wouldn't know because I haven’t made any music in months and the goats smell funny.
There's two points here:

1) even though most of people on here know what npm is, many of us are not web developers and don't really know how to turn a random package into a useful webapp.

2) The AI is faster than googling a finished product that already exists, not just as an NPM package, but as a complete website.

Especially because search results require you to go through all the popups everyone stuffs everywhere because cookies, ads, before you even find out if it was actually a scam where the website you went to first doesn't actually do the right thing (or perhaps *anything*) anyway.

It is also, for many of us, the same price: free.

replies(2): >>44387121 #>>44387137 #
1. alganet ◴[26 Jun 25 13:17 UTC] No.44387137[source]▶
Ice Ice Baby getting the bass riff of Under Pressure is sampling. Making a cover is covering. Milli Vanilli is another completely different situation.

I am sorry, none of your points are made. Makes no sense.

The LLM work sounds dumb, and the suggestion that it made "a qr code generator" is disingenuous. The LLM barely did a frontend for it. Barely.

Regarding the "free" price, read the comment I replied on again:

> Built with Aider and either Sonnet 3.5 or Gemini 2.5 Pro

Paid tools.

It sounds like the author payed for `npm install`, and thinks he's on top of things and being smart.

replies(1): >>44390587 #
2. ben_w ◴[26 Jun 25 19:42 UTC] No.44390587[source]▶
> The LLM work sounds dumb, and the suggestion that it made "a qr code generator" is disingenuous. The LLM barely did a frontend for it. Barely.

Yes, and?

The goal wasn't "write me a QR library" it was "here's my pain point, solve it".

> It sounds like the author payed for `npm install`, and thinks he's on top of things and being smart.

I can put this another way if you prefer:

  Running `npm install qrious`: trivial.
  Knowing qrious exists and how to integrate it into a page: expensive.
https://www.snopes.com/fact-check/know-where-man/

> > Built with Aider and either Sonnet 3.5 or Gemini 2.5 Pro

> Paid tools.

I get Sonnet 4 for free at https://claude.ai — I know version numbers are weird in this domain, but I kinda expect that means Sonnet 3.5 was free at some point? Was it not? I mean, 3.7 is also a smaller version number but listed as "pro", so IDK…

Also I get Gemini 2.5 Pro for free at https://aistudio.google.com

Just out of curiosity, I've just tried using Gemini 2.5 Pro (for free) myself to try this. The result points to a CDN of qrcodejs, which I assume is this, but don't know my JS libraries so can't confirm this isn't just two different ones with the same name: https://github.com/davidshimjs/qrcodejs

My biggest issue with this kind of thing in coding is the same as my problem with libraries in general: you're responsible for the result even if you don't read what the library (/AI) is doing. So, I expect some future equivalent of the npm left-pad incident — memetic monoculture, lots of things fail at the same time.

replies(1): >>44390745 #
3. alganet ◴[26 Jun 25 20:02 UTC] No.44390745[source]▶
> Knowing qrious exists and how to integrate it into a page: expensive.

qrious literally has it integrated already:

https://github.com/davidshimjs/qrcodejs/blob/master/index.ht...

I see many issues. The main one is that none of this is relevant to the qemu discussion. It's on another whole level of project.

I kind of regret asking the poor guy to show his stuff. None of these tutorial projects come even close to what an AI contribution to qemu would look like. It's pointless.

replies(2): >>44390893 #>>44391009 #
4. ben_w ◴[26 Jun 25 20:20 UTC] No.44390893{3}[source]▶
The very first part of the quotation is "Knowing qrious exists".

So the fact they've already got the example is great if you do in fact already have that knowledge, and *completely useless* if you don't.

> I kind of regret asking the poor guy to show his stuff. None of these tutorial projects come even close to what an AI contribution to qemu would look like. It's pointless.

For better and worse, I suspect it's very much the kind of thing AI would contribute.

I also use it for things, and it's… well, I have seen worse code from real humans, but I don't think highly of those humans' coding skills. The AI I've used so far are solidly at the quality level of "decent for a junior developer", not more, not less. Ridiculously broad knowledge (which is why that quality level is even useful), but that quality level.

Use it because it's cheap or free, when that skill level is sufficient. Unless there's a legal issue, which there is for qemu, in which case don't.

5. TeMPOraL ◴[26 Jun 25 20:30 UTC] No.44391009{3}[source]▶
Person in question here.

I didn't know qrious exist. Last time I checked for frontend-only QR code generators myself, pre-AI, I couldn't find anything useful. I don't do frontend work daily, I'm not on top of the garbagefest the JS environment is.

Probably half the win applying AI to this project was that it a) discovered qrious for me, and b) made me a working example frontend, in less time than it would take me to find the library myself among sea of noise.

'ben_w is absolutely correct when he wrote:

> The goal wasn't "write me a QR library" it was "here's my pain point, solve it".

And:

  <quote>
  Running `npm install qrious`: trivial.
  Knowing qrious exists and how to integrate it into a page: expensive.
  </quote>
This is precisely what it was. I built this in between other stuff, paying half attention to it, to solve an immediate need my wife had. The only thing I cared about it here is that:

1. It worked and was trivial to use

2. Was 100% under my control, to guarantee no tracking, telemetry, ads, crypto miners, and other usual web dangers, are present, and ensure they never are going to be present.

3. It had no build step whatsoever, and minimal dependencies that could be vendored, because again, I don't do webshit for a living and don't have time for figuring out this week's flavor of building "Hello world" in Node land.

(Incidentally, I'm using Claude Code to build something bigger using a web stack, which forced me to figure out the current state of tooling, and believe me, it's not much like what I saw 6 months ago, and nothing like what I saw a year ago.)

2 and 3 basically translate to "I don't want to ever think about it again". Zero ops is my principle :).

----

> I see many issues. The main one is that none of this is relevant to the qemu discussion. It's on another whole level of project.

It was relevant to the topic discussed in this subthread. Specifically about the statement:

> But there are also local tools generated faster than you could adjust existing tools to do what you want. I'm running 3 things now just for myself that I generated from scratch instead of trying to send feature requests to existing apps I can buy.

The implicit point of larger importance is: AI contributions may not show up fully polished in OSS repos, but making it possible to do throwaway tools to address pain points directly provides advantages that compound.

And my examples are just concrete examples of projects that were AI generated with a mindset of "solve this pain point" and not "build a product", and making them took less time and effort than my participation in this discussion already did.

replies(1): >>44391176 #
6. alganet ◴[26 Jun 25 20:46 UTC] No.44391176{4}[source]▶
Cool, makes sense.

Since you're here, I have another question relevant to the thread: do you pay for AI tools or are you using them for free?

replies(1): >>44391441 #
7. TeMPOraL ◴[26 Jun 25 21:13 UTC] No.44391441{5}[source]▶
TL;DR: I pay, I always try to use SOTA models if I can.

I pay for them; until last week, this was almost entirely[0] pay-as-you-go use of API keys via TypingMind (for chat) and Aider (for coding). The QR code project I linked was made by Aider. Total cost was around $1 IIRC.

API options were, until recently, very cheap. Most of my use was around $2 to $5 per project, sometimes under $2. I mostly worked with GPT-4, then Sonnet 3.5, briefly with Deepseek-R1; by the time I got around to testing Claude Sonnet 3.7, Google released Gemini 2.5 Pro, which was substantially cheaper, so I stuck to the latter.

Last week I got myself the Max plan for Anthropic (first 5x, then the 20x one) specifically for Claude Code, because using pay-as-you-go pricing with top models in the new "agentic" way got stupidly expensive; $100 or $200 per month may sound like a lot, but less so when taking the API route would have you burn this much in a day or two.

--

[0] - I have the $20/month "Plus" subscription to ChatGPT, which I keep because of gpt-4o image generation and o3 being excellent as my default model for random questions/problems, many of them not even coding-related. I could access o3 via API, but this gets stupidly expensive for casual use; subscription is a better deal now.