David Crespo

Just to defend the JavaScript world a little bit, I think the spectrum of rigor that you might need,

It applies in a lot of different situations.

You might make a one-off Rust CLI as a debugging tool in that same situation.

You can tell if it works by running it.

The depth of static analysis, you don't really need that because you run the thing and it does what you want and you can tell that it worked.

So there's a lot of situations I think that's an underrated point that people assume it's all or nothing, that the code needs to be perfect or it doesn't work at all, which is ridiculous.

our most rigorously engineered code is still going to have some bugs in it.

So obviously there's sort of a spectrum of, of amount of bugs that we can tolerate or amount, you know, of leeway that we have.

Something people have mentioned in the chat, and we haven't talked about too much, is that something that really helps the LLMs in these kinds of loops is they have a signal, like a verification signal, that can tell them when they're done and how far away they are from it.

And types passing, obviously, test passing is one of those things.

But I'm curious how you think of what the verification signal is to the LLM as it's doing this.

Does it satisfy these natural language requirements?

I think we covered everything there is to say about LLM.

Yeah, so I think that's kind of right. And I think we had also reached kind of a software complexity. So when we were talking about this, my recollection is we were kind of going back on what was good about PSARC, what was bad about PSARC. And in particular, it was kind of like the 20 questions part of it.

Not necessarily did you write every manual page down into a case that was there, but more of the what are we trying to do and why. we had kind of gotten to the point where both Triton and Manta had reached a level of complexity as well, where it's just like, how did these things intersect? What actually happens when you're building this?

And to your point, the act of writing it down just forced you to think about it a little bit ahead of time. But yeah, I think that that's kind of where we were. And then I think we kind of used Alex as the first willing

Yeah, I think it was both. I think we kind of both were looking for it and then looking for a way to kind of lead with a couple examples of what we were looking for because it was kind of a hard thing to – if you just like what is the actual shape of this kind of amorphous document? And so you want to have, you know, something that kind of describes like, what's the problem?

You know, what are we actually proposing? How does this intersect? You know, especially for kind of like a bunch of stuff for us was, you know, then, you know, what is actually going to be user visible? Like how does some of these APIs, what are some of these APIs, what are these sketches of them? So we understand how they fit together.

Yeah, that's my recollection, especially, like, in the era of, like – chat bots that will link to things. I think the bot already did RFCX to the actual IETF RFC, so that was going to be doubly confusing. I think it was that, and then also that way we could just distinguish it from the IETF. Yeah, that's mostly why we chose a different name. I don't think there's too much

Yeah, I think the sentence you have, the parenthetical you have at the end of that joint RFD intro is probably about as accurate as it is.