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.
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.
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.
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. :)
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...
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
> 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.
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.
It makes a nice test case to work on techniques for building reliable software with AI. It's research people can learn from, not a product someone is imposing on you.
> We don't want or need hundreds of LLM generated Unix-clones
Actually, I do want that. Having a monoculture where one vulnerability affects all computers seems problematic to me. Even if each clone is less secure, hacking into one doesn't cause the rest of the world to panic. It changes the economics for a black hat.
> 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.
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.
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.
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.
You cannot relicense a public domain work, but you can release a public domain work under a different license. If you couldn't, you wouldn't be able to make derivative works out of public domain material without the derivative also being public domain.
The new license simply doesn't apply to anything that is in the public domain, only to the new parts and to the combined work.
> 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.
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
Vibe coding was always about what you were doing if you didn't review code or pay any other attention to the output. If you're designing it, planning it, and reviewing it then it's not vibe coding.
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
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.
54 comments
[ 5.5 ms ] story [ 42.6 ms ] threadBecause 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.
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.
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.
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.
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.
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.
> 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.
Not sure if that naming choice would have been a good idea though. :)
So vibe coded then.
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...
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.
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.
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.
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
It makes a nice test case to work on techniques for building reliable software with AI. It's research people can learn from, not a product someone is imposing on you.
> We don't want or need hundreds of LLM generated Unix-clones
Actually, I do want that. Having a monoculture where one vulnerability affects all computers seems problematic to me. Even if each clone is less secure, hacking into one doesn't cause the rest of the world to panic. It changes the economics for a black hat.
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.
Apparently they got fixed by now.
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.
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.
> 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.
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.
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.
The new license simply doesn't apply to anything that is in the public domain, only to the new parts and to the combined work.
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.
Just trying to bring awareness to the absolute crap show that is going to happen when these start getting litigated, RIAA style.
JFC... The world does not have enough psychiatrists to fix the current catastrophe.
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