Inside Claude Code With Its Creator Boris Cherny

21:56It's pretty easy. What's the vision for quad teams? It's collaboration. It's like, there's this whole new field of like agent topologies that people are exploring. Like what are the ways they can configure agents? There's this one sub idea, which is uncorrelated context windows. And the idea is just multiple agents. They have fresh context windows that aren't essentially polluted with each other's context or their own previous context. And if you throw more context at a problem, that's like a form of test time compute. And so you just get more capability that way. And then if you have the right topology on top of it, so the agents can communicate in the right way, they're laid out in the right way, then they can just build bigger stuff.

22:30And so Teams is kind of like one idea. There's a few more that are coming pretty soon. And the idea is just maybe it can build a little bit more. I think the first kind of big example where it worked is our plugins feature was entirely built by a swarm over a weekend. It just ran for like a few days. There wasn't really human intervention. And plugins is pretty much in the form that it was when it came out. How did you set that up? Like did you spec out sort of the outcome that you were hoping for and then let it sort of figure out the details and then like let it run? Yeah, an engineer on the team just gave Quad a spec and told Quad to use a Asana board.

23:09And then Quad just put up a bunch of tickets on Asana and then spawned a bunch of agents and the agents started picking up tasks. And then Quad just gave it instructions and they all just figured it out. Like independent agents that didn't have the context of the bigger spec, right? Right. If you think about the way that, you know, like how our agents actually started nowadays. And, you know, I haven't pulled the data on this, but I would bet the majority of agents are actually prompted by quad today in the form of subagents. Because like a subagent is just like a recursive quad code. That's all it is in the code.

23:39And it's just prompted by, we call her mama quad. And that's all it is. And I think probably if you look at most agents, they're launched in this way. My Claude insights just told me to do this more for debugging. so that I get, like, I spend a lot of time on debugging and it would just be better to have, like, multiple subagents spin up and, like, debug something in parallel. And so then I just, like, added that to my ClaudeMD to just be like, hey, like, next time you're trying to fix a bug, like, have one agent that, like, looks in the log, like, one that looks in the code path. That just seems sort of inevitable.

24:08For weird, scary bugs, I try to fix bugs in plan mode and then it seems to use the agents to sort of search everything. Whereas, like, when you're just trying to do it in line, It's like, okay, I'm going to do like this one task instead of search wide. This is something I do all the time too. I just say, if the task seems kind of hard, this kind of research task, I'll calibrate the number of sub-agents I ask it to use based on the difficulty of the task. So if it's like really hard, I'll say like use three or maybe five or even 10 sub-agents, research in parallel, and then see what they come up with.

24:39I'm curious. So then why don't you put that in your clawed MD file? It's kind of case by case, you know, like clawed MD, like what is it? It's just a, it's a shortcut. But if you find yourself repeating the same thing over and over, you put in the Quad MD. But otherwise, you don't have to put everything there. You can just prompt Quad. Are you also in the back of your mind thinking that maybe in six months, you won't need to prompt that explicitly? The model would just be good enough to figure it out on its own. Maybe in a month. No more need for Plan Mode in a month? Oh my god. I think Plan Mode probably has a limited lifespan.

25:10Interesting. That's some alpha for everyone here. What would the world look like without Plan Mode? you just describe it at the prompt level and it would just do it, one shot it? Yeah, we've started experimenting with this because quad code can now enter plan mode by itself. I don't know if you guys have seen that. So we're trying to kind of get this experience really good. So it would enter plan mode the same point where a human would have wanted to enter it. So I think it's something like this. But actually plan mode, there's no big secret to it. All it does is it adds one sentence to the prompt that's like, please don't code.

25:43That's all it is. So you can actually just say that. So it sounds like a lot of the feature development for Cloud Code is very much what we talk about at YC. Talk to your users, and then you come and implement it. It wasn't the other way that you had this master plan and then implemented all the features. Yeah, yeah. I mean, that's all it was. Like, plan mode was we saw users that were like, hey, Cloud, come up with an idea. Plan this out, but don't write any code yet. And there was kind of various versions of this. Sometimes it was just talking through an idea. Sometimes it was these very sophisticated specs that they were asking Cloud to write.

26:12but the common dimension was do a thing without coding yet and so literally like this was like sunday night at 10 p.m i was i was just like looking at github issues and kind of seeing what people were talking about and looking at our internal slack feedback channel and i just wrote this thing in like 30 minutes and then uh shipped it that night it went out monday morning that was plan mode so do you mean that there'll be no need for plan mode so in the sense of i'm worried that the model is going to do like it's going to do like the wrong thing or head off in the wrong direction, but there will still be a need for that.

26:42You need to think through the idea and figure out exactly what it is that you want. And you have to do that somewhere. I kind of think about it in terms of like kind of increasing model capabilities. So maybe six months ago, a plan was insufficient. So you get Claude to make a plan, let's say even with plan mode, you still have to kind of sit there and babysit because it can go off track. Nowadays, what I do is probably 80 % of my sessions, I say plan mode has a limited lifespan, but I'm a heavy plan mode user. Probably 80 % of my sessions, I start in plan mode. And Claude will, you know, it'll start, it'll start making a plan, I'll move on to my second terminal tab, and then I'll have it make another plan.

27:17And then when I run out of tabs, I open the desktop app, and then I go to the code tab, and then I just start a bunch of tabs there. And they all start in plan mode, probably, you know, like 80 % of the time. Once the plan is good, and sometimes it takes a little back and forth, I just get Claude to execute. And nowadays, what I find with Opus 4.5, I think it started with 4.6. It got really good. Once the plan is good, it just stays on track and it'll just do the thing exactly right almost every time. And so, you know, before you had to babysit after the plan and before the plan. Now it's just before the plan.

27:46So maybe the next thing is you just won't have to babysit. You can just kind of give a prompt and Quad will figure it out. The next step is Cloud just speaks to your users directly. Yeah, it just bypasses you entirely. It's funny. This is actually the current stuff for us. Our quads actually like they talk to each other. They talk to our users on Slack, at least internally pretty often. My quad will like tweet once in a while. No way. But I actually like delete it. It's just like, it's a little like cheesy. Yeah. Like I don't love the tone. What does it want to tweet about? Sometimes it'll just like respond to someone because I always have like cowork running in the background.

28:19And it's like, it's the cowork quad that really loves to do that because it likes using a browser. That's funny. A really common pattern is I ask quad to build something. It'll look in the code base. It'll see some engineer touch something in the git flame. and then it'll message that engineer on Slack, just like asking a clarifying question. And then once it gets the answer back, it'll keep going. What are some tips for founders now on how to build for the future? It sounds like everything is really changing. What are like some principles that will stay on and what will change? So I think some of these are pretty basic, but I think they're even more important now than they were before.

28:53So one example is latent demand. Like I mentioned it a thousand times for me, it's just like the single biggest idea in product. It's a thing that no one understands. It's a thing I certainly did not understand my first few startups. And the idea is like people will only do a thing that they already do. You can't get people to do a new thing. If people are trying to do a thing and you make it easier, that's a good idea. But if people are doing a thing and you try to make them do a different thing, they're not going to do that. And so you just have to make the thing that they're trying to do easier.

29:20And I think Quad is going to get increasingly good at kind of figuring out these kind of product ideas for you just because it can look at feedback. It can look at debug logs. It can kind of figure this out. That's what I mean by plan mode was latent demand that people already had their clawed chat window open in the browser and were talking to it to figure out the spec and what it should do. And now plan mode just became that. You just do it in clawed code. Yeah, yeah. Sometimes what I'll do is I'll just walk around the office on our floor and I'll just kind of stand behind people. I'll say like, hi, so it's not good.

29:53And then I'll just see kind of like how they're using clawed code. And this is also just something I saw a lot. But it also came up in GitHub issues, like people were talking about it. It seems like you're surprised how far the terminal has gone and how far it's been pushed. Like, how far do you think it has left to go? Just given with this world of SWAR, multiple agents, do you think there's going to be a need for a different UI on top of it? It's funny. If you asked me this a year ago, I would have said the terminal has like a three-month lifespan, and then we're going to move on to the next thing.

30:23And you can see us experimenting with this, right? Because Quad Code started in a terminal, but now it's on web, like Quad.ai.s hash code. It's in the desktop app. We've had that for three months or six months or something, just in the code tab. It's in the iOS and Android apps, just like in the code tab. It's in Slack. It's in GitHub. There's VS Code extensions. There's JetBrains extensions. So we're just like, we're always experimenting with different form factors for this thing to figure out what's the next thing. I've been wrong so far about the lifespan of the CLI. So I'm probably not the person to forecast.

30:56What about like your advice to DevTool founders? Like someone's building a DevTool company today. Should they just like be building for engineers and humans? Or should they be thinking more about like what Claude is going to think and want and build for sort of like the agent? The way I would frame it is think about the thing that the model wants to do and figure out how do you make that easier? And that's something that we saw, you know, like when I first started hacking on quad code, I realized this thing just wants to use tools. It just wants to interact with the world. And how do you enable that?

31:29Well, the way you don't do it is you put it in a box. And you're like, here's the API. Here's how you interact with me. And here's how you interact with the world. The way you do it is you see what tools it wants to use. You see what it's trying to do. And you enable that the same way that you do for your users. And so if you're building a DevTools startup, I would think about what is the problem you want to solve for the user? And then when you apply the model to solving this problem, what is the thing the model wants to do? And then what is the technical and product solution that serves the weight and demand of both?

31:56YC's next batch is now taking applications. Got a startup in you? Apply at ycombinator.com slash apply. It's never too early and filling out the app will level up your idea. Okay, back to the video. Back in the day, more than 10 years ago, you were a very heavy user and you wrote a book about TypeScript, right? Before TypeScript was cool. This is when everyone was deep in JavaScript. This is back in early 2010s, right? Yeah, something like that. Before TypeScript was a thing because back then is a very weird language. It's not supposed to do a lot of things with being typed in JavaScript. And now it's the right thing.

32:38And it feels like cloud code in the terminal has a lot of parallels with TypeScript at the beginning. TypeScript makes a lot of really weird language decisions. So if you look at the type system, pretty much anything can be a literal type, for example. And this is like, this is super weird because like, even like Haskell doesn't even do this. It's just like, it's too extreme or it has like conditional types, which I don't think any language thought of at all. It was like very strongly typed. Yeah, it was very strongly. And the idea was like when, you know, like when Joe Pamer and Anders and the early team was like building this thing, the way they built it is we, okay, we have these teams teams with these big, untyped JavaScript code bases.

33:18We have to get types in there. But we're not going to get engineers to change the way that they code. You're not going to get JavaScript people to have 15 layers of class inheritance like you would a Java programmer. They're going to write code the way they're going to write it. They're going to use reflection. And they're going to use mutation. And they're going to use all these features that traditionally are very, very difficult to type. They're a very unsafe type to any strong functional programmer, really. That's right. That's right. That's right. And so the thing that they did, instead of getting people to kind of change the way that they code, they built a type system around this.

33:47And it was just, it's brilliant because there's all these ideas that no one was thinking about. Even in academia, like no one thought of a bunch of these ideas. It purely came out of the practice of observing people and seeing how JavaScript programmers want to write code. And so, you know, for quad code, there are some ideas that are kind of similar in that, you know, like you can use it like a Unix utility. You can pipe into it, you can pipe out of it. In some ways it is kind of rigorous in this way, but in almost every other way, It's just the tool that we wanted. Like I built a tool for myself and then the team built the tool for themselves and then for anthropic employees and then for users.

34:22And it just ends up being really useful. It's not this like principled and academic thing. Which I think the proof is actually in the results. Now fast forward more than 15 years later, not many code bases are in Haskell, which is more academic. And there's tons of them now in TypeScript because it's way more practical. Right. Which is interesting. Yeah, it is interesting, right? It's like TypeScript solves a problem. I guess one thing that's cool, I don't know how many people know, but the Terminal is actually one of the most beautiful Terminal apps out there and is actually written with React Terminal.

34:57When I first started building it, you know, like I did front-end engineering for a while. So and I was also like, you know, I'm sort of like a hybrid. Like I do like design and user research and, you know, write code and all the stuff. And we love hiring engineers that are like this. So we just we love generalists. So for me, it's like, okay, I'm building a thing for the terminal. I'm actually kind of a shitty Vim user. So like, how do I build a thing for people like me that, you know, are going to be working in a terminal? And I think just the delight is so important. And I feel like at YC, this is something you talk about a lot, right?

35:27It's like, build a thing that people love. If the product is useful, but you don't fall in love with it, that's not great. So it kind of has to do both. Designing for the terminal, honestly, has been hard, right? It's like 80 by 100 characters or whatever. You have like 256 colors. You have one font size. is you don't have like mouse interactions. There's all this stuff you can't do. And there's all these very hard trade-offs. So like a little known thing, for example, is you can actually enable mouse interactions in a terminal. So you can enable like clicking and stuff. Oh, how do you do that in Cloud Code?

35:54I've been trying to figure out how to do this. We don't have it in Cloud Code because we actually prototyped it a few times and it felt really bad because the trade-off is you have to virtualize scrolling. And so there's all these weird trade-offs because like the way terminals work is like there's no DOM, right? It's like there's like anti-escape codes and these kind of weird organically evolved specs since like the 1960s or whatever. Oh, yeah. It feels like BBSs. It's like a BBS door game. Yeah, yeah, yeah. Oh, my God. That's like a great compliment. Yeah, yeah, yeah. It should feel like we're discovering something.

36:22Lord of the Red Dragons. Fantastic. Oh, my God. Yeah, but we've had to just like discover all these kind of UX principles for building the terminal because no one really writes about this stuff. And if you look at the big terminal apps of, you know, like the 80s or 90s or 2000s or whatever, they use like EdCurses and they have all these like windows and things like this. And it just looks kind of like janky by modern standards. It just looks too heavy and complicated. And so we had to like reinvent a lot. And, you know, for example, something like the terminal spinner, like just like the spinner words, it's gone through probably, I want to say like 50, maybe a hundred iterations at this point.

36:55And probably 80 % of those didn't ship. So we tried it. It didn't feel good. Move on to the next one. Try it. Didn't feel good. Move on to the next one. And this was like sort of one of the amazing things about quad code, right? It's like you can write these prototypes and you can just do like 20 prototypes back to back, see which one you like, and then ship that. And the whole thing takes maybe a couple hours. Whereas in the past, what you would have had to do is like weren't to use origami or framer or something like this. You built like maybe three prototypes. It took like two weeks. It just took much, much longer.

37:21And so we have this luxury of we have to discover this new thing. We have to build the thing. We don't know what the right endpoint is, but we can iterate there so quickly. And that's what makes it really easy. And that's what lets us build a product that's like joyous and that people like to use. Boris, you had other advice for builders and we kept interrupting you because we have so many questions. I would say, so, okay, so maybe two pieces of advice that are kind of weird because it's like about building for the model. So one is don't build for the model of today, build for the model of six months from now.

37:54This is like sort of weird, right? Because like you can't find PMF if the product doesn't work, but actually this is the thing that you should do because otherwise what will happen is you spend a bunch of work, you find PMF for the product right now and then you're just going to get leapfrogged by someone else because they're building for the next model and a new model comes out every few months. Use the model, feel out the boundary of what it can do, and then build for the model that you think will be the model maybe six months from now. I think the second thing is, you know, actually in the quad code area where we sit, we have a framed copy of The Bitter Lesson on the wall.

38:23And this is this like Rich Sutton plot code that everyone should read it if you haven't. And the idea is the more general model will always beat the more specific model. And there's a lot of corollaries to this, but essentially what it boils down to is never bet against the model. And so this is just like a thing that we always think about, where we could build a feature into quad code, we could make it better as a product, and we call this scaffolding. That's all this code that's not the model itself. But we could also just wait like a couple months and the model can probably just do the thing instead.

38:56And there's always this trade-off, right? It's like engineering work now, and you can kind of extend the capability a little bit, maybe 10, 20 % or whatever in whatever domain on this spider chart of what you're trying to extend. Or you can just wait and the next model will do it. So just always think in terms of this trade-off. Where do you actually want to invest? And assume that whatever the scaffolding is, it's just tech debt. How often do you rewrite the codeways of CloudCode? Is it every six months with this first visible? Is there scaffolding that you've deleted because you don't need it anymore because the model just improved?

39:26Oh, so much. Yeah. All of CloudCode has just been written and rewritten and rewritten and rewritten over and over and over. We unship tools every couple of weeks. We add new tools every couple of weeks. There's no part of quad code that was around six months ago. It's just constantly rewritten. Would you say most of the code base for our current quad code is only, say, 80 % of it is only less than a couple of months old? Yeah, definitely. It might even be less than, yeah, maybe a couple of months. That feels about right. So it's like the lifecycle of code now. That's another alpha is expecting it to be the shelf life to be just a couple of months for the best founders.

39:59Do you see Steve Yeggie's post about how awesome working at Anthropic is? And I think there's a line in there that says that an Anthropic engineer currently averages 1000x more productivity than a Google engineer at Google's peak, which is really an insane number, honestly, like 1000x. Like, you know, three years ago, we were still talking about 10X engineers. Now we're talking about 1000X on top of a Google engineer in the prime. Like, this is unbelievable, honestly. Yeah, I mean, internally, if you look at like technical employees, they all use quad code every day. And even non-technical employees, I think like half the sales team uses quad code.

40:40They've started switching to coworker because it's a little easier to use. It has like a VM, so it's a little bit safer. But yeah, we actually, we just pulled the stat and I think the team doubled in size last year, but productivity per engineer grew something like 70%. As measured by? Just like the simplest, stupidest measure, pull requests. But we also kind of cross-checked that against commits and the lifetime of commits and things like this. And since QuadCode came out, productivity per engineer at Anthropic has grown 150%. Oh my God. And this is crazy because in my old life, I was responsible for code quality at Meta.

41:13And I was responsible for the quality of all of our code bases across every product, across Facebook, Instagram, WhatsApp, whatever. And one of the things that the team worked on was improving productivity. And back then, seeing a gain of something like 2 % in productivity, that was like a year of work by hundreds of people. And so this like 100%, this is just like unheard of, just completely unheard of. What drew you to come over to Anthropic? I mean, basically, as a builder, you could go anywhere. What was the moment that made you say, like, actually, this is the set of people or this is the approach?

41:44I was living in rural Japan and I was opening up Hacker News every morning and I was reading the news. And it was all it just started to be like AI stuff at some point. And I started to use some of these early products. And I remember like the first couple of times that I used it, I was just like it just took my breath away. That was like very cheesy to say, but that was actually that was actually the feeling. Like it was just like it was amazing. Like as a as a builder, I've just never kind of felt felt this feeling like using these very, very early products. That was like in the quad two days or something like that.

42:17And so I just started talking to friends at labs just to kind of see what was going on. And I met Ben Mann, who's one of the founders at Anthropic. And he just immediately won me over. And as soon as I met kind of the rest of the team at Ant, it just won me over. And I think probably in two ways. One is it operates as a research lab. So the product org was teeny, teeny, tiny. It's really all about building a safe model. That's all that matters. And so this idea of just being very close to the model and being very close to development and being not the most important thing because the product isn't anymore.

42:53It's just the model is the thing that's the most important. That really resonated with me after building product for many years. And then the second thing was just how mission driven it is. Like I'm a huge sci-fi reader. My bookshelf is just like filled with sci-fi. And so like I just know how bad this can go. And when I kind of think about what's going to happen this year, you know, it's going to be totally insane. And in the worst case, it can go very, very bad. And so I just wanted to be at a place that really understood that and kind of really internalized that. And at Ant, you know, like if you overhear conversations in the lunchroom or in the hallway, people are talking about AI safety.

43:28This is really the thing that everyone cares about more than anything. And so I just wanted to be in a place like that. I know for me personally, the mission is just so important. What is going to happen this year? Okay, so if you think back like six months ago and kind of what are the predictions that people are making? So Dario predicted that 90 % of the code at Anthropic would be written by quad. This is true. For me personally, it's been 100 % for like since Opus 4.5. I uninstalled my IDE. I don't edit a single line of code by hand. It's just 100 % quad code in Opus. And, you know, I land, you know, like 20 PRs a day every day.

44:06If you look at Anthropic overall, it ranges between like 70 to 90%, you know, depending on the team. For a lot of teams, it's also like 100%. For a lot of people, it's 100%. And I remember making this prediction back in May when we GA'd quad code that you wouldn't need an ID to code anymore. And it was totally crazy to say. I feel like people in the audience gasped because it was such like a silly prediction at the time. But really all it is is like you just like trace the, you know, the exponential. and this is just like so deep in you know the dna at ant because like you know three of our founders were co-authors of the scaling laws paper they kind of they saw this very early and so this is just like tracing the exponential this is what's going to happen and yes that happened so continuing to trace the exponential i think what will happen is coding will be generally solved for everyone and i think today coding is practically solved you know for me and i think it'll be the case for everyone um you know regardless of domain i think we're gonna start to see the title software engineer go away.

45:01And I think it's just going to be maybe builder, maybe product manager. Maybe we'll keep the title as kind of a vestigial thing. But the work that people do, it's not just going to be coding. It's software engineers are also going to be writing specs. They're going to be talking to users. Like this thing that we're starting to see right now in our team, where engineers are very much generalists and every single function on our team codes, like our PM's code, our designer's code, our EM codes, our finance guy codes, like everyone on our team codes. We're going to start to see this everywhere. So this is sort of, this is kind of like the lower bound if we just continue the trend.

45:36The upper bound, I think, is a lot scarier. And this is something like, you know, we hit ASL4. And, you know, at Anthropic, we talked about these safety levels. ASL3 is where the models are right now. ASL4 is the model is recursively self-improving. And so if this happens, essentially we have to meet a bunch of criteria before we can release a model. And so the extreme is that, you know, this happens or there's some kind of catastrophic misuse. Like people are using the model to design bioviruses, design zero days, stuff like this. And this is something that we're really, really actively working on.

46:07So that doesn't happen. I think it's just been, honestly, it's just been like so exciting and humbling, like seeing how people are using quad code. Like, you know, I just wanted to build a cool thing and it ended up being really useful. And that was so surprising and so exciting. My impression from Twitter or just the outside is basically everyone went away over the holidays and then like found out about Claude Code and it's just been crazy ever since. But is that how it was for you at like internment? Did you, were you having like a nice Christmas break and then came back and like what happened?

46:37Well, actually for all of December, I was traveling around and I took a coding vacation. So we were kind of traveling around and I was just like coding every day. So that was really nice. And then I also started to use Twitter at the time because like I worked on threads back then, way back when. So I've been a threads user for a while. So I just like tried to see kind of like other platforms where people are. Yeah, I think for a lot of people, that was the moment where they discovered Opus 4.5. I kind of already knew. And internally, quad code's just been on this exponential tear for many, many months now.

47:05So that just became even more steep. That's what we saw. And if you look at QuadCode now, there was some stat from Mercury that 70 % of startups are choosing Quad as their model of choice. There was some other stat from Semi-Analysis that 4 % of all public commits are made by QuadCode, of all code written everywhere. All the companies use QuadCode from the biggest companies to smaller startups. It plotted the course for Perseverance, like the Mars rover. This is the coolest thing for me. And we like we even printed posters because the team was like, wow, this is just like so cool. The NASA chooses to use this thing.

47:43So, yeah, it's just like it's humbling. But it also feels like the very beginning. What's the sort of interaction between Cloud Code and then Co-Work? Like, you know, was it a fork of Cloud Code? Was it like you had Cloud Code look at the Cloud Code code and say, let's make a new spec for non-technical people that, you know, keeps all the lessons. And then, you know, it sort of went off for a couple of days and did that. What's the genesis of that? And where do you think that goes? This is going to be my fifth time using the word wait and demand. It was just that. I mean, we were looking at Twitter and there was that one guy that was using quad code to monitor his tomato plants.

48:21There was this other person that was using it to recover wedding photos off of a corrupted hard drive. There were people that were using it for finance. When we looked internally at Anthropic, every designer is using it. The entire finance team at this point is using it. the entire data science team is using it not for coding. People are jumping over hoops to install a thing in the terminal so that they can use this. So we knew for a while that we wanted to build something. And so we're experimenting with a bunch of different ideas. And the thing that kind of took off was just, you know, a little quad code wrapper in a GUI in the desktop app.

48:51And that's all it is. It's just quad code under the hood. It's the same agent. Oh, wow. And Felix and the team, and Felix was an early electron contributor. He kind of knows that stack really well when he It was hacking on various ideas. And they built it in, I think, something like 10 days. It was just like 100 % written by quad code. And it just felt ready to release. There was a lot of stuff that we had to build for non-technical users. So it's a little bit different than technical audience. All the code runs in a virtual machine. There's a lot of protections for deletion and things like this.

49:25There's a lot of permission prompting and kind of other guardrails for users. but yeah it was honestly pretty obvious Boris thank you so much for making something that is taking away all my sleep but in return it's making me feel creator mode again sort of founder mode again it's been an exhilarating three weeks I can't believe I waited that long since November to actually get into it thank you so much for being with us thank you for building what you're building yeah thanks for having me and the sun bugs sounds good