Y Combinator Startup Podcast
00:31:04 · S1, Peter Steinberger
[00:31:04] S1: Okay. AI tools. What's your decision you made purely for speeds early that you still live with today? [00:31:12] S0: I think that was really early in in deciding that I don't read all the code. I see code review more as risk management. You know, sometimes you touch a system that is scary. You kinda wanna like read a little bit closer, and other times you build UI. Do I really care the UI is built if it looks correct? No. So you kinda, you glance over or you simply accept that it looks right. Part of it is just like you develop a little bit of a feeling how long something should take. So if I do a small tweak that should like change how dragging works, and it takes three hours, I know something's wrong. I'll look closely. But otherwise, part of code review is simply like observing, looking how big a change is and trusting your gut. [00:32:09] S1: Okay. AI tools make it easy to build a product in a weekend now, but building isn't the hard part, getting people to use this. How would you go from a working prototype to your first 10 real users today? [00:32:25] S0: Well, I think that was part of what I addressed in my talk. User number one should be you, and my users two to 20 were friends. So I'm sure you have some people that would actually test your stuff, but you need to be the first user. If you don't you don't get excited about what you're building, it'll probably not make sense.
00:32:25 · Peter Steinberger, S1
[00:32:25] S0: Well, I think that was part of what I addressed in my talk. User number one should be you, and my users two to 20 were friends. So I'm sure you have some people that would actually test your stuff, but you need to be the first user. If you don't you don't get excited about what you're building, it'll probably not make sense. [00:32:51] S1: Like, in this day and age, eyeballs are kind of the the most expensive currency, because building something so fast now, how do you balance solving issues that annoy you and make features you think people you want? [00:33:08] S0: That's a hard one because oftentimes it it kinda goes together. I get annoyed if something's not there as I want it. I haven't, to be honest, I haven't fully figured that part out yet. I feel I could just work for months on issues, because there's always gonna be weird edge cases in software, especially if you add more and more features. But then again, if I only do that, I'll lose interest in working. So it needs to be like, it needs to be a healthy mix. [00:33:44] S1: If you could back and change the thing, one thing about OpenClaw, what would you change?
00:33:44 · S1, Peter Steinberger
[00:33:44] S1: If you could back and change the thing, one thing about OpenClaw, what would you change? [00:33:51] S0: I would be less stressed out about security researchers. They are really good at making you feel really bad. They would send a report, they would email me, they would call me, they would do everything they can possibly get to get my attention, but not actually to help a product. In most of the case it's really just for them to get cloud, for them to get a point, oh we found something, and most of them really sent reports that their agent produced without actually even testing it, I take a stronger sense of explaining what are the parts that we guarantee, and what are the parts that will not be fixed because that's not our security boundary. But I honestly, I had no... This was my first time I was exposed to this world, so I just didn't know how to handle that. And I I lost a few months and got a few gray hairs to learn. [00:34:57] S1: What's the single biggest bottleneck in today's Adjantic infrastructure? Reliability, tooling, memory evolves.
00:34:57 · S1, Peter Steinberger
[00:34:57] S1: What's the single biggest bottleneck in today's Adjantic infrastructure? Reliability, tooling, memory evolves. [00:35:06] S0: Managing compute, if that makes sense. Like, if I run one test locally in my machine, TS go will spin up 16 threads and will bottleneck my machine. If 10 sessions do that, two of them will probably time out and will have to do it again, and there's no really good system of like managing all of that. Now if I do web stuff, it's easy to create a cloud session. If I do like something that requires macOS, that's already where like 99% of the tools fail me. If it's something that needs other stuff that's on my computer, same. And we haven't really built something yet where things could easily move from here to here without issues, at least I didn't see good stuff working yet. Or where I could drive a fleet in a reliable way. Like right now, I use too many systems, I screen share into some computers to like distribute a load, I shouldn't be doing that. [00:36:13] S1: How do you keep an open source project opinionated and point it in one direction, whether they're just merging the n plus one PR that adds a random feature? And how do you communicate that direction to the community? Have you ever said no to popular PR because it pulled the project off course?
00:36:13 · S1, Peter Steinberger
[00:36:13] S1: How do you keep an open source project opinionated and point it in one direction, whether they're just merging the n plus one PR that adds a random feature? And how do you communicate that direction to the community? Have you ever said no to popular PR because it pulled the project off course? [00:36:36] S0: Yeah, yeah. I would say I didn't say no enough. This is I... When I do new open source, I write a vision dot md file, where I kinda explain what it is now, where I see this to be, but of course it's incorrect, it's not perfect science. And it's something I need to adhere to better, because it is always tempting to add this one feature that looks really cool, but what you rarely think about is when you merge this feature, it really means here's this pile of code that I don't need, that the person probably doesn't really understand, that I don't fully understand, that I also got responsibility. [00:37:24] S1: When do you expect to have clause that are perpetually running, that are proactive in their work?
00:37:24 · S1, Peter Steinberger
[00:37:24] S1: When do you expect to have clause that are perpetually running, that are proactive in their work? [00:37:32] S0: I mean, that's not so much a tech problem, it's more a token problem where we could do that today, but you wouldn't get very far with your subscription, and not everyone is willing to spend so many tokens. It's also... But a part that's not easy is designing a system that doesn't just burn empty tokens. Even the... My early system of, like, heartbeats was too static and not not proactive enough. And then especially bad if you have a large session, and then one hour later you call like a heartbeat checkup and everything, and that means you send 600,000 tokens back to the server after the Kiwi cache cleared, and you pay a stupidly amount of money for a lot of not useful work. So there's a lot of things that can be done to optimize that. It's also really, really hard. [00:38:33] S1: Can you tell us more about your own personal setup? What do you host your claws on? What model are you running? What harness do you use? Do you still read... Can we scroll? Do you still read your code?