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.
> 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.
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.
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
Apparently they got fixed by now.
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.
> And as a test case they built a Linux-compatibe thing in Rust!
This naive 5-year-old style writing doesn't work any more. The Pelican guy is also no longer taken seriously.
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.
We don't want or need hundreds of LLM generated Unix-clones which are merely slight variations on the Linux source code.
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.
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.
Not sure if that naming choice would have been a good idea though. :)
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.
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.
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.
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 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...
So vibe coded then.