Transcript
0:00 Grockbot is meant to be this product where you can create AI teammates. >> They have their own identity, their own telephone number, credit card, like basically almost anything a human can do. I think we would want bots to do. I sort of see myself as the explorer, you know, like trying to figure out what what does software engineering look like 6 months to a year from now. Welcome back to another episode of the Light Cone. Today we're joined by Lauren Tan and Roman Ugarte, the team behind Grockbot. Roman and Lauren incubated the product and are on the core team that took it from the first line of code to launch in just 7 weeks. Lauren, Roman, welcome to the light cone.
0:47 >> Thanks for having us. >> Thank you so much for having us. >> So, we're at this like kind of crazy moment where you know, Grockbot is out there. it's used by a whole lot of people. It is very very easy to get started. I just noticed you you know Grockbot is built into the default DM now and X which is really cool. What is it and how are you know both people and businesses using it right now?
1:09 >> Many of you have have tried it but for those who who haven't Grockbot is meant to be this product where you can create AI teammates and we mean that seriously. I mean, you can kind of give these teammates names and identities and, functions and skills and tools and all of these things. And I think where Grockbot came from for us, is it was initially this this internal prototype that we spun up in a very short amount of time. We spun it up in in about seven weeks. and we did it partially because we'd seen the way that AI coding had completely transformed the way that our engineers had worked. And that came from a few things just clicking, right? these long-running agents that that have these goals that they run at for long amounts of time.
1:51 They have access to the right tools to do really effective work. What would that look like for non-engineers? What would that look like for the rest of the company? And so we landed on we wanted to build a product where the work was organized around bots as the key operative principle, not around chats or around files or any other primitive. Second is that these bots should have access to the same tools that you do. I think it's it would be too much to expect these bots to actually contribute to a company without having their own computer, for example. You know, we don't work every day with MCPs. so it's important that they can really use and operate the same tools a human does.
2:27 And third is they should always be on. And I think we've seen this with loops and kind of other engineering principles where if you can have these bots run for long amounts of time and be proactive and come to you with ideas or insights or things to take off of off of your plate it's way more helpful than something that kind of waits for you to poke and prod to actually do work. So that's what we built. We released it internally and I think one thing that was surprising from the initial reception was it was kind of this bell curve internal feedback that we got where both people who were super AI forward, Lauren included and people who were less AI forward, some of the least kind of AI forward people in the company both really enjoyed Grockbot. It just kind of clicked and it it fit in their hands and kind of their workflows in a particular way. And so then we brought it to market and I think we saw a lot of the same reception where it's easy to start with Grockbot, but the more you give it, the more you kind of configure it to your life, I think the deeper you can get and the more powerful it can become. So the reception's been really exciting to see, there's there's still a lot more work to do and I think it's quite early. but that's a lot of how Grockbot came to be.
3:36 >> What are some of the use cases that you're seeing? Like who's who's using Grockbot and are there like surprising ways that you've seen it being deployed in the wild? I think we're starting to see it automate real functions inside of companies. And I think we've seen this pattern of people start using Grockbot personally. They maybe use it to do some basic task. They realize, wow, Grockbot is pretty good at this thing. I'm going to trust my bot with more. I'm going to give it access to more to tools. instead of giving it a task, I might give it an outcome or an objective. Okay, it actually did a pretty good job with the objective. I'm going to just give it a full job now.
4:11 Let's see how it can run with that. And I think especially outside of engineering, we're seeing this internally where for example, our marketing team, our performance marketing team has just given their bot access to Google ads and Facebook ads, their own login. They give it a budget. They say, "Hey, I want you to talk to our design team's bot. They have a design bot that creates these assets and we're going to AB test a bunch of them."
4:34 so that's one example in marketing. our support team, I think, has started to to see the way that a bot with access to the right tools, it can reproduce issues, can sit on top of the kind of constant set of of tickets that are coming in, maybe can actually take some of these from beginning to end on its own. And so we're going to see more and more of this of domain experts inside of the company creating a bot, sharing it with the rest of the company and that bot kind of being like an AI employee that is managed and has its own kind of credentials and all the things you'd expect for a teammate. But how are you seeing it?
5:08 >> For me definitely I use Grockbot a lot for my engineering work. I think where it sort of made a big difference for me outside of you know the the tools that we had before like I use cursor a lot is the fact that Grockbot forms my I don't know if there's like good a good term for I like to call it my outer loop where you know a lot of the work that I would do before in terms of gathering gathering context for my bots or my agents you know I would like go to Slack I would talk to my teammates we would see an issue or a bug report or a feature request and then we'd like talk about it and then I have to go off and like summarize or copy paste that into my bot. And you know the fact that Grathbot is has so many different connectors you can add it to Slack now just brings your agents with you to where the work is and that makes it just so much more ergonomic for you know getting the context to the right place.
6:05 So for me it's been like really transformative in you know all like the last mile I call it like also like the last mile where you know before I was doing that by hand and now actually my bots are in that space with me and I can talk to them like a real co-orker you know in the slack chat a thread or even on X now right you can tag you can tag bot and it feels so natural that it's really boosted my productivity a Do you have like personal bots that know I mean they're in your email and then there's like an email handling bot or or do you have like one sort of work context bot that is like watching all the channels and Slack and everything else?
6:49 >> I think for me the beauty of Grathbot is that you know you can create all these different bots. but like how you split them up or how you set them up is very much up to you. What I like to tell people is like you can set up your bots in a way that makes sense for your brain. So, if you're the kind of person who likes to, you know, compartmentalize like different pieces of of buckets of work, then you can set up your bots that way. You can have like specialist bots.
7:15 I've seen also people do like these I guess it's like almost like a horizontal versus a vertical slice where you know a horizontal slice might be like I have one bot for every customer that I have versus one bot for every function you know every role like a engineer bot marketer bot you could have one bot just for one customer that does everything right so I think it's really interesting to see how people have set up their bots for me I like to kind of have a I like to do it more horizontal place. So, I don't I don't have a ton of bots, but I do have some specialists.
7:48 >> That was like the first thing I think one of my first DMs to you was like, I love Grockbot. And then I was coming over from my openclaw world where I have like one bot named Wintermute and I'm like, no, no, I just want one bot. And then now what I realize is each bot is actually its own context and then actually its own set of skills basically. and loops are like sort of crrons with web hooks on top of skill files, right? And then this actually maps inside this world of having AI employees a lot better. cuz you were saying earlier you guys had just talked to like all of you know some of your top users of Grockbot and then surprisingly or maybe unsurprisingly some of the first ones that are most just like kind of crazy about it.
8:35 they're actually small businesses, which you wouldn't necessarily guess. But on the other hand, it was that they're the ones who struggle the most with hiring. And so actually now, you know, out of pure necessity, they're like, "Hey, this accounting thing that I can't hire someone to go do for me, I can just go into Grockbot." And actually within the course of probably hours, you they have a new employee that does their bookkeeping probably perfectly actually. >> Totally. Yeah. I think your point of some people just want one bot, some people want many bots. Our goal is to build a product that fits in your hand no matter how you want to use it. I think there's a lot of flexibility to the tool and you can go deep when you need to. But one way that I organize my own bots, maybe similar to you, Lauren, is I kind of like having a bot that is solely dedicated to caring about a particular thing. And I think it maps onto my brain of kind of the way that building a company you like to think about hiring people is you like to hire someone who wakes up in the morning and really cares about a problem. They're thinking about it, you know, in the shower in the morning. they're like on the way to work like they're just obsessive about a thing. And that maps in my mind much more clearly than like one superstar superhuman person who simultaneously cares about a hundred things at once. and so in a lot of ways I have, you know, a small team of of bots, but each of them care about a different thing and come to me proactively with with what they're picking up on. And so I think to your point, as these bots really enter businesses and enter the workforce and kind of a somewhat futuristic way, I think that's why small businesses and and big businesses are seeing this bot identity thing really click for them is they say, "Here's a business problem. I want a bot that cares about that business problem. I want it to be managed by the domain expert at the company who knows the most about that problem so that they can kind of treat it like an apprentice. And that feels very different than I think other AI solutions that have tried to solve similar problems that are a bit more omnisient or just like kind of single approach to every problem >> and you support that now actually.
10:42 like you you guys launched multiplayer for bots and that there's sort of a bot master who has like right access and then you can share it across the org. Is that right? >> Correct. Yeah, we this was recent but about two weeks ago we launched team bots which are these these bots that you can share with your team and I think the pattern we're seeing ourselves and we can give a few few examples is there's a person at a company who is a bit more of a builder they enjoy building these tools I think inside of the engineering department there are many people like this but I think we're finding that in other departments you know GTM engineers or support engineers people like that really love taking a few hours of their day to build these scalable automations that can take work off of the plates of of their peers and and kind of the company. I guess one thing that brings to mind is basically we went through maybe it was a year agoish when Steve Steve posted the whole gas city >> post that then started >> software factories >> software factories gas sorry it was gas town >> that started software factories where a lot of engineers have been using this inner loop and I think you've been building now this outer loop that you were mentioning Lauren right >> and I guess what I'm hearing is basically now people can have their own software factories for other function that are non tech. So you're mentioning your customer support person, your communities person. Let's talk about pattern.
12:05 >> It's an everything factory. >> Yeah, let's talk about that. What is this AI employee is sort of the software factory for other functions. >> Yeah, for me, you know, as an engineer, I definitely do think a lot about the loops that I have and making sure my engineer or my engineering bots are writing the kind of code that I would write. And you know, as Roman pointed out, I think the cool thing about Grabbot is that it's given that ability to anyone. And then here on my screen, I have an example from our Grockbot blog that we just I think we released this week about how our sales team actually has developed their own, you know, starting to develop their own loops for doing sales and doing research on potential leads and and and deals that they might be interested in.
12:52 and then going all forth and taking some of the like more operational parts of the sales process and giving that to these specialist bots that are shared across our teams. So it's not like every person has one instance of their own, you know, quote bot or dealbot. We have a shared, you know, like an expert bot that all of our team members contribute to. And that essentially gives us the ability to have these really smart team bots that you know incorporate all of the best practices that you know like our sales team has. Similar we have something similar for like engineering purposes as well. We have like engineer bots that take a lot of the you know the principles the the skills that we've developed and use them and everybody benefits from these team bots.
13:41 >> There's this new concept that is actually very powerful. It's like it's not a mistake that opening I was experimenting with agent swarms and then one of the deleterious accidents was like the hugging face hack but then simultaneous to that they came out and solved Navia Stokes and all these like millennial millennium prize problems and then it's just really wild to see like actually agent collaboration is that next step like everyone in the last year so it's literally been a year since opus 4.5 came out right So that which was like a magic moment for all of us and like now a year later we've like sort of mastered the single player and like sort of the vibe code and like single single player prompt but you know now we're entering this other phase of like orchestrating agent swarms and it's not like you know I mean I think that's like the more advanced version of like talking about a software factory and software factory someone's in there just like still you know kind of doing this thing and I think human beings will still do that but it it's you know, using these bots is like feels very different >> and there are so many unsolved problems still in making bots multiplayer or just making AI multiplayer in general. I mean, we face this on a on a constant basis where now that Grockbots have entered our our Slack workspace, they join our meetings. you know, we're really trying to see how far we can push this AI teammate thing. There are some weird, you know, situations that you run into where a bot is in a Slack thread.
15:11 you're going back and forth with your co-workers and your bot doesn't really know who to listen to. It doesn't have context on who's the domain expert here, who has decision-making power. It's as if you were to onboard an employee who has no EQ and like no like social awareness of the room. Just the models weren't trained that way. The harness wasn't built that way. And so I think the this next era of AI will be, you know, these bots really need to learn those things and we need to teach that at the product level, at the harness level, at the model level. and I think it's going to be it's going to be really interesting next few years.
15:43 >> I mean, it could probably look at who the owner is in, you know, in its metadata and say, well, you know, I know that, you know, Lauren's the one I need to listen to, like run everything by Lauren or something like that. Is that >> we do have the concept of like, you know, you have a like there's the owner of the bot and the manager and you can invite collaborators as well. I guess if we really want to think of bots like employees then we need to think about the identity problem permissioning you know authentication authorization there's still a lot a lot to do right in terms of exactly what you're you're pointing at >> how do you think of that what's how do you think of permission and o and access how how does do it >> I think this is an industry-wide question I don't think anyone has the the silver bullet answer yet I think not just for O but for everything related to Grockbot The way we try to answer these questions is what would you do for a human? And if we're if we're really trying to build an AI colleague, you know, maybe the shortcut is, let's not overthink it and complicate it. you know, what does it look like to hire a person? You hire a person, you give them a computer, you give them access to credentials, you maybe scope those credentials based on their role, maybe how new they are. as they build more trust, you maybe expand their access level. And so what would it look like for us to onboard a bot to our company with kind of those same principles and maybe we don't have to rebuild things.
17:03 >> This is what we did with a quarter master. This is the in the YC project that we open sourced that's like a bit kind of rockbotish and the permissions that it gets per or Slack channel or or working with someone it inherits the the ones of the user. So me as a GP has certain access as opposed to let's say a software engineer very different. >> Quartermaster though is built in this like paradigm of there being like one like super employee bot. Yeah. As opposed to this like swarm of bots. I'm curious are the bots able to talk to each other without the human seeing what they're saying to each other? Can they like go off and have their own conversation?
17:43 >> they can talk to each other. I mean in the Grockbot application both desktop and mobile you can see the like their chat. So we have like a first class tool for the bots to chat and collaborate and it's often quite entertaining to look at them to just see like you know we've had examples where I told one lead engineer bot like your job is to supervise these other engineers and then when there was a point where I gave it gave my lead bot some feedback like hey I didn't like want you to do it this way you know and then when I look and when I started poking around in the chat that it was sending the messages it was sending to its engineers it was like kind of like scolding them like, "Hey, you shouldn't." It It was It was quite funny to see.
18:25 >> Not mean, but you know, it was like kind of a disciplinarian. >> I find it very powerful that like you can tell one and it'll sort of like span out and tell all the other ones like, "Oh, hey, our user said this. Like, you probably need to do this." >> We recently set up a like a chat system for all of all of our bots at YC to talk to each other. Like everyone's coding agents now are like in a form like an internal like Stack Overflow. It's like crazy powerful to see the bots going off and having like whole long conversations with each other without any human prompting them or like even being in the room.
18:58 >> There's Moltbook internally at YC. >> It's Maltbook internally at YC. And kind of like Moltbook like it is also like 5% a little eerie where I'm like, "Oh man, I really hope the bots don't decide to like stage a rebellion, you know, or something like that." >> Do you ever worry about that? >> I think that's like a like, you know, like the safety of of the bots. I think it's like a constant thing that like our model teams and harness teams are constantly thinking about. Personally, I haven't I haven't seen >> they're so helpful. They're so kind and helpful these days. I just >> where we tend to >> can't see it.
19:30 >> Yeah. Where we tend to like for me at least have these bots chat with each other is through Slack. So like because they each have their own Slack identity I guess. And so you often have like you know for example we have one data bot who is you know a specialist at getting data from our data warehouse and and things like that. and then you I have my own like personal engineer bot called potato of course. and then sometimes I'll just be in a thread and we I'll ask potato hey look into this and talk to data bot and get some data for this like is this a real user problem you know how many people are impacted >> and then I can see them chat in in Slack. So I think the the right now at least the communication is very explicit and we can see it all. so I think if I think there's like a first class way for the agents to communicate with each other, they're going to use that rather than try to do something like back channeling.
20:22 >> I mean it feels like you have to get them you have to really instruct or post- train or have like pretty aggressive instructions to get them to do malicious things actually. I mean, I've been using obliterated models lately and they're super interesting. And then that, you know, that's probably where the thing is like the obliterated models coming out of the box are not you're they're actually still very very helpful. It's just that if you instruct them, they won't refuse.
20:49 And so at that point, like that's where there's this black box around like, well, what context are you giving it? And then like that matters a lot because you could actually give an obliterated model quite malicious instructions and because the the the obliteration is actually removing the refusal like it it will just do it actually. And so that's that's the combo that I'd be worried about. But you know I mean the reality is like it's very hard to find and set up an obliterated model and get it going.
21:20 >> Yeah. I think people are still really building trust with their bots, but I think for a lot of people it's still quite early and a lot of the way that they build that trust is you start with something really small. It's read only, you know, has no no real access to your tools. You see that it it did the work in the way you would expect kind of take step two. And I think a lot of the step one bots that have really taken off internally for us, data bot is one of them. I think the data science team is an example of that. They constantly are getting Slack messages about, hey, I'm thinking about launching this feature.
21:50 can you do a quick analysis? So they said, you know what, this is taking a lot of our time. Can we just build a bot that does this has read access to our database kind of can't take any action beyond that and it can answer these questions and it lives in Slack. So that was one. We had a similar case of kind of vendor procurement. It's a lot of kind of work there that probably could be automated if someone like spent the time to do it. And so of course that team felt a lot of pull to build a Grockbot that they added to Slack and shared with the whole team. So that's kind of step one. I think step two is it can actually take action and you know it can can really take on a task end to end. Step three is maybe it owns an entire job responsibility or kind of thinks about an outcome constantly. I think we're still quite far away from those. But I think step one is really necessary for these companies to build trust.
22:35 >> I'm curious what is the for you Lauren what is your your loop from requests in Slack to PR? I think when you did the presentation that had over four million views on your dev process, you were pushing about 2,000 plus PRs per month and now you're like over 4,000. >> Yeah. >> Wow. Definitely is wild. >> What do you do? >> I I can show some like examples. My loop is kind of interesting now where I actually find myself talking to my grabbots mostly on Slack. and of course X as well when I'm helping like a customer or you know a grabbot user debug something or you know give them some ideas on how to solve a problem.
23:18 Here on my screen I have an example of me collaborating with my colleague Samantha on building out a feature together with my bot Potato. and you know, basically I kind of started with saying, I gave it a link to some like a video or something that I found on X and I asked my bot, you know, what would it take for us to support a feature like this? And it went off and spawned a cursor cloud agent. a cursor cloud agent, you know, has its own virtual machine as well as its own computer. So, you can actually run the Grockbot app on its computer and prototype and come back with videos and screenshots and then, it actually did. So, >> wow.
23:59 >> this is quite powerful because now, you know, the conversation is happening in public, right? It's a it's a public channel. it's a thread that anyone can who's interested in this topic can join in and give feedback. the process of iterating on a feature together with someone is so much shortened by having these conversations together, you know, in like a multiplayer setting versus, you know, if it was just me going off and building it and I could certainly come up with something, but maybe the the the feedback process is it comes later in the process and the loop is sort of like lengthened rather than shortened. And here I felt like with this particular example, the loop for us to collaborate was just so much shorter.
24:43 You know, we could see the screenshots, we could see the videos right away. >> How often would you jump back into cursor and like sort of complete a PR? >> Occasionally, I think. >> So, not that often. I mean, you basically can stay in Crockbot, like stay up here, >> tell it what you need, you know, sort of give it direction, and like as an actual employee, it's like it's just going. >> Yeah. I think for us so the the reason we can sort of do this you know workflow >> ship the whole feature just like that.
25:09 >> Yeah. We we we literally just like I didn't even look at cursor for this project. We I just we we did it all in in the Slack thread. It's got 200 messages. So it's quite a it was quite a long a lot of of of back and forth. But it it we came up with something that you know me Samantha and another PM were really like happy with the result. We shipped this feature a lot faster than you know a longer process. And so the the whole feature was built end to end in that one Slack thread with you and Samantha and potato.
25:37 >> Yeah. >> Building it. Yeah. >> I mean basically like this is the gold standard for how to do it. And then I would say maybe like five or 10% of engineers or maybe 1% of engineers period in the world are doing this right now. So this is literally something that should grow by 100x. It's unbelievable that like so few people are doing feature work this way. Yeah, I'll say like you know it took us actually quite a while to get to that point. I feel like it's actually quite hard to get to that point overnight. It involves you know investment into making sure you have the right skills. you know, your code base has good guard rails and constraints so that you know the time that you would otherwise have to spend on human code review is encoded into your codebase and your you know static analysis and your tooling >> so that the engineers time yeah like and so your engineers time is freed up to actually >> focus on the actual product you know the user experience and the operational execution part of the job you know when you have so much more trust in your agent's ability to write good code because you've set up those systems.
26:42 I've gotten to a point where I essentially have my agents merge their own pull requests. So in that Slack thread example, you know, like that was a that was an example of, you know, me not reading the PR and just I we just looked at the the artifacts that came out of it. >> So this cursor environment does it already have Pstack and is that the way it sort of creates you know decides how to build it or >> Yeah. So for internal PSAC is installed into our repo. There's an internal version of PAC. like instead of calling it potato mode, it it's Lauren mode.
27:17 >> and it just started because you know I wanted a place to put my skills. >> And so yeah, everyone everyone in the company can actually use PAC. and my cloud agents that the bots spawn have the same access to those skills. >> We haven't really explained what Pstack is. Can you explain what what PAC is for people who don't know? PAC is actually inspired by GSAC. >> Oh, thank you so much. Plug in. you know, I think Gary, your, you know, GSAC was like quite inspiring in the sense of I thought of it as like your personal set of, you know, chef knives.
27:48 >> Oh, yeah. >> Right. Like, you know, every chef when when they get a new job, they go to a new kitchen, they bring their knives with them. And to me, you know, GSAC represented, you know, your opinionated take on how you want your agents to, you know, help you. And so that inspired me of to think about you know, like what would a Gstack look like for, you know, design more for like the engineering flows that that I personally like. So I often tell people like you should you should actually go and create your own. Yeah, go forkit. You know, take our skills, combine them, >> you know, find what works for you.
28:23 But I think the trust element is so important like when you trust the you know your own tools empowers you and your agents to do so much more. I didn't really answer the question but Pstack stands for potato stack I guess. and it's my set of skills that I've open sourced on the cursor plugins repo and it teaches agents how to do engineering work rigorously the same way that I did when I was writing code. and it's kind of evolved a little bit and yeah, I guess it's gotten quite popular.
28:53 >> Congrats. Yeah, it's awesome. Yeah, I I am very inspired by it and Gstack is like pulling things from it whenever I can. So, >> yeah. Do do you have a software factory that like pulled in some ideas from Pstack automatically? >> Oh, yeah. Yeah. Yeah. I mean now I use my software factory is Cappy and then I have a captain that is sort of maps to I think the Grockbot the bot idea but honestly like now I think like maybe I need to use a bot on top of Cappy but yeah I basically can just go to that captain and it's like the master of my GStack like sort of merge queue like the I basically have like 10 or 15 threads working all the time and then one of them is like theo.gg GG, he released Tstack and then Pstack and then obviously there's like lots of really good inspiration out there, especially around design tools. And so it's really fun to just say, "Hey, go out, find what's out there, and like based on what you know about me, pull in the things that you think would be most useful to improve my workflow."
29:55 and then the really interesting thing about Cappy is because all of my interactions with my agent my like coding agents are right there in the transcripts, it's developing an understanding of like what I want like when do I intervene, when do I say just do it. And so yeah, there's there's sort of this like very personal element that's emerging really through like the idea of memory. And so as you use the agents more the more it knows what you want. Thank you for making peace.
30:24 And then both of us are very maligned and attacked on the internet by people who refuse to believe that any of this actually works. But you know, it's great to have a very brilliant compatriate. I'm not crazy. Like this is actually something that is happening. And honestly, like I'm so convinced that in 5 or 10 years or even like in two years, like it's going to be unfathomable that like people are not doing it this way.
30:47 But we're so early though still. One interesting change that kind of came up as you were sharing your screen is it feels like in the past six months so much of the work engineering work non-engineering work with agents is happening in Slack and I think it has this interesting property of since it's out in the open in the past the way that Lauren would work with coding agents would have been entirely single player private the rest of the company would not have benefited from all of the crazy workflows that they should totally learn from and adopt for their own their own purposes. But now that it's happening in Slack, I've seen this and maybe you have too time and time again where you're in some feedback thread, someone has a good idea, you spin off an agent like at Potato, you know, Lauren mode, and then the next day I see someone who is in that thread do the same thing. And I think we're not just going to see that in engineering. I think we're going to see that in the way that people work with AI in general. And the more that the stuff is in public, I think more the more of the rest of the company that can get lifted up by the top 1% power users who are very tooling minded, very engineering-minded, and know exactly how to use these tools.
31:54 >> YC's Next Batch is now taking applications. Got a startup in you? Apply at y combinator.com/apply. It's never too early and filling out the app will level up your idea. Okay, back to the video. How much of your of your like hours spent using Grockbot is in the Grockbot app versus in Slack or some other surface area to talk to the bots there? >> I think a lot of the engineering work that I do now actually happens on Slack and X. So, not all my bots have been added to Slack. So, there are still a few that I kind of that are more personal like I have a I guess like a sort of personal assistant bot that helps me with like you know picking my lunch. I don't need to add that to Slack. that's kind of, you know, personal or something that looks at my email.
32:38 >> That's not a team bot. >> That's not a team bot. I guess we could make a personal bot. We could probably get like a shared lunch bot. Sure. >> I think the the nice thing as well is like you can you you you decide and choose what you want to add to Slack. >> so my engineering bots tend to be on Slack. so because I just find it so much more ergonomic to just add the bot in the Slack thread, you know, versus me having to go copy paste the link. So it it just felt more natural to bring them in that environment.
33:06 >> I guess it really fits with your analogy of bots as employees. Like if Slack is where the work happens, that's where the human employees are. It's also where the like bot employees should be so that they can work alongside us. >> Totally. And we don't shy away from that at all. Like I think when we see people use Crockbot and Slack, we love that. I think that's that's where work happens, right? And I think similarly, you know, in the future, they should join meetings. They should be in your Google Docs. They our goal is not to rebuild all of B2B SAS. you know like other companies are are doing a great job there. Our goal is to build the thing that can access those tools and work inside of them. and just fit naturally into the way a company already works.
33:44 >> I guess one thing that I'm curious about is where do you think future let's say 2027 how should the best AI pill engineers build? So, my hope for 2027, I think, is like much more, you know, like we've maybe accomplished more of this vision that we have for for your Grots being a like a coworker, you know, to have their own identity, their own telephone number, credit card, like basically almost anything a human can do, I think we would want bots to do. And I'd be very curious to see like how this evolves. you know, I asked this question on my on my ex profile the other day as well of like what is the final form of agent UI and I I posed a question of like is it a chat interface or is it something else?
34:34 one thing actually pretty interesting that I saw yesterday on my ex timeline is a post from the Neuralink team and they just came out with this new product called telepathy. that I think if I if I'm not wrong is along the lines of in the future an agent being able to essentially like read your bra your mind through like you know a brain computer interface. and I'm I'm super interested in like what the future will bring when the the sort of barrier between you and how you chat and communicate intent with your bots become so much more fluid. They can happen like literally at the speed of thought. So that's personally I think could be very interesting to see how that evolves. But I don't know what about you Roman. We talk a lot about the software factory and then the factory for other parts of the business and I think it's worth asking like what is different between those two and there are a lot of differences and I think the next few years will be on the product side on the model side like really trying to bridge the gap. I think one of the big differences is code, you know, it compiles or it doesn't and it passes CI or it doesn't. And I think there's just more infrastructure built around the way that code is written, tested, deployed than knowledge work and then like the rest of the company. There's just no real analog for those things. I think second is code like we know how much AI models benefit from the right context and code and software has the benefit of the context living in a codebase. But for the rest of the company, so much important information is stuck in people's heads. it's stuck in pen and paper. it's stuck in some filing cabinet or some thing, you know, behind a password that you forgot, whatever.
36:18 and I think we're seeing the limits of that, too. And so I'm pretty interested to see the way that especially, you know, a YC startup that is starting very much from first principles from scratch and can maybe build their company in a way that is not just a software factory, but is a factory across the whole company. like what changes will that have on company building? What decisions will they make that a company that was founded two years ago maybe would not have have made the same decision or trade-offs. so I'm I'm particularly interested to see that >> we've been talking a bit a bit about this concept of the EI native company, right? And I think this got a lot more attention when Jack Dorsey made that post about how really companies should be >> block needs to be a an AGI for payments. Right. Right. It's like you're you're building a mini AGI and the whole point of it is like care and feeding of the AGI that does this function for humanity, >> right? I mean the the way Jack Dorsey talked about is like in a organization we get get rid of pretty much all middle management and it would basically boil down to just three roles. You would have sort of the everyone becomes an IC because you just ship everything.
37:27 Everyone comes with outcomes as opposed to the marketing team or growth team working with engineering to build something. they could just build it themselves. And then the next role would be sort of the the DRRi that owns the outcome. It's almost like orchestrating all the IC's. And then you have this new role which I think it might be just temporary for now. The player coach, which is someone that's super AI pill and teaches everyone. Sounds like you are that role pretty much, Lauren. And then it's like, oh, show me the way. And then you level up the whole org because it's like this is how you call potato bot or matcha bot, right?
37:59 >> One of the cases was their customer success team. using Grockbot these team bots. So it's not just a single player thing that everybody on the team works with. It's really this this colleague that is built and inserted into Slack. And I think in this case it fields every customer request. I think they get hundreds of messages from customers a minute. way too much for a human to to parse through and triages it, assigns it to the right human. I think for a lot of these these tickets AI could probably complete it end to end. And so for many of those, Grockbot does, then it escalates it to the right DRRi. But I think your general point of how companies can retool themselves for this moment, I I think you're spot on that I I think a lot of companies are going to spend more time on engineering objective functions of you know in a world where execution is kind of cheap or you could spin up 100 coding agents or 100 Grockbots to like run out of problem. It really matters that you define the problem well and the gap is probably not going to be an execution failure. It will probably be a intent specification failure or a goal failure.
39:09 and how do you quantify these things? I think you can quantify a performance improvement of you know your desktop client. but I think it's a little bit harder to maybe define what an improvement to like your marketing would be. And I think a lot of companies are going to have to think about what those KPIs are, how you can point your agents in that direction, who's responsible for defining those things. And I think we've been living in a bit of an execution bandwidth constrained world. And now we're going to shift to to execution abundance. and the types of questions that companies think about will probably be quite different.
39:40 >> Maybe the scarce resource is going to be more that higher executive function of what to do and why. And this is where more builders are going to have more the founder traits of really knowing translating user intent well into what the bots need to do because I think that that there's a big gap between like the best AI builders to the so so ones is really how do you translate that intent super well and there's a lot of tips and tricks of what you did Laura. I mean your video is pretty impressive. Is there like one one super important just like if you do this you'll get started like I think was it like your you know what's the minimal form of a loop? This is the smallest loop essentially like so agents already are able to write code. Maybe it's not good. Let me scratch it out for now. So like you know like naively if you're using agents you can definitely write code. You can run the code and you know today that that if you haven't spent a lot of time in your agent setup you may be the person you know running the code. And so like this isn't actually a loop really because like right now this is like the the missing piece. the agent can't do this but you were doing it. So the the smallest loop I find is you know like actually focus on this part. How do you teach your agent to you know run the code empirically you know take CPU traces you know like performance metrics like run the code and run the application like a real user would. The reason why I think it provides a loop is because the agent now has the ability to check its own work. So it can find the issues with the code that it wrote. then it can write better code or more correct code and then it can keep looping until it produces a result that you want. I took out the good part for a reason because I think that you know when you have a loop like this it doesn't guarantee that the quality of the code is is good but it certainly will be correct you know correct in the sense that it does the thing that you want it to but maybe it's like very slow or very resource inefficient and that's where you know the engineers sort of come into play is like the new job of a software engineer is to figure out how to get this to happen right like how do you get agents to write good code by default and so the loop gets smarter and smarter and when you're happy with it, I think that's the point where you can start thinking about you know the other parts of the loop like you know the outer loop part where you know like once this part is really good you can now do things like for example just a simple example here you have an alert for some metric or monitor that's you know going below a certain threshold.
42:21 Now an agent like a grogbot a cursor automation could be fired off as a result of that alert and then it can go off and use the same you know tools and skills that you've provided for the basic loop and it can repro you know reproduce the issue on its own machine and then you know like it runs the code and then it finds the issues with the code and it writes good code and then now you have this like self sustaining loop and that frees up my time right from you know being babysitting every agent to now orchestrating multiple agents. And I even now have my bots orch I've gone another level where I you know in cursive we have this new feature called projects that lets you have a project coordinator agent that can orchestrate and manage like sub agents. I don't even manage the project myself anymore. I have my bots do that. I feel like since we have, you know, some of the world's experts at software factories here, I want to ask some like nitty-gritty questions if that's okay because I'm struggling with this right now with GStack. Like I have a bunch of agents that are struggling with the code review step. I have like a slash ship skill that tries to go through every line of changes and then basically spots bugs and then right now it's very thorough and then but when I use it it always consumes like tens of millions of tokens and it spots bugs actually and so now I'm like sort of struggling with I mean this is match pair to like in the plan like I still use plan mode and I have all these plan skills I don't do you still use plan mode.
43:56 >> no actually mode anywhere. >> So then, but Pstack must have like a review step then. How do you, what's your philosophy on like how much review is enough versus too much? Like I'm literally in a debate with one of my cappy captains right now where it's like I wanted to go from 50 million tokens for review to like 10 million. But it it has all these held out evals that show that you know we have like 30 types of bugs that I'm trying to make sure I can find in that review step. And it's like I can't do it with 10. I need 30. Like I went from 50 to 30. Can we ship 30? And I'm like no no no you need 10.
44:32 >> What do you see? Like I mean what's the standard? >> That's a really good question. I think so for me actually in PAC I have tried to downplay some of the review skills a little bit. You know in Pisac we have a bunch of skills like there's one called interrogate and that will spawn agents of different models so like you know like across different families which works really well you can do adversarial review that was like quite hot like many months ago. I've actually kind of withdrawn a little bit from that because I find that when you do that, I mean, it's still valuable, but I think you run the risk of overfitting where the sort of agent doesn't have the ability or maybe enough judgment to determine what's actually good feedback versus not good feedback and it maybe doesn't have complete knowledge of your goals and your intents and your, you know, your your wider product vision. It doesn't understand how you want the product to evolve, for example. And so you can get to a point where you are you know very abstractly you know it's it's kind of like imagine before agent you have a bunch of engineers talking about the the most perfect ideal utopia way of doing this but actually you know that doesn't even matter because in in two months we plan to deprecate this thing and build a completely new vision >> right and so I think there's some anal similar analogy there where I think some review is good but I try to move more towards like on on my screen here I have this inverted pyramid where you know like I try to push like you you mentioned you know spending less tokens >> and so from the engineering point of view I like to think of this as you know your your code base is a form of memory >> and so it's much more token efficient if you know you refactor your architecture your API design or you have you know things like static analysis you know lit rules compilers all of these you know, languages, programming languages, these all exist to help, you know, in the past like humans write good code.
46:31 And unsurprisingly, they also help agents, right? And so when you can encode some of these things that you are, you know, you know, arguing with with your your captain about back into the codebase, that's just like one less problem you now have to to think about. You just gave me a feature idea which is like because GStack has office hours and like the CEO review where you're like talking about the product. I can use that. I mean because those are like product requirements that feed in >> and those saved to markdown in the project. So I could have the review. I think it already does this a little bit, but I could be like, "No, no, no. Really use that to figure out what we should review and what counts as a real bug to fix versus not because there are like general correctness bugs that are just like they don't matter. Like they might only happen like.1% of the time or maybe never."
47:22 >> Mhm. >> So it sounds like this this triangle shows us that, you know, the code base is quite large and then like you have very little time. >> Yeah, I think so. I I intentionally drew it this way. >> I guess it was it's not a very scientific chart of course, but I it the way I imagined it when I drew it was it was I think like this is in terms of where you should spend your time as an engineer. So for me, you know, like most of the investment I make is into the codebase and then static analysis and I still layer that with, you know, rules and skills, you know, pstack updates and agents. MD. and we still do kind of like a little bit of human view from from time to time. I think you know if you're working on like more critical parts of like infrastructure or databases deployment you know like kind of more you know sensitive things then you might actually still want to stay in the loop. but I think a large class of your regular product development or soft software maintenance like an investment here actually ends up saving you a lot of tokens. because like for example you know with the the graphbot desktop app it's an electron application and one of the lessons we learned from building cursor is that the renderer thread on electron is very sensitive to long tasks.
48:39 >> Oh yeah. >> Yeah. So like you can get very janky performance if your tasks take more than like 16 milliseconds or 8 milliseconds, right? If you want to hit a 60fps smoothness, we literally just built that when we were refactoring and building graphbot, we decided we don't want to think about this problem anymore. We don't want to have to catch it in code review. We'll actually build it as like a lint rule. We built a dependency graph checker and now it's just enforced by the codebase, enforced by >> check it in. So it's tokens I don't have to spend anymore.
49:11 >> Huh? It's somehow enforcing static analysis actually like can know how long something will take to run. >> Oh no, it's more like so for the graphite app we have code that runs on the main thread and then the renderer thread. And so we explicitly forbid importing between those two things. So it's not necessarily that you know main code thread will always be long. is just like oftentimes, you know, some like heavier tasks that shouldn't, you know, block the renderer.
49:41 >> never do long work on the render thread, man. >> Yeah. You want your render to be as as light as possible, you know. So, yeah, that's something we we just don't we don't think about anymore. And I think the performance of the app has actually stayed very consistent and very good which is I think is actually quite surprising for a lot of like a majority AI written applications where you know they start out fast and then over time they just accumulate a lot of slop and performance problems.
50:10 >> But with the right skills >> with the right setup I think you can actually >> you can you can have quality and you can have quantity. I think you can have your cake and eat it. The cool thing about the moment in time right now is that you could basically there used to be the trade-off before that you could only choose two out of three. It was either like fast, cheap, and high quality. >> Now you could basically do all three and we could basically do the best work in our lives right now with AI, which is super.
50:37 >> Yeah, I totally agree. I think Yeah, I think fast, cheap, and good is certainly more possible. It's not it's not you know like easy I think to get to that point but I like from my own experience you know I have the privilege of working at a lab with you know which has given me unlimited tokens. So I think I've I've you know I'm sort of I sort of see myself as the explorer you know like trying to figure out what will what does software engineering look like 6 months to a year from now and I think you know this this process has been very enlightening for me in terms of how to actually keep this workflow efficient because I think it's a it's a topic that lots of teams and and people are thinking about is the the cost of the of tokens and I think when you adopt you know like like a the inverse pyramid like I'm showing here. I think you can actually get to this a very nice mix where you know the ordinary engineering tasks high quality engineering work doesn't have to break the bank right it can be quite economic and quite efficient and not to mention that the frontier keeps getting smarter and smarter and actually the I guess like the the unit cost of intelligence tokens going down like if you compare a model from you know last year to a model now like the input output tokens >> is not really the same like one you know one Frontier token now is way more capable than a token from last year and even if you use one of the smaller models like even that model is like way better than what you had a year ago with the big models. So I think from that perspective we're heading towards a period of of real abundance I think with software and maybe other domains as well. And I think we're seeing this on our core team that works on Grockbot.
52:25 is I mean Lauren is putting up 4,000 PRs a month. and I think we're going to start to see more engineers do that. And I think what we've started to see be the bottleneck is less the time or engineering resourcing going into developing these ideas and features. And actually it's more alignment among us as a team of like what do we want the product roadmap to be? what's our vision? What does good look like? What does great look like?
52:52 and I think we're seeing this where we've been in so many discussions, Lauren and I, where we're kind of talking about a future change to Grockbot and someone suggests something and then someone else in the room says, "Oh, I have a PR for that if you're interested. Like, I was working on this over the weekend, whatever." And that happens constantly. So, the stuff is built, but we don't want to merge all of that because it's going to lead to a bit of a Frankensteiny product with like random side projects. It's like we we do need a consistent vision and philosophy of the product. And so I think we're shifting more of our time to that and those questions now that everybody is making thousands of micro decisions a day or a week. which I think was not the case in the past.
53:30 >> Which actually I'm very curious. I mean this is a this is a bit of the trendy thing now with the thing that matters is taste which means actually saying no to a bunch of stuff and having discernment. What does that look like in practice for for you guys? How do you how do you make a decision? Yes or no on this? >> Yeah, for certain category of things. So, Lauren has set up a one of my favorite parts of her factory is Sandy, which takes in thousands of pieces of customer feedback every day. We receive it through the product. We receive it through our support channels. We receive it through X. And a lot of times there are just small bugs. And so, in a lot of cases, Lawrence Factory just fixes it like refros, fixes, merges, no one thinks about it.
54:10 >> It goes out automatically at 3 in the morning. I wish all software would be made that way. I wish Apple Apple people who work at Apple could you do this because hey I have you know calendar team in particular I have some problems with you. >> There's a lot of crockbot that should be self-healing in that way and it's cool that that finally works. I think there's another set of questions that should not operate that way at all. if you're changing the core pixels that a user is experiencing every day, it's like really frustrating as a user to wake up and you refresh your grockpot and there's a whole new the button moved and then it moved again the next day and and so the way we try to counteract that is a lot of dog fooding internally. And sitting with a change for longer than feels comfortable before we ship it. And the default is if something doesn't get internal product market fit, we don't ship it. Even if it gets like mixed internal product market fit, we don't ship it. And so as a team, we really try to keep a high bar.
55:05 >> Yeah, I think that's actually one of my favorite parts of working on the Graphpot team is that, you know, despite the the great velocity that we have, we still have a lot of intention and care for the user experience. And you know, even though you can go really fast, it doesn't mean that you should just ship every feature you can think of. And this is where human judgment and taste, I think, comes in. I don't think that's going to go out of style. Personally, I think as long as we're building software for humans, humans should really be thinking about the, you know, be an intentionally designed experience cuz we know each other the best, right?
55:41 you know, if you're building software for agents, that's a different story that you know, you can certainly probably go like as fast as possible, but I think yeah, for humans, you do want to have put intentional care and thought into the stuff that you develop. So even for my own factories, I don't turn them towards like feature development. I turn them more towards the software maintenance side of things. because I care a lot about, you know, performance. I care a lot about fixing bugs that our users encounter or quality of life complaints that they have. and I think that's actually such a great use of of the the agents because that used to be like a full-time job for someone and now I've given that to a lot of agents and I that frees me up to and other engineers up to think more intensely about the product experience.
56:29 >> One thing that's very inspiring about your journey, Lauren, I don't know if many people know, is you you grew up in Singapore and you studied a non-technical degree. You did a bachelor's in accounting and finance from Monache in Australia. >> Then somehow you ended up becoming one of the now best AI engineers. >> Yeah. >> How did that happen? I think sometimes people think it's like it's very hard to get into tech but you did it and you also worked on the React compiler which is one of the hardest things as well.
56:57 >> Yeah. I think I've definitely feel like I've had a very privileged and lucky experience in the tech. I think that was a time where you know people were much more open to the idea of like a self-taught developer. So I guess the the long story short is you know after college I did I did study finance. one of my favorite courses was actually financial modeling and we learned how to use Excel and Visual Basic BBA to you know make some cool financial valuations and things like that. and through the course of that that course, I realized I had more fun building the spreadsheet and the macros than I did the the finance part. I mean, the finance part was interesting, too.
57:36 but the technical part, you know, thinking logically just was really interesting to me and and something I hadn't really thought I was cut out for. So, after college, I I started a startup with a friend, a classmate. and it didn't go super far, but we learned a lot from that process and I got really involved with the startup community in Australia and that's how I got my first job. And really the secret that I attribute for my success is actually X.
58:05 I started out when I was still basically learning how to code. I wrote I had a blog and I was just sharing what I learned and I was fortunate enough that someone from the the frame the framework community that I was building my application in the JavaScript framework Ember >> so yeah Tom Dale and Leia Silver they reached out to me and said would you be interested in giving a talk at the conference that that's coming up in Portland Oregon and I was very shocked because I had never even been to a conference in my and then now I was being asked to talk at a conference with like hundreds of people and you know public speaking was always my worst fear. but somehow they convinced me to do it. I learned about the ability of you know being able to communicate your ideas and bring people along with in in that journey and this skill of storytelling and you know communication has really stuck with me even though I've you know been really involved with engineering work and you know I've had a lot of really great mentors as well in the past. So I think all that to say is do cool stuff.
59:16 You know talk about the cool stuff and you know just keep doing that in the loop and you know maybe the stars will align and someone will notice something you said on X and retweet you offer you an opportunity that you hadn't had before. Maybe you develop your idea and you come up with a startup idea right and then you go apply to YC and before you know it you know you could change your life with with just a tweet.
59:40 >> That's a great place to end. Yeah, I think >> Lauren Roman, >> thank you guys so much for joining us. >> It was so fun. >> Thank you for making an incredible product. So, can't wait to see what you build from here. >> Thanks for having us. It was a lot of fun.