Project includes an Apache license, but code created by an AI is not copyrightable and it’s output is in the public domain.
> Ginux is available under the Apache License 2.0. See LICENSE and NOTICE.
Zarya of the Dawn concludes that human direction and selection is not enough to produce a copyrightable work from AI generated content. Without copyright, there is no legal basis to offer a license. The code is public domain or worse, mislicensed, AI washed GPL or BSD.
AI code being public domain doesn't preclude a license. Code under public domain can be incorporated on a work regardless of its license. The license will apply to the combined work as a whole, even though the portion under public domain will remain public domain.
For example, if I take a public domain file and incorporate it into my GPL project, if you make a derivative of the project as a whole, you still need to follow the GPL. But you can also take that file and use it with no regard for the project's license, since the file itself is public domain.
You cannot take a public domain work and choose to relicense it with something more restrictive. Licensing is based on copyright. If you have no copyright, you cannot license. Attempting to do so is fraud.
The NOTICE or other document could specify which parts are covered under copyright, but they do not. Apache 2.0 restricts what others can do with this (as limited as those requirements are). This is not allowed under current copyright laws.
> Zarya of the Dawn concludes that human direction and selection is not enough to produce a copyrightable work from AI generated content. Without copyright, there is no legal basis to offer a license. The code is public domain or worse, mislicensed, AI washed GPL or BSD.
I am of the opinion that there is very little humans can do that other reasonably competent humans cannot also do. So the entire idea of IPR is a joke, but the idea has been with us for a few centuries and might stay on for one more.
That said, human direction is critical in so many things. A camera can be operated by any monkey; all you need to do is click a button. But knowing how to focus, what to focus on, and so may of those tiny decisions is what makes photography an art form. There are hundreds of such fields where the actual human effort involves providing direction to an otherwise mechanical process.
> code created by an AI is not copyrightable and it’s output is in the public domain
This isn't settled yet, and while the license may ultimately be meaningless, it lets people compile and use the code without risking copyright law violation.
I do agree about AI washing though, ethically any code you generate using AI should be licensed as similarly to the source material as possible.
A USCO opinion, and then two more confirmations of that opinion, one before Congress, is not settled? Unless the law changes the only thing licensable is the prompts.
USCO doesn't make the law nor do they decide what the law says, they just register Copyrights. However, registration is not necessary for a work to be protected under Copyright law.
Congress makes the law then the Court interprets it, which hasn't happened yet.
If choosing the position / angle of a camera and its settings is enough to gain Copyright over the images it generates then prompting a model to generate an image is enough too. I don't see how anyone can come to any other conclusion.
The creativity bar for Copyright is not high. An alphabetically ordered list of customers does not meet it. Pointing a camera at someone and pushing the button does.
Congress has made the laws and USCO interprets them and makes rules based on its interpretation. Those are the implementation of those laws.
Directing is not copyrightable. The person who takes the picture owns the copyright (fixation rule) unless some other contract says otherwise. Treating the prompt writer as a director reduces their claim to ownership.
The opinion was only for fully ai-generated content, notably the human-authored components of the comic were still protected. Whats unsettled is when the artifact is built up over multiple rounds of targeted edits to existing output in collaboration with a human, and whether that output is protected.
I'm guessing there's too much money in that being protected for it not to be protected so, no I think providing LICENSE is still worthwhile.
There was a thing, but it didn't happen often, where a GPL advocate would take an MIT or BSD license project, make some additions, license their changes under the GPL, and effectively copyleft their release of the combined work.
I'm not a lawyer, but I don't think the law is simple.
Code exists in the Linux kernel that is licensed under permissive licenses. This works because (some) permissive licenses contain no restrictions incompatible with releasing the code and/or derivative works under the GPL.
This is why the original BSD license (with advertising clause) was incompatible with the GPL, while BSD without the advertising clause is not.
"Public domain" is not a license, and has different meanings in different jurisdictions, and thus it can be useful to release code under a license even if the intent is unrestricted use.
Y'all I get that the term "vibe coding" feels derogatory and that it took off as a term before it took over regular dev work too. But we're kinda stuck with the name and running away from it with "Agentic Engineering" or "Human-Directed AI Engineering" to try and distinguish from some normie asking Claude to make a random app iw just not gonna stick. Maybe if we go with "vibe engineering" as a tongue in cheek sort of name but I think running away from the "vibe" part of vibe coding to describe agentic dev is just not gonna work nobody's gonna let us get away with it
Tasks like ×× that are compatible with 〇〇 are what AI excels at most. This is because the process of expanding compatibility can be improved incrementally, and the acceptance criteria are clear.
1. Prepare one item that works with 〇〇
2. Make it work with ××
3. Return to (1) until it is deemed sufficient
4. Prepare 100 items that work with 〇〇
5. Measure performance with ××
6. Measure performance with 〇〇
7. Consider several performance improvement measures
8. Implement improvement measures while verifying that compatibility is not compromised
9. Return to (4) until it is determined that performance has improved sufficiently
10. Completion of ××, which is sufficiently compatible with 〇〇 and not inferior in performance
The things described at that link cannot be fixed in any simple way.
There it is said that Ginux does not implement mutual exclusion in the right way for a multiprocessor.
To implement this correctly and in a way that ensures high performance even on CPUs with hundreds of cores is one of the most difficult parts of an operating system kernel, much more difficult than just implementing the system call interfaces, to enable a user program to run.
Other point is that Ginux is vulnerable to some races caused by interrupts, which is again something difficult to get right in an operating system kernel, unless you copy exactly the corresponding code from the Linux kernel.
From a practical point of view, Ginux cannot be called anything else except a toy operating system kernel, at the level that previously could have been a home project for one student at an OSes course.
Of course, despite being a toy, Ginux is an impressive accomplishment by being good enough to run an unmodified Linux user program, and its implementation with an LLM has required at least an order of magnitude less time than a human student would have needed.
Still, there is a very long way from a demo like this to seeing an LLM that can generate autonomously a real operating system kernel, without further interaction with a human after the initial specification.
It should be remembered that the main purpose of an operating system kernel is not implementing the API of the system calls used by the user programs, which is the trivial part of its functions. The kernel is the manager of the shared resources of a computer system, like CPU time, memory, peripherals, which allocates them to user programs and ensures that their usage is maximally efficient and that the user processes cannot use the shared resources otherwise than as decided by the kernel. This is something that Ginux has not accomplished at all, based on the description from the link provided above.
Most of the comments here are super salty. Agentic coding is here to stay, and the authors are here to make it better.
And as a test case they built a Linux-compatibe thing in Rust!
Al of this is cool to me, but what I read here in the comments: slop, stealing, evil people, no trust, etc.
Linux is open source: the license says that it can be used for any purpose, which includes training an LLM.
LLMs have made developers more powerful (like IDEs did, or CI/CD did, or better programming languages did, or Github did, or ...), but all I hear is nagging.
Because at some point if (big if) this trajectory keeps up the end goal is for all software to be fully democratized and created on demand. Operating system included.
> Linux is open source: the license says that it can be used for any purpose, which includes training an LLM.
The licence says that you have to distribute the modified sources under the same licence. IMHO the least Ginux could do is licence their work as GPLv2.
I don't think they are 'just a tool', just like drugs aren't just a tool but a method to subjugate. Sometimes, with tools of sufficient complexity, the intention of the tool cannot be separated from the tool itself so much so that the tool and the intention and human values behind the tool cannot be separated.
> Ginux is a research prototype, not a production kernel or Linux replacement. The larger lesson is that AI can generate complex systems software, but compatibility, security, hardware support, standards, community, and long-term maintenance remain the real moat.
Why does it seem like HDAE is just a new term to distract from terms like "vibecoded" and "AI slop"?
Because the bigger the project, the more unlikely it is for a human to review all the code. And in this case we're talking about re-making the Linux kernel.
- AI slop is clearly negative. "Lacking in effort", "low quality".
- Vibecoding, I believe, tends to mean "letting the AI do it without putting much effort into it". So vibecoding produces AI slop.
- HDAE, that this article tries to define, is "a method for building complex software by combining human-defined architecture, constraints, milestones, acceptance criteria, and stopping points with an autonomous implementation, execution, diagnosis, and revision loop".
In other words, they say "it is actually possible to put a lot of effort into producing code with AI". And I personally don't disagree with that.
Now of course, it feels like marketing, a bit. "I will present you how I built this kernel as an effort to make you accept it as "not slop", by trying to convince you that I put a lot of effort into producing it".
IMO, it does not really matter. Whether code is written by a random person on the Internet, vibecoded by a random person on the Internet or HDAE-ed by a random person on the Internet, it should not be trusted unless audited. If it happens that vibecoded code is good, I don't see a reason not to use it. If HDAE-ed code is bad, it should not be used.
I played with the idea of starting a new Linux distro called "Slopware", which accepts basically everything from either humans or AI but requires rigorous testing and development processes, raising the quality to levels realistically unreachable by single human developers.
Not sure if that naming choice would have been a good idea though. :)
good balanced view. Regardless of how much effort is put into AI writing correctly, humans should review and understand.
the last part is tricky on these kinds of projects.
Just look at the bugs coming out in Linux or other kernels. Often they are very subtle errors based in very subtle misunderstandings.
This is why you'd want a lot of different people involved who in their combined knowledge have a good chance to understand enough to make such a project a success, even IF all they do is review the AI code.
> Often they are very subtle errors based in very subtle misunderstandings.
I'd like to address this specifically. Introducing a very subtle bug can be an adversarial move, right? Say I want to introduce an exploit into a project, I can try to do that. And it is a risk in any open source project where contributions come from "random people on the Internet".
Now my question: as a maintainer, is it better for me to try to convince myself that all those contributions I receive from random people are well intentioned (and maybe miss subtle bugs that were introduced on purpose), or is it better to have an AI replace those contributors?
I don't have an answer, but I think it is an interesting question. As a maintainer, my bottleneck has generally been more around reproducing, understanding the bug and testing. Less around producing the code. And an AI can produce the code I ask it to produce, copying my style, and I can ask it to start over as often as I want.
Most contributors nowadays probably use LLM. And those who don't, often produce code worse than LLM.
If you're not OK with random code, you gotta rewrite everything yourself. So treat their contributions just as inspiration and work from there.
And if you're OK with random code, maybe it's safer to just use LLM and ask it to rewrite the contributed code? At least you know that LLM is not ill-intentioned.
Yeah, that's pretty much exactly what I meant, but you expressed it better.
> At least you know that LLM is not ill-intentioned.
It's more complicated than that, but yeah... I see what you mean here and I agree :-). Probably the LLM is not trained to insert bugs into my repositories, I guess? But anyway, in the future I could totally imagine that some open weight models are "mainstream" and "audited", at which point it sounds harder to target my repo from the LLM than from a PR by a random account.
IME it is much, much more difficult to review code that is the result of a LLM regurgitation than to review human-written code made by someone even a bit experienced in programming - even more so if the human in question is a domain expert.
For one, LLMs tend to waffle and produce code that works but is much more extensive and/or unintuitively organized than code that a human writes. The bigger thing however is testing. LLM code tends to test itself, whereas a domain expert human tends to have many more domain-specific edge cases in mind.
Maybe, yeah. But isn't possible for a human to write "bad code", too?
Does it matter if it comes from a human you don't know or an AI you don't know? If it's difficult to review for the maintainers, then the maintainers should not merge it.
Let me put it this way: if a random contributor opens a PR as a human, then the maintainers will do what they were doing before AI, right? Now if a random contributor opens a PR pretending to be written manually, but actually written with the help of an AI, what will the maintainers do? Exactly the same, right? Try to read and understand the contribution, and merge it if they want to take responsibility of it.
The difference, really, is that everyone and their dog can now open a PR that looks evolved, and for maintainers it's difficult because it adds noise.
> But isn't possible for a human to write "bad code", too?
Sure. But I'd trust someone whom I know to be a domain expert and a good coder much more than some random github account. And once I see anything like "co-authored-by: claude"... oh hell no I'll go over that with a fine toothed comb because I have zero idea what the user prompted into the LLM, which in turn means I don't know what edge cases the author (and by extension the LLM) even knew about.
Yeah I agree. At the end of the day, the question boils down to whether or not the contribution is helping the maintainer, right?
As a maintainer, if it's easier for me to ask an AI to do it, then I will do that. Now depends on what "easier" is. Maybe a question of trust (if I don't trust a random contributor, I may as well do it myself), maybe a question of testing it (if a contributor can show me that it works on their 5 devices I don't own, it may have value).
But the fact that it was written by AI is not the biggest factor, IMO. Proven by the fact that if the AI writes exactly what I wanted, then I will be happy to merge it.
LLMs will eat software. Much, not all, of software is taking ideas into a strict language, compile to a stricter language and check if the processing unit will run it. There are a ton of algorithms and many can be combined with many others.
A token prediction system that has built a multi-dimensional model of all tokens on the Internet should be good at generating a bunch of algorithm combinations. Then it is about a loop to test, find out other combinations, find a winner.
On this, I was recently wondering if Anthropic at some point will make an announcement of full re-implementation of Linux kernel in Rust. But maybe that would be a too-niche of a news to affect their IPO.
Okay I made this comment based on the title, assuming it meant a sort of "reimplementation" of the linux kernel running in userspace, similar to gvisor (an application kernel).
But that does not in fact seem to be what this is. In fact I can discern no architectural decisions that would differentiate this from Linux in any way. So what is it? We vibecoded an OPEN SOURCE piece of software??? Genuinely so confused by this...
I agree that it is mostly entirely pointless; but I don't think the goal was to make something useful, rather to prove that "HDAE" can in-fact produce a kernel capable of running some unmodified Linux applications
The true problem is that if a method exists to do something to get attention, it will be used. And when the only means of getting attention is in a social-media algorithm-powered world, the results are typically abysmal...
Project includes an Apache license, but code created by an AI is not copyrightable and it’s output is in the public domain.
> Ginux is available under the Apache License 2.0. See LICENSE and NOTICE.
Zarya of the Dawn concludes that human direction and selection is not enough to produce a copyrightable work from AI generated content. Without copyright, there is no legal basis to offer a license. The code is public domain or worse, mislicensed, AI washed GPL or BSD.
AI code being public domain doesn't preclude a license. Code under public domain can be incorporated on a work regardless of its license. The license will apply to the combined work as a whole, even though the portion under public domain will remain public domain.
For example, if I take a public domain file and incorporate it into my GPL project, if you make a derivative of the project as a whole, you still need to follow the GPL. But you can also take that file and use it with no regard for the project's license, since the file itself is public domain.
You cannot take a public domain work and choose to relicense it with something more restrictive. Licensing is based on copyright. If you have no copyright, you cannot license. Attempting to do so is fraud.
The NOTICE or other document could specify which parts are covered under copyright, but they do not. Apache 2.0 restricts what others can do with this (as limited as those requirements are). This is not allowed under current copyright laws.
> Zarya of the Dawn concludes that human direction and selection is not enough to produce a copyrightable work from AI generated content. Without copyright, there is no legal basis to offer a license. The code is public domain or worse, mislicensed, AI washed GPL or BSD.
I am of the opinion that there is very little humans can do that other reasonably competent humans cannot also do. So the entire idea of IPR is a joke, but the idea has been with us for a few centuries and might stay on for one more.
That said, human direction is critical in so many things. A camera can be operated by any monkey; all you need to do is click a button. But knowing how to focus, what to focus on, and so may of those tiny decisions is what makes photography an art form. There are hundreds of such fields where the actual human effort involves providing direction to an otherwise mechanical process.
I’m not saying current copyright law is correct, moral, or otherwise.
Just trying to bring awareness to the absolute crap show that is going to happen when these start getting litigated, RIAA style.
> code created by an AI is not copyrightable and it’s output is in the public domain
This isn't settled yet, and while the license may ultimately be meaningless, it lets people compile and use the code without risking copyright law violation.
I do agree about AI washing though, ethically any code you generate using AI should be licensed as similarly to the source material as possible.
A USCO opinion, and then two more confirmations of that opinion, one before Congress, is not settled? Unless the law changes the only thing licensable is the prompts.
USCO doesn't make the law nor do they decide what the law says, they just register Copyrights. However, registration is not necessary for a work to be protected under Copyright law.
Congress makes the law then the Court interprets it, which hasn't happened yet.
If choosing the position / angle of a camera and its settings is enough to gain Copyright over the images it generates then prompting a model to generate an image is enough too. I don't see how anyone can come to any other conclusion.
The creativity bar for Copyright is not high. An alphabetically ordered list of customers does not meet it. Pointing a camera at someone and pushing the button does.
Congress has made the laws and USCO interprets them and makes rules based on its interpretation. Those are the implementation of those laws.
Directing is not copyrightable. The person who takes the picture owns the copyright (fixation rule) unless some other contract says otherwise. Treating the prompt writer as a director reduces their claim to ownership.
(Edit to to clarify interpretation of parent)
The opinion was only for fully ai-generated content, notably the human-authored components of the comic were still protected. Whats unsettled is when the artifact is built up over multiple rounds of targeted edits to existing output in collaboration with a human, and whether that output is protected.
I'm guessing there's too much money in that being protected for it not to be protected so, no I think providing LICENSE is still worthwhile.
There was a thing, but it didn't happen often, where a GPL advocate would take an MIT or BSD license project, make some additions, license their changes under the GPL, and effectively copyleft their release of the combined work.
I'm not a lawyer, but I don't think the law is simple.
Code exists in the Linux kernel that is licensed under permissive licenses. This works because (some) permissive licenses contain no restrictions incompatible with releasing the code and/or derivative works under the GPL.
This is why the original BSD license (with advertising clause) was incompatible with the GPL, while BSD without the advertising clause is not.
"Public domain" is not a license, and has different meanings in different jurisdictions, and thus it can be useful to release code under a license even if the intent is unrestricted use.
Y'all I get that the term "vibe coding" feels derogatory and that it took off as a term before it took over regular dev work too. But we're kinda stuck with the name and running away from it with "Agentic Engineering" or "Human-Directed AI Engineering" to try and distinguish from some normie asking Claude to make a random app iw just not gonna stick. Maybe if we go with "vibe engineering" as a tongue in cheek sort of name but I think running away from the "vibe" part of vibe coding to describe agentic dev is just not gonna work nobody's gonna let us get away with it
Tasks like ×× that are compatible with 〇〇 are what AI excels at most. This is because the process of expanding compatibility can be improved incrementally, and the acceptance criteria are clear.
1. Prepare one item that works with 〇〇 2. Make it work with ×× 3. Return to (1) until it is deemed sufficient 4. Prepare 100 items that work with 〇〇 5. Measure performance with ×× 6. Measure performance with 〇〇 7. Consider several performance improvement measures 8. Implement improvement measures while verifying that compatibility is not compromised 9. Return to (4) until it is determined that performance has improved sufficiently 10. Completion of ××, which is sufficiently compatible with 〇〇 and not inferior in performance
An initial review found a few things: https://social.kernel.org/notice/BBry0fMLEodHRiUqGW
Apparently they got fixed by now.
The things described at that link cannot be fixed in any simple way.
There it is said that Ginux does not implement mutual exclusion in the right way for a multiprocessor.
To implement this correctly and in a way that ensures high performance even on CPUs with hundreds of cores is one of the most difficult parts of an operating system kernel, much more difficult than just implementing the system call interfaces, to enable a user program to run.
Other point is that Ginux is vulnerable to some races caused by interrupts, which is again something difficult to get right in an operating system kernel, unless you copy exactly the corresponding code from the Linux kernel.
From a practical point of view, Ginux cannot be called anything else except a toy operating system kernel, at the level that previously could have been a home project for one student at an OSes course.
Of course, despite being a toy, Ginux is an impressive accomplishment by being good enough to run an unmodified Linux user program, and its implementation with an LLM has required at least an order of magnitude less time than a human student would have needed.
Still, there is a very long way from a demo like this to seeing an LLM that can generate autonomously a real operating system kernel, without further interaction with a human after the initial specification.
It should be remembered that the main purpose of an operating system kernel is not implementing the API of the system calls used by the user programs, which is the trivial part of its functions. The kernel is the manager of the shared resources of a computer system, like CPU time, memory, peripherals, which allocates them to user programs and ensures that their usage is maximally efficient and that the user processes cannot use the shared resources otherwise than as decided by the kernel. This is something that Ginux has not accomplished at all, based on the description from the link provided above.
I recently built a concept Linux OS with the entire UI generated by a local AI model based on the user's intend. https://github.com/codetiger/velliangiri
Most of the comments here are super salty. Agentic coding is here to stay, and the authors are here to make it better.
And as a test case they built a Linux-compatibe thing in Rust!
Al of this is cool to me, but what I read here in the comments: slop, stealing, evil people, no trust, etc.
Linux is open source: the license says that it can be used for any purpose, which includes training an LLM.
LLMs have made developers more powerful (like IDEs did, or CI/CD did, or better programming languages did, or Github did, or ...), but all I hear is nagging.
But you're basically rehashing things that have already been made by humans. What's the use in that?
We don't want or need hundreds of LLM generated Unix-clones which are merely slight variations on the Linux source code.
Because at some point if (big if) this trajectory keeps up the end goal is for all software to be fully democratized and created on demand. Operating system included.
> We don't want or need hundreds of LLM generated Unix-clones which are merely slight variations on the Linux source code.
Good news, you don't have to use them. People want to build them, to learn, to explore, to feel good.
I'd argue that that's not even a good thing any more. It's borderline just drug use, and at the cost of huge amounts of energy.
That's what people said about forks in open source: "we do not want them".
Apparently there's someone who wants them... The programmer who made it.
Funny how we're all for freedom and free expression, until we find someone not properly investing their time /s
> Linux is open source: the license says that it can be used for any purpose, which includes training an LLM.
The licence says that you have to distribute the modified sources under the same licence. IMHO the least Ginux could do is licence their work as GPLv2.
[flagged]
And you, the new account holder, want others to take you seriously? What are you even mad about?
LLMs are a tool. Every tool renders some work obsolete. Some of us realize this and are using the new tool. Others will have to find new work. Chill.
I don't think they are 'just a tool', just like drugs aren't just a tool but a method to subjugate. Sometimes, with tools of sufficient complexity, the intention of the tool cannot be separated from the tool itself so much so that the tool and the intention and human values behind the tool cannot be separated.
> The license assumed benevolent humans.
You do make me laugh.
> The Pelican guy is also no longer taken seriously.
This part I agree with.
For context, the author of this is one of the creators of Rocky Linux, so it's probably not just vibecoded rubbish.
https://gmkurtzer.github.io/
https://x.com/gmkurtzer/status/2114958282481910115
> Ginux is a research prototype, not a production kernel or Linux replacement. The larger lesson is that AI can generate complex systems software, but compatibility, security, hardware support, standards, community, and long-term maintenance remain the real moat.
Why does it seem like HDAE is just a new term to distract from terms like "vibecoded" and "AI slop"?
Because the bigger the project, the more unlikely it is for a human to review all the code. And in this case we're talking about re-making the Linux kernel.
My guess:
- AI slop is clearly negative. "Lacking in effort", "low quality".
- Vibecoding, I believe, tends to mean "letting the AI do it without putting much effort into it". So vibecoding produces AI slop.
- HDAE, that this article tries to define, is "a method for building complex software by combining human-defined architecture, constraints, milestones, acceptance criteria, and stopping points with an autonomous implementation, execution, diagnosis, and revision loop".
In other words, they say "it is actually possible to put a lot of effort into producing code with AI". And I personally don't disagree with that.
Now of course, it feels like marketing, a bit. "I will present you how I built this kernel as an effort to make you accept it as "not slop", by trying to convince you that I put a lot of effort into producing it".
IMO, it does not really matter. Whether code is written by a random person on the Internet, vibecoded by a random person on the Internet or HDAE-ed by a random person on the Internet, it should not be trusted unless audited. If it happens that vibecoded code is good, I don't see a reason not to use it. If HDAE-ed code is bad, it should not be used.
I played with the idea of starting a new Linux distro called "Slopware", which accepts basically everything from either humans or AI but requires rigorous testing and development processes, raising the quality to levels realistically unreachable by single human developers.
Not sure if that naming choice would have been a good idea though. :)
Isn't that what Omarchy is trying to do? Sloparchy maybe, for the name? :-)
good balanced view. Regardless of how much effort is put into AI writing correctly, humans should review and understand.
the last part is tricky on these kinds of projects.
Just look at the bugs coming out in Linux or other kernels. Often they are very subtle errors based in very subtle misunderstandings.
This is why you'd want a lot of different people involved who in their combined knowledge have a good chance to understand enough to make such a project a success, even IF all they do is review the AI code.
> Often they are very subtle errors based in very subtle misunderstandings.
I'd like to address this specifically. Introducing a very subtle bug can be an adversarial move, right? Say I want to introduce an exploit into a project, I can try to do that. And it is a risk in any open source project where contributions come from "random people on the Internet".
Now my question: as a maintainer, is it better for me to try to convince myself that all those contributions I receive from random people are well intentioned (and maybe miss subtle bugs that were introduced on purpose), or is it better to have an AI replace those contributors?
I don't have an answer, but I think it is an interesting question. As a maintainer, my bottleneck has generally been more around reproducing, understanding the bug and testing. Less around producing the code. And an AI can produce the code I ask it to produce, copying my style, and I can ask it to start over as often as I want.
Most contributors nowadays probably use LLM. And those who don't, often produce code worse than LLM.
If you're not OK with random code, you gotta rewrite everything yourself. So treat their contributions just as inspiration and work from there.
And if you're OK with random code, maybe it's safer to just use LLM and ask it to rewrite the contributed code? At least you know that LLM is not ill-intentioned.
Yeah, that's pretty much exactly what I meant, but you expressed it better.
> At least you know that LLM is not ill-intentioned.
It's more complicated than that, but yeah... I see what you mean here and I agree :-). Probably the LLM is not trained to insert bugs into my repositories, I guess? But anyway, in the future I could totally imagine that some open weight models are "mainstream" and "audited", at which point it sounds harder to target my repo from the LLM than from a PR by a random account.
IME it is much, much more difficult to review code that is the result of a LLM regurgitation than to review human-written code made by someone even a bit experienced in programming - even more so if the human in question is a domain expert.
For one, LLMs tend to waffle and produce code that works but is much more extensive and/or unintuitively organized than code that a human writes. The bigger thing however is testing. LLM code tends to test itself, whereas a domain expert human tends to have many more domain-specific edge cases in mind.
Maybe, yeah. But isn't possible for a human to write "bad code", too?
Does it matter if it comes from a human you don't know or an AI you don't know? If it's difficult to review for the maintainers, then the maintainers should not merge it.
Let me put it this way: if a random contributor opens a PR as a human, then the maintainers will do what they were doing before AI, right? Now if a random contributor opens a PR pretending to be written manually, but actually written with the help of an AI, what will the maintainers do? Exactly the same, right? Try to read and understand the contribution, and merge it if they want to take responsibility of it.
The difference, really, is that everyone and their dog can now open a PR that looks evolved, and for maintainers it's difficult because it adds noise.
> But isn't possible for a human to write "bad code", too?
Sure. But I'd trust someone whom I know to be a domain expert and a good coder much more than some random github account. And once I see anything like "co-authored-by: claude"... oh hell no I'll go over that with a fine toothed comb because I have zero idea what the user prompted into the LLM, which in turn means I don't know what edge cases the author (and by extension the LLM) even knew about.
Yeah I agree. At the end of the day, the question boils down to whether or not the contribution is helping the maintainer, right?
As a maintainer, if it's easier for me to ask an AI to do it, then I will do that. Now depends on what "easier" is. Maybe a question of trust (if I don't trust a random contributor, I may as well do it myself), maybe a question of testing it (if a contributor can show me that it works on their 5 devices I don't own, it may have value).
But the fact that it was written by AI is not the biggest factor, IMO. Proven by the fact that if the AI writes exactly what I wanted, then I will be happy to merge it.
Because it most certainly is.
Because we clearly need different terms to describe radically different processes that lead to different outcomes.
Gotta have a corpspeak acronym for your slop.
I do not trust most research published on zenodo, in my experience almost everything there equates to AI Slop.
LLMs will eat software. Much, not all, of software is taking ideas into a strict language, compile to a stricter language and check if the processing unit will run it. There are a ton of algorithms and many can be combined with many others.
A token prediction system that has built a multi-dimensional model of all tokens on the Internet should be good at generating a bunch of algorithm combinations. Then it is about a loop to test, find out other combinations, find a winner.
On this, I was recently wondering if Anthropic at some point will make an announcement of full re-implementation of Linux kernel in Rust. But maybe that would be a too-niche of a news to affect their IPO.
Just vibe your app to run directly on CPU, why bother with vibed in kernel ?
Ever heard of gvisor...?
Okay I made this comment based on the title, assuming it meant a sort of "reimplementation" of the linux kernel running in userspace, similar to gvisor (an application kernel).
But that does not in fact seem to be what this is. In fact I can discern no architectural decisions that would differentiate this from Linux in any way. So what is it? We vibecoded an OPEN SOURCE piece of software??? Genuinely so confused by this...
I agree that it is mostly entirely pointless; but I don't think the goal was to make something useful, rather to prove that "HDAE" can in-fact produce a kernel capable of running some unmodified Linux applications
"Made via Human-Directed AI Engineering"
JFC... The world does not have enough psychiatrists to fix the current catastrophe.
> "Made via Human-Directed AI Engineering"
So vibe coded then.
"Human directed A.I. engineering" is a euphemism for slop.
Let me help you here: you want to say “Made via AI slop”.
[flagged]
The true problem is that if a method exists to do something to get attention, it will be used. And when the only means of getting attention is in a social-media algorithm-powered world, the results are typically abysmal...
Poor comment and downvoted. Nothing is stolen, nothing digital ever has been stolen. Maybe it was copied.
[flagged]
Throwaway account...
[flagged]
Teams of offshore coders >>> you