I use LLMs for generating documentation- I write my code, and ask Claude to write my documentation
I think you are doing it the wrong way around.
Define policy forbidding use of AI code generators
171–180 of 427 posts
Re: Define policy forbidding use of AI code generators
#172Interesting. Harder line than the LLVM one found at https://llvm.org/docs/DeveloperPolicy.html#ai-generated-cont... I'm very old man shouting at clouds about this stuff. I don't want to review code the author doesn't understand and I don't want to merge code neither of us understand.
>I don't want to review code the author doesn't understand
I get that. But the AI tooling when guided by a competent human can generate some pretty competent code, a lot of it can be driven entirely through natural language instructions. And every few months, the tooling is getting significantly more capable.
I'm contemplating what exactly it means to "understand" the code though. In the case of one project I'm working on, it's an (almost) entirely vibe-coded new storage backend to an existing VM orchestration system. I don't know the existing code base. I don't really have the time to have implemented it by hand (or I would have done it a couple years ago).
But, I've set up a test cluster and am running a variety of testing scenarios on the new storage backend. So I understand it from a high level design, and from the testing of it.
As an open source maintainer myself, I can imagine (thankfully I haven't been hit with it myself) how frustrating getting all sorts of low quality LLM "slop" submissions could be. I also understand that I'm going to have to review the code coming in whether or not the author of the submission understands it.
So how, as developers, do we leverage these tools as appropriate, and signal to other developers the level of quality in code. As someone who spent months tracking down subtle bugs in early Linux ZFS ports, I deeply understand that significant testing can trump human authorship and review of every line of code. ;-)
Re: Define policy forbidding use of AI code generators
#173Earlier quoted context omitted.
> There is a well settled practice in computing that you just don't plagiarize code. Even a small snippet. I think way many developers use StackOverflow suggests otherwise.
In the first place, in order to post to StackOverflow, you are required to have the copyright over the code, and be able to grant them a perpetual license. They redistribute the material under the CC BY-SA 4.0 license. https://creativecommons.org/licenses/by-sa/4.0/ This allows visitors to use the material, with attribution. One can, of course, use the ideas in a SO answer to develop one's own solution.
Show me the professional code base with the attribution to stack overflow and I'll eat my hat.
Re: Define policy forbidding use of AI code generators
#174Earlier quoted context omitted.
Dude, have you ever looked at code you wrote 6 months ago and gone "What was the developer thinking?" ;-)
yes, constantly. I also don't remember much contextual domain info of a given section of code about 2 weeks into delving into some other part of the same app. So-called AI makes this worse. Let me remind you of gyms, now that humans have been saved of much manual activity...
>So-called AI makes this worse.
The AI tooling is also really, really good at being able to piece together the code, the contextual domain, the documentation, the tests, the related issues/tickets, it could even take the change history into account, and be able to help refresh your memory of unfamiliar code in the context of bugs or new changes you are looking at making.
Whether or not you go to the gym, you are probably going to want to use an excavator if you are going to dig a basement.
Re: Define policy forbidding use of AI code generators
#175Earlier quoted context omitted.
> or public domain https://news.artnet.com/art-world/ai-art-us-copyright-office... https://en.wikipedia.org/wiki/Monkey_selfie_copyright_disput... Im pretty sure that this ship has sailed.
It's sailed, but towards the other way: https://www.bbc.com/news/articles/cg5vjqdm1ypo
https://www.wired.com/story/ai-art-copyright-matthew-allen/
https://www.cnbc.com/2025/03/19/ai-art-cannot-be-copyrighted...
Here are cases where the product of AI/ML are not the products of people and not capable of being copyrighted. These are about the OUTPUT being unable to be copyrighted.
Re: Define policy forbidding use of AI code generators
#176Earlier quoted context omitted.
I'd also worry that a language model is much more likely to introduce subtle logical errors, potentially ones which violate the hypervisor's security boundaries - and a user relying heavily on that model to write code for them will be much less prepared to detect those errors.
Generally speaking AI will make it easier to write more secure code. Tooling and automation help a lot with security and AI makes it easier to write good tooling. I would wager good money that in a few years the most security-focused companies will be relying heavily on AI somewhere in their software supply chain. So I don't think this policy is about security posture. No doubt human experts are reviewing the securit…
I'd doubt this very much - LLMs hallucinate API calls and commit all sorts of subtle errors that you need to catch (esp. if you're on proprietary problems which it's not trained on).
It's a good replacement for Google, but probably nothing close to what it's being hyped out to be by the capital allocators.
Re: Define policy forbidding use of AI code generators
#177Earlier quoted context omitted.
Can you show these 3 things to us?
Not OP, but: I'm getting towards the end of a vibe coded ZFS storage backend to ganeti that includes the ability to live migrate VMs to another host by: taking snapshot and replicating it to target, pausing VM, taking another incremental snapshot and replicating it, and then unpausing the VM on the new destination machine. https://github.com/linsomniac/ganeti/tree/newzfs Other LLM tools I've built this week: This aft…
I vibe-coded my own MySQL-compatible database that performs better than MariaDB, after my agent optimized it for 12 hours. It is also a time-traveling DB and performs better on all benchmarks and the AI says it is completely byzantine-fault-tolerant. Programmers, you had a nice run. /s
Re: Define policy forbidding use of AI code generators
#178Earlier quoted context omitted.
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.
> the authors vibe out while playing guitar and clipping their toenails I don't think anyone is claiming that. If you submit changes to a FOSS project and an LLM assisted you in writing them how would anyone know? Assuming at least that you are an otherwise competent developer and that you carefully review all code before you commit it. The (admittedly still controversial) claim being made is that developers with LLM…
Why would you need to carefully review code? That is so 2024. You’re bottlenecking the process and are at a disadvantage when the AI could be working 24/7. We have AI agents that have been trained to review thousands of PRs that are produced by other, generative agents, and together they have already churned out much more software than human teams can write in a year.
AI “assistance” is a short intermediate phase, like the “centaurs” that Garry Kasparov was very fond of (human + computer beat both a human and a computer by itself… until the computer-only became better).
Re: Define policy forbidding use of AI code generators
#179Earlier quoted context omitted.
> #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.
that's like driving big personal vehicles and having a bunch of children and eating a bunch of meat and do nothing about because marine and terrestrial ecosystems weren't fully destroyed by global warming
Ahh, there you go, environmental activists outright saying having children is considered a crime against nature. Wonderful, you seem to hit a rather bad stereotype right on the head. What is next? Earth would be better of if humanity was eradicated?
Re: Define policy forbidding use of AI code generators
#180Open 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 res…
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 no…
It seems to me that the point in your first paragraph argues against your points #2 and #3.
If a project allows AI generated contributions, there's a risk that they'll be flooded with low quality contributions that consume human time and resources to review, thus paralyzing the project - it'd be like if you tried to read and reply to every spam email you receive.
So the argument goes that #2 and #3 will not materialize, blanket acceptance of AI contributions will not help projects become more competitive, it will actually slow them down.
Personally I happen to believe that reality will converge somewhere in the middle, you can have a policy which says among other things "be measured in your usage of AI," you can put the emphasis on having contributors do other things like pass unit tests, and if someone gets spammy you can ban them. So I don't think AI is going to paralyze projects but I also think its role in effective software development is a bit narrower than a lot of people currently believe...