Adam Leventhal

So it's like, you really cannot rely on something that you've really trained on.

You're going to have to kind of look at this

But it was good.

And I would say like net net, it probably saved me probably about, in terms of like the actual time to implement this, it probably saved me like half the time.

I spent about two hours on it to have something that was, I was pretty confident would work and did work versus I think it'd probably be about,

four hours on it.

And someone's in chat saying, well, how many LLMs train on a Lumos?

It's like, yes, but what it was, the way it was iterating, and if folks haven't used cloud code, it is really, it's worth experimenting with, especially on an established source base.

And so one of the things that I would just like to throw out there as like a first way that these things can help increase your rigor is by asking questions about a source base.

And clearly, like, you know, all of the caveats apply that you can get the wrong answers and so on.

You need to verify these things.

But it was really, it made it much more, it figured out a lot of what needed to be done surprisingly quickly.

So I will absolutely be using it again for other kernel projects, if only to, as a starting point,

And one thing it did, it was funny, is, Adam, it needed to add a field to a structure.

And this is, the actual structure itself, none of the fields is commented.

You know how we, like, best practice would be to comment every structure member?

And in this particular source file, none of the structure members are commented.

And what its proposal was, was to actually comment the structure member, like for bad reasons, like we're not going to do that.

We're going to be consistent with what's there by not commenting the new member that you just added.

Like the code you want to actually write is actually cleaner than what's there.