And they never will, with that attitude.

I'm sorry, this is simply not true.

this https://codeberg.org/lrvick/nit/src/branch/main/src/system/r...

is textbook definition of boilerplate. you need to be patient to cross-reference syscall tables but certainly not smart.

Again, students learning about operating systems do similar things as a normal part of their education process.

I'm not saying LLMs wouldn't help with this (in fact, this is the type of thing that becomes pretty much a no-op with them) but the notion that this is "impossible by any realistic standards" is risible, and if you have actually contributed to the kernel like you say, you should know better.

> I am mostly pushing back on the notion of dismissing software as low quality just because the author used LLMs.

Its not that hard to imagine that apps made with heavily LLM involvement suffer in quality. The article already goes into it a bit. I get the strong feeling that you are failing to approach this from anything else than your own perspective and how you use LLMs. Which, given the setup you are describing is already far from the norm.

Zooming out a bit further I think we can generally break up LLM usage in roughly two distinct ways of using LLMs. Or maybe more accurately there are two sides of a spectrum with a lot of area in between them:

1. Let LLMs do the majority of the heavy lifting and generate the output. Providing an LLM with some basic info, what you are looking for and let the LLM do most of the work for you. 2. Using LLMs as a tool external to the process where you are still doing most of the work.

The first way of using LLMs using agentic workflows, code harnesses, etc *can* produce good quality. As long as there is still a human in the mix who a) has the prerequisite knowledge to validate what the LLMs have generated b) takes their due diligence at key points in the process to actually make sure input is of high enough quality and validates the output.

You have decades of knowledge and experience you are now applying to rigidly structure how these LLMs work. Which, yes again, I believe gives you personally pretty good results, no doubt about that. But, many people do not have that experience to begin with. And even for those that do, using the first method comes with a risk that boils down to simple psychology, our minds are wired to take the easy approach wherever they can. Which turns the first way of using LLMS from a efficient way of using them to a lazy way of using them.

In my personal experience a lot of people who start using LLMs sort of drift to the lazy approach very easily. Because it is very convenient and easy to slowly hand over more thinking to an LLM. The latter I have seen happen all too often around me. An alarming increase of lazy non critical use of LLM tools by people who should know better. People who might have been a bit slower before but delivered excellent results now have started delivering trash. Code spanning dozens of line trying to solve something that should only take one line. Code that completely ignores and conventions or design paradigms put in place. Code that goes directly against security practices. Suddenly downgraded dependency versions (because the models training data doesn't include the latest version).

As I said, I see this as a spectrum and the more someone leans towards the first use case combined with "lazy usage" the more signs there will be in a repository that this is the case. The amount of commits, the release cadence and various other things. Which, again, the article also makes a case for and is again why your repository is irrelevant to the whole discussion. Why? Because your repository doesn't show these signs.

Nearly any C programmer could write this.

So it violates codeberg's policy.

It got flagged because it is wildly wrong.

LLMs are literally solving math problems humans have struggled with for decades.

It took me a while to get through the cognitive dissonance too, but we are all going to have to do it.

I can have confidence because I specced the test suite to prove the rust assembly calls matches up with the tables in the linux source code.

If any of that is wrong, then the Linux kernel is wrong the same way.

I am not even close to vibe coding. This is built to my exact spec because I actually understand this area pretty well.

I constructed a Linux distribution on my own before AI and contributed to the kernel by hand going back 20 years ago now.

humans are overly confident too when they are mostly wrong