The problem is the increasing review burden - with LLMs it is possible to create superficially valid looking (but potentially incorrect) code without much effort, which will still take a lot of effort to review. So outright rejecting code that can identified as LLM-generated at a glance, is a rough filter to remove the lowest effort PRs.

Over time this might not be enough, though, so I suspect we will see default deny policies popping up soon enough.

>Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense.

Why not?

>Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense.

Humans have been doing this for the better parts of 5 decades now. Don't assume others rely on LLMs as much as you do.

>Not to mention that even finding good developers willing to develop without AI (a significant handicap, even more so for coding things like an OS that are well represented in LLM training) seems difficult nowadays, especially if they aren't paying them.

I highly doubt that. In fact, I'd take a significant pay cut to move to a company that doesn't use LLMs, if I were forced to use them in my current job.

The LLM has brainwashed so many devs that they now think they are nothing without it.

That's an optimistic view. Maybe they really are 10x slower on any task without a LLM.

> Because it takes a massive amount of developer work

You know what else takes "a massive amount of developer work"?

"any LLM-generated code must be reviewed by a good programmer"

And this is the crux of the matter with using LLMs to generate code for everything but really simple greenfield projects: They don't really speed things up, because everything they produce HAS TO be verified by someone, and that someone HAS TO have the necessary skill to write such code themselves.

LLMs save time on the typing part of programming. Incidentially that part is the least time consuming.

The submitter is supposed to be the good programmer; if not, then maintainers may or may not review it themselves depending on the importance of the feature.

And yes of course they need to be able to write the code themselves, but that's the easy part: any good developer could write a full production OS by themselves given access to documentation and literature and an enormous amount of time. The problem is the time.

> The submitter is supposed to be the good programmer;

And how will that be assured? Everyone can open a PR or submit a bug.

> The problem is the time.

But not the time spent TYPING.

The problem is the time spent THINKING. And that's a task that LLMs, which are nothing other than statistical models trying to guess the next token, really aren't good at.

Well, assuming you care about verification, of course. If it's got that green checkmark emoji, it ships!

> Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense.

Every single production OS, including the one you use right now, was made before LLMs even existed.

> What makes sense if that of course any LLM-generated code must be reviewed by a good programmer

The time of good programmers, especially ones working for free in their spare time on OSS projects, is a limited resource.

The ability to generate slop using LLMs, is effectively unlimited.

This discrepancy can only be resolved in one way: https://itsfoss.com/news/curl-ai-slop/

> There are only 4 successful general purpose production OSes

Feel like you are using a very narrow definition of "success" here. Is BSD not successful? It is deployed on 10s of millions of routers/firewalls/etc in addition to being the ancestor of both modern MacOS and PlaystationOS...

What about IBM i and z/OS, and Stratus VOS, and Burroughs MCP, and Tandem GUARDIAN, and VxWorks and OS-9 and… These all not only still exist but run huge transaction volume (for the mainframe and minicomputer systems) and run a huge amount of embedded systems (for the embedded OSes).

> And a new OS needs to be significantly better than those to overcome the switching costs.

Who cares if nobody switches to it as their daily driver? The goal you proposed was "viable", not "widely used". The former is perfectly possible without LLMs (as history has proved), and the latter is unrelated to how you choose to make the OS.

None of this counters the argument I made above :-)

Just because they have been made before LLMs doesn't mean it can be done again, since there was just one success (GNU/Linux) and that success makes it much harder for new OSes since they need to better then it

> Just because they have been made before LLMs doesn't mean it can be done again

Erm...no? That's exactly what that means.

Earth-Ovens haven't been in widespread use for hundreds of years. People can still use them to bake bread however: https://www.youtube.com/watch?v=WAJqGVxuJPo

Well, by this logic there have been 0 successful OSes made with LLMs so far...

> Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense.

Perhaps the same way that every other viable OS was made without use of LLMs.

> Not sure how they can expect to make a viable full OS without massive use of LLMs, so this makes no sense.

Terry Davis built a full OS with his own editor, compiler and language. I think Redox can survive just fine without LLMs

they already have...