Sam Schillace: belief

Transcript context

…I'm guilty of that. I mean, I like to play with stuff. I tend to think with my fingers as much as anything else. So I actually think there's a good place for just play with the tech a lot and figure out what it's good for. What I've evolved to doing these days with my teams is I pick what I call north stars that I think are interesting, useful things to get to rather than just messing around. What's a cool thing that I think might be buildable with this? So right now we're doing these multi-agent systems. We're trying to figure out how much independent work they can do without a person holding their hand. And so a nice domain to test that out in is programming, because you don't have a whole lot of... You just give something a Python environment and a file system and that's it and that's all it needs. And so you're not distracted by connectivity issues or whatever. So one of the problems right now is go write the eye in Python. That's a problem I could give to an intern and it would take them a summer to do some halfway decent job of it. It's a thing you could expect a reasonably competent programmer to do, mostly independently. And so it should be possible for the system, if it's independent at all, to go do that. So is that useful by itself? No, because we already have the eye, it doesn't matter. But if we build a system of programming agents that can self-monitor and self-correct and bug themselves, that can build things that are roughly that scale of complexity, that's valuable. That would be a valuable thing to have. It's kind of interesting too, because that system already, it's produced a bunch of good insights. One of them is its kind of complicated and then hard to debug it. It's this asynchronous system of stochastic agents. That's a lot of stuff to deal with. So we wrote a debugger agent. And debugger agent watches stuff, and when there's a problem somewhere, it goes and figures out what the problem is and then gives you a nice explanation of what you broke and what needs to be fixed. And we haven't turned it loose on actually fixing things yet because we don't trust it, but it's very helpful as an assistant [inaudible 00:47:15]. We had one that documented itself too. That's the other one we did recently. Just turned it loose on documenting the code base and did a pretty good job of it. So it's starting to produce interesting stuff, right? Because we have these north stars that we aim things at. And I think that's maybe a good antidote to this. Just playing with tech without being focused doesn't tend to produce anything that's super valuable. But picking these, even if they're arbitrary goals, as long as they're real goals that you're trying to get to, that's useful, right? Where you're like, "I wonder if I can get this to work. I wonder if I can build this thing." Then grind away at that for a week and see how close I can get. See what I learned about why it's hard. ht? Where you're like, "I wonder if I can get this to work. I wonder if I can build this thing. " Then grind away at that for a week and see how close I can get. See what I learned about why it's hard. That's probably better than just like, "Let me poke at JavaScript for a while." It's also different, I think, at a bigger company where you need to achieve something, versus I think as just an engineer out of college just playing around, like, go for it, right? It's just like, what's the worst that could happen?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.