Michael Truel
speaker
75 appearances
1 recordings
1 series
first heard Sep 2024
last heard Sep 2024
Michael Truel’s voice in public audio — every appearance, attributed to the second.
Trend
recordings per month · last 12 monthsNo recordings in the last 12 months.Older appearances are listed below; set an alert to hear about the next one.
Appearances
I think that this benchmark question is both complicated by what Svali just mentioned, and then also to... What Aman was getting into is that even if you like, you know, there's this problem of like the skew between what can you actually model in a benchmark versus real programming. And that can be sometimes hard to encapsulate because it's like real programming is like very messy.
And sometimes things aren't super well specified what's correct or what isn't. But then it's also doubly hard because of this public benchmark problem. And that's both because public benchmarks are sometimes kind of hill-climbed on, but then it's really, really hard to also get the data from the public benchmarks out of the models.
And so, for instance, one of the most popular agent benchmarks, SweetBench, is really, really contaminated in the training data of these foundation models. And so if you ask these foundation models to do a sweet bench problem, but you actually don't give them the context of a code base, they can like hallucinate the right file pass, they can hallucinate the right function names.
And so it's also just the public aspect of these things is tricky.
I think that given the dearths and benchmarks, there have been a few interesting crutches that places that build systems with these models or build these models actually use to get a sense of are they going in the right direction or not. And in a lot of places, people will actually just have humans play with the things and give qualitative feedback on these things.
like one or two of the foundation model companies, they have people who, that's a big part of their role. And, you know, internally we also, you know, qualitatively assess these models and actually lean on that a lot in addition to like private evals that we have. It's like the vibe. The vibe, yeah. It's like the vibe.
Don't you think this gets at a little bit some of the stuff you were talking about earlier with the difficulty of specifying intent for what you want with software? Where sometimes it might be because the intent is really hard to specify, it's also then going to be really hard to prove that it's actually matching whatever your intent is.
Yeah, or just for a given spec, maybe you can... I think there is a question of can you actually do the formal verification? Is that possible? I think that there's more to dig into there.
Even if you have the spec. Is the spec written in natural language? Yeah, how do you map the spec?
But how easy would that be to draw? So then I think that you care about things that are not going to be easily well-specified in the spec language.
Yeah. Maybe an argument against formal verification is all you need.
Yeah. And I think that it's also important to note that this is having good bug finding models feels necessary to get to the highest reaches of having AI do more and more programming for you, where you're going to, you know, if the AI is building more and more of the system for you, you need to not just generate, but also verify.
And without that, some of the problems that we've talked about before with programming with these models will just become untenable. So it's not just for humans, like you write a bug, I write a bug, find the bug for me, but it's also being able to verify the AI's code and check it is really important.
You can also do a bunch of work, not even at the model level, of taking the biggest models and then maybe giving them access to a lot of information that's not just the code. it's kind of a hard problem to stare at a file and be like, where's the bug? And that's hard for humans often, right? And so often you have to run the code and being able to see things like traces and step through a debugger.
There's a whole other direction where it kind of tends toward that. And it could also be that there are kind of two different product form factors here. It could be that you have a really specialty model that's quite fast that's kind of running in the background and trying to spot bugs.
And it might be that sometimes, sort of to Arvid's earlier example about some nefarious input box bug, it might be that sometimes you want to like You know there's a bug. You're not just checking hypothesis-free. You're like, this is a problem. I really want to solve it.
And you zap that with tons and tons and tons of compute, and you're willing to put in $50 to solve that bug or something even more.
There is also a potential world where there's a technical solution to this like honor system problem too, where if we can get to a place where we understand the output of the system more, I mean, to the stuff we were talking about with like, you know, error checking with the LSP and then also running the code.
But if you could get to a place where you could actually somehow verify, oh, I have fixed the bug, maybe then the bounty system doesn't need to rely on the honor system too.
Yeah, I think that it has been an interesting journey adding each extra zero to the request per second. You run into all of these with the general components you're using for caching and databases run into issues as you make things bigger and bigger. And now we're at the scale where we get int overflows on our tables and things like that.
Showing 21–40 of 75 · page 2 of 4
← Previous
Next →