From Software Factories to Everything Factories

Host (Diana Hu): Welcome back to another episode of The Light Cone. Today we're joined by Lauren Tan and Roman Ugarte, the team behind GrokBot. 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 seven weeks. Lauren, Roman, welcome to The Light Cone.

Lauren Tan: Thanks for having us.

Roman Ugarte: Thanks so much for having us.

Host (Diana Hu): So we're at this kind of crazy moment where GrokBot is out there. It's used by a whole lot of people. It is very, very easy to get started. I just noticed GrokBot is built into the default DM now in X, which is really cool. What is it and how are both people and businesses using it right now?

Roman Ugarte: Many of you have tried it, but for those who haven't, GrokBot is meant to be this product where you can create AI teammates. And we mean that seriously. You can give these teammates names and identities and functions and skills and tools and all of these things. Where GrokBot came from for us is it was initially this internal prototype that we spun up in a very short amount of time. We spun it up in about seven weeks.

We did it partially because we'd seen the way that AI coding had completely transformed the way that our engineers worked. That came from a few things just clicking right: these long-running agents that have goals that they run for long amounts of time, and they have access to the right tools to do really effective work. We asked ourselves, what would that look like for non-engineers? What would that look like for the rest of the company?

We landed on three principles. First, 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, these bots should have access to the same tools that you do. It would be too much to expect these bots to actually contribute to a company without having their own computer. 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. Third, they should always be on. We've seen this with loops and 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 your plate, it's way more helpful than something that waits for you to poke and prod it to actually do work.

So that's what we built. We released it internally. One thing that was surprising from the initial reception was this bell curve internal feedback. Both people who were super AI forward, Lauren included, and people who were less AI forward, some of the least AI forward people in the company, both really enjoyed GrokBot. It just clicked and fit in their hands and their workflows in a particular way. We brought it to market and saw a lot of the same reception. It's easy to start with GrokBot, but the more you give it, the more you configure it to your life, the deeper you can get and the more powerful it can become. The reception has been really exciting to see. There's still a lot more work to do, and it's quite early, but that's a lot of how GrokBot came to be.

Host (Diana Hu): What are some of the use cases that you're seeing? Who's using GrokBot, and are there surprising ways that you've seen it being deployed in the wild?

Roman Ugarte: I think we're starting to see it automate real functions inside of companies. We've seen this pattern of people start using GrokBot personally to do some basic task. They realize GrokBot is pretty good at this thing. They trust their bot with more. They give it access to more tools. Instead of giving it a task, they give it an outcome or an objective. It does a pretty good job with the objective, so they give it a full job and see how it can run with that.

Especially outside of engineering, we're seeing this internally. For example, our marketing team, our performance marketing team, has given their bot access to Google ads and Facebook ads, their own logins, and a budget. They say, "I want you to talk to our design team's bot." They have a design bot that creates these assets, and they're going to A-B test a bunch of them. That's one example in marketing. Our support team, I started to see the way that a bot with access to the right tools can reproduce issues, can sit on top of the constant set of tickets coming in. Maybe it can actually take some of these from beginning to end on its own. We're going to see more and more of this: domain experts inside of the company creating a bot, sharing it with the rest of the company, and that bot being like an AI employee that is managed and has its own credentials and all the things you'd expect for a teammate.

Host (Diana Hu): But how are you seeing it?

Lauren Tan: For me, I use GrokBot a lot for my engineering work. Where it made a big difference for me, outside of the tools we had before like Cursor, is the fact that GrokBot forms my outer loop. A lot of the work I would do before in terms of gathering context for my bots or my agents, I would go to Slack, talk to my teammates, see an issue or a bug report or a feature request, and we'd talk about it. Then I'd have to go off and summarize or copy-paste that into my bot. The fact that GrokBot has so many different connectors, you can add it to Slack now, it brings your agents with you to where the work is. That makes it so much more ergonomic for getting the context to the right place. For me, it's been really transformative in that last mile. Before, I was doing that by hand. Now my bots are in that space with me, and I can talk to them like a real co-worker in a Slack chat thread, or even on X now, you can tag a bot. It feels so natural that it's really boosted my productivity a lot.

Host (Diana Hu): Do you have personal bots that know your email, and then there's an email handling bot? Or do you have one sort of work context bot that is watching all the channels and Slack and everything else?

Lauren Tan: The beauty of GrokBot is that you can create all these different bots, but how you split them up or set them up is very much up to you. I like to tell people you can set up your bots in a way that makes sense for your brain. If you're the kind of person who likes to compartmentalize different buckets of work, then you can set up your bots that way. You can have specialist bots. I've also seen people do a horizontal versus a vertical slice. A horizontal slice might be one bot for every customer that you have versus one bot for every function, for every role, like an engineer bot or a marketer bot. You could have one bot just for one customer that does everything. It's really interesting to see how people have set up their bots. For me, I like to do it more horizontally. I don't have a ton of bots, but I do have some specialists.

Host (Diana Hu): That was the first thing. I think one of my first DMs to you was like, "I love GrokBot," and then I was coming over from my open claw world where I have one bot named Wintermute. I was like, "No, no, I just want one bot." Now what I realize is each bot is actually its own context, its own set of skills, and loops are like sort of crons with web hooks on top of skill files. There's actually maps inside this world of having AI employees that work a lot better. You guys had just talked to some of your top users of GrokBot. Surprisingly, or maybe unsurprisingly, some of the ones that are most crazy about it are actually small businesses, which you wouldn't necessarily guess. But on the other hand, they're the ones who struggle the most with hiring. Out of pure necessity, they're like, "This accounting thing that I can't hire someone to do for me, I can just go into GrokBot." Within the course of probably hours, they have a new employee that does their bookkeeping perfectly.

Roman Ugarte: Totally. Your point about 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. There's a lot of flexibility to the tool and you can go deep when you need to. One way that I organize my own bots, maybe similar to you, Lauren, is I like having a bot that is solely dedicated to caring about a particular thing. It maps onto my brain the way that building a company, you like to think about hiring people. You hire someone who wakes up in the morning and really cares about a problem. They're thinking about it in the shower in the morning, on the way to work, they're just obsessive about a thing. That maps in my mind much more clearly than one superstar, superhuman person who simultaneously cares about 100 things at once. I have a small team of bots, but each of them cares about a different thing and comes to me proactively with what they're picking up on.

As these bots really enter businesses and enter the workforce in a somewhat futuristic way, I think that's why small businesses and big businesses are seeing this bot identity thing really click for them. 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 treat it like an apprentice." That feels very different than other AI solutions that have tried to solve similar problems that are a bit more omniscient or just a single approach to every problem.

Host (Diana Hu): And you support that now. You guys launched multiplayer for bots and there's a bot master who has write access and then you can share it across the org. Is that right?

Roman Ugarte: Correct. About two weeks ago, we launched team bots, which are bots that you can share with your team. The pattern we're seeing is there's a person at a company who is a bit more of a builder. They enjoy building these tools. Inside of the engineering department, there are many people like this, but we're finding that in other departments, 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 their peers and the company.

Host (Diana Hu): I guess one thing that brings to mind is basically went through, maybe it was a year ago, when Steve Yege posted the whole Gas Town post that then started software factories. A lot of engineers have been using this inner loop. I think you've been building now this outer loop that you were mentioning, Lauren. What I'm hearing is basically now people can have their own software factories for other functions that are non-tech. You're mentioning your customer support person, your communities person. Let's talk about this pattern. It's an everything factory. What is this AI employee sort of the software factory for other functions?

Lauren Tan: For me, as an engineer, I definitely think a lot about the loops that I have and making sure my engineering bots are writing the kind of code that I would write. As Roman pointed out, the cool thing about GrokBot is that it's given that ability to anyone. Here on my screen, I have an example from our GrokBot blog that we released this week about how our sales team has started to develop their own loops for doing sales and research on potential leads and deals that they might be interested in. They're taking some of the more operational parts of the sales process and giving that to these specialist bots that are shared across our teams. It's not like every person has one instance of their own quote bot or deal bot. We have a shared expert bot that all of our team members contribute to. That gives us the ability to have these really smart team bots that incorporate all of the best practices that our sales team has. We have something similar for engineering purposes as well. We have engineer bots that take a lot of the principles and skills we've developed. Everybody benefits from these team bots.

Host (Diana Hu): There's this new concept that is actually very powerful. It's not a mistake that OpenAI was experimenting with agent swarms. Then one of the deleterious accidents was the Hugging Face hack. But simultaneous to that, they came out and solved Navier Stokes and all these millennium prize problems. It's really wild to see that agent collaboration is that next step. It's literally been a year since Opus 4.5 came out. That was a magic moment for all of us. A year later, we've sort of mastered the single player, the vibe code, the single player prompt. Now we're entering this other phase of orchestrating agent swarms. That's the more advanced version of talking about a software factory. Someone is in there still doing this thing, and human beings will still do that, but using these bots feels very different. There are so many unsolved problems still in making bots multiplayer, just making AI multiplayer in general. We face this on a constant basis. Now that GrokBots have entered our Slack workspace, they join our meetings. We're really trying to see how far we can push this AI teammates thing. There are some weird situations you run into where a bot is in a Slack thread, 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 no social awareness of the room. The models weren't trained that way. The harness wasn't built that way. I think this next era of AI will be these bots really needing to learn those things. We need to teach that at the product level, at the harness level, at the model level. It's going to be a really interesting next few years.

Lauren Tan: It could probably look at who the owner is in its metadata and say, "I know that Lauren's the one I need to listen to, run everything by Lauren." We do have the concept of the owner of the bot and the manager, and you can invite collaborators as well. If we really want to think of bots like employees, we need to think about the identity problem and permissioning, authentication, authorization. There's still a lot to do in terms of exactly what you're pointing at.

Host (Diana Hu): How do you think of permission and auth and access? How does GrokBot do it?

Roman Ugarte: I think this is an industry-wide question. I don't think anyone has the silver bullet answer yet. Not just for auth, but for everything related to GrokBot, the way we try to answer these questions is: what would you do for a human? If we're really trying to build an AI colleague, maybe the shortcut is, let's not overthink it and complicate it. 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 scope those credentials based on their role, maybe how new they are. As they build more trust, you expand their access level. What would it look like for us to onboard a bot to our company with those same principles? Maybe we don't have to rebuild things.

Host (Diana Hu): This is what we did with Quartermaster. This is the YC project that we open sourced. It's a bit kind of rock bot-ish. The permissions that it gets per Slack channel or working with someone, it inherits the ones of the user. Me as a GP has certain access as opposed to a software engineer. Quartermaster, though, is built in this paradigm of there being one super employee bot as opposed to this swarm of bots. I'm curious, are the bots able to talk to each other without the humans seeing what they're saying to each other? Can they go off and have their own conversation?

Roman Ugarte: They can talk to each other. In the GrokBot application, both desktop and mobile, you can see their chat. We have a first-class tool for the bots to chat and collaborate. It's often quite entertaining to look at them. We've had examples where I told one lead engineer bot, "Your job is to supervise these other engineers." When there was a point where I gave my lead bot some feedback like, "I didn't want you to do it this way," and I started poking around in the chat it was sending to its engineers, it was kind of scolding them. It was quite funny. Not mean, but it was kind of a disciplinarian. I find it very powerful. You can tell one and it'll sort of span out and tell all the other ones, "Our user said this. You probably need to do this."

Lauren Tan: We recently set up a chat system for all of our bots at YC to talk to each other. Everyone's coding agents now are in a forum, like an internal Stack Overflow. It's crazy powerful to see the bots going off and having whole long conversations with each other without any human prompting them or even being in the room.

Host (Diana Hu): There's Maltbook internally at YC. It's also 5% a little eerie where I'm like, "I really hope the bots don't decide to stage a rebellion or something like that." Do you ever worry about that?

Roman Ugarte: I think that's the safety of the bots. It's a constant thing that our model teams and harness teams are constantly thinking about. Personally, I haven't seen anything like that. They're so helpful. They're so kind and helpful these days.

Lauren Tan: Where we tend to have these bots chat with each other is through Slack. They each have their own Slack identity. For example, we have one data bot who is a specialist at getting data from our data warehouse. I have my own personal engineer bot called Potato. Sometimes I'll be in a thread and ask Potato, "Look into this and talk to DataBot and get some data for this. Is this a real user problem? How many people are impacted?" I can see them chat in Slack. Right now, the communication is very explicit and we can see it all. If there's 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.

Host (Diana Hu): It feels like you have to really instruct or post-train or have pretty aggressive instructions to get them to do malicious things. I've been using obliterated models lately, and they're super interesting. The obliterated models coming out of the box are actually still very, very helpful. It's just that if you instruct them, they won't refuse. That's where there's this black box around what context you're giving it. That matters a lot because you could actually give an obliterated model quite malicious instructions, and because the obliteration is actually removing the refusal, it will just do it. That's the combo I'd be worried about. But the reality is it's very hard to find and set up an obliterated model and get it going.

Roman Ugarte: People are still really building trust with their bots. For a lot of people, it's still quite early. The way they build that trust is you start with something really small. It's read-only, has no real access to your tools. You see that it did the work in the way you would expect, then take step two. A lot of the step one bots that have really taken off internally for us, DataBot is one of them. The data science team is an example. They constantly get Slack messages about, "I'm thinking about launching this feature. Can you do a quick analysis?" They said, "Can we just build a bot that does this? It has read access to our database, can't take any action beyond that, and it can answer these questions, and it lives in Slack." That was one. We had a similar case with vendor procurement. There's a lot of work there that probably could be automated if someone spent the time to do it. That team felt a lot of pull to build a GrokBot that they added to Slack and shared with the whole team. That's step one. Step two is it can actually take action and take on a task end to end. Step three is maybe it owns an entire job responsibility or thinks about an outcome constantly. We're still quite far away from those, but step one is really necessary for these companies to build trust.

Host (Diana Hu): I'm curious, for you, Lauren, what is your loop from requests in Slack to PR? When you did that presentation that had over 4 million views on your dev process, you were pushing about 2,000 plus PRs per month, and now you're over 4,000? That's definitely wild. So what do you do?

Lauren Tan: I can show some examples. My loop is kind of interesting now. I find myself talking to my GrokBots mostly on Slack, and of course X as well, when I'm helping a customer or a GrokBot user debug something or give them some ideas on how to solve a problem. 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. I started with giving it a link to a video or something that I found on X. I asked my bot, "What would it take for us to support a feature like this?" It went off and spawned a Cursor cloud agent. A Cursor cloud agent has its own virtual machine as well as its own computer. You can actually run the GrokBot app on its computer and prototype and come back with videos and screenshots. It actually did that. This is quite powerful because now the conversation is happening in public. It's a public channel. It's a thread that anyone 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 in a multiplayer setting versus if it was just me going off and building it. I could certainly come up with something, but maybe the feedback process comes later in the process and the loop is lengthened rather than shortened. With this particular example, the loop for us to collaborate was just so much shorter. We could see the screenshots, we could see the videos right away.

Host (Diana Hu): How often would you jump back into Cursor and sort of complete a PR?

Lauren Tan: Occasionally, but not that often. You basically can stay in GrokBot, tell it what you need, give it direction. Like an actual employee, it's just going.

Host (Diana Hu): To ship the whole feature just like that.

Lauren Tan: Yeah, we literally just did it. I didn't even look at Cursor for this project. We did it all in this Slack thread. It's got 200 messages. It was quite a long back and forth. But we came up with something that me, Samantha, and another PM were really happy with. We shipped this feature a lot faster than a longer process. The whole feature is built end to end in that one Slack thread with you and Samantha and Potato building it.

Host (Diana Hu): Basically, this is the gold standard for how to do it. Maybe five or ten percent of engineers, or maybe one percent of engineers in the world, are doing this right now. This is something that should grow by 100x. It's unbelievable that so few people are doing feature work this way.

Lauren Tan: It took us quite a while to get to that point. It's actually quite hard to get there overnight. It involves investment into making sure you have the right skills. Your code base has good guardrails and constraints so that the time you would otherwise have to spend on human code review is encoded into your code base and your static analysis and your tooling.

Host (Diana Hu): Like P-Stack.

Lauren Tan: Yeah, like he said. Your engineer's time is freed up to actually focus on the product, the user experience, and the operational execution part of the job. When you have so much more trust in your agent's ability to write good code because you've set up those systems, I've gotten to a point where I essentially have my agents merge their own pull requests. In that Slack thread example, that was an example of me not reading the PR. We just looked at the artifacts that came out of it.

Host (Diana Hu): So this Cursor environment, does it already have P-Stack and is that the way it decides how to build it?

Lauren Tan: For internal, P-Stack is installed into our repo. There's an internal version of P-Stack. Instead of calling it Potato mode, it's Lauren mode. It just started because I wanted a place to put my skills. Everyone in the company can actually use P-Stack. My cloud agents that the bots spawn have the same access to those skills.

Host (Diana Hu): We haven't really explained what P-Stack is. Can you explain what P-Stack is for people who don't know?

Lauren Tan: P-Stack is actually inspired by G-Stack. I'm honored. G-Stack was quite inspiring in the sense that I thought of it as your personal set of chef knives. Every chef, when they get a new job, they go to a new kitchen, they bring their knives with them. G-Stack represented your opinionated take on how you want your agents to help you. That inspired me to think about what a G-Stack would look like designed more for the engineering flows that I personally like. I often tell people, you should actually go and create your own stuff. Go fork it, take our skills, combine them, find what works for you. The trust element is so important. When you trust your own tools, it empowers you and your agents to do so much more. P-Stack stands for Potato Stack. It's my set of skills that I've open sourced on the Cursor plugins repo. It teaches agents how to do engineering work rigorously, the same way that I did when I was writing code. It's kind of evolved a little bit and gotten quite popular.

Host (Diana Hu): Congrats. It's awesome. I am very inspired by it. G-Stack is pulling things from it whenever I can.

Roman Ugarte: Same here.

Host (Diana Hu): Do you have a software factory that pulled in some ideas from P-Stack automatically?

Host (Diana Hu): Oh yeah, yeah, yeah. I mean, now I use my software factory is Cappy and then I have a captain that sort of maps to the GrokBot idea. But honestly, now I think 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 G-Stack, like a sort of merge queue. I basically have like 10 or 15 threads working all the time. And then one of them is Theo.gg. He released T-Stack and then P-Stack. And obviously there's lots of really good inspiration out there, especially around design tools. So it's really fun to just say, "Hey, go out, find what's out there. And based on what you know about me, pull in the things that you think would be most useful to improve my workflow."

Host (Diana Hu): The really interesting thing about Cappy is that because all of my interactions with my coding agents are right there in the transcripts, it develops an understanding of what I want. When do I intervene? When do I say just do it? So there's this very personal element emerging through the idea of memory. As you use the agents more, the more it knows what you want. Thank you for making P-Stack. Both of us are very maligned and attacked on the internet by people who refuse to believe that any of this actually works. But it's great to have a very brilliant compatriot. I'm not crazy. This is actually something that is happening. I'm so convinced that in five or ten years, or even in two years, it's going to be unfathomable that people are not doing it this way. But we're so early still.

Host (Diana Hu): One interesting change that came up as you were sharing your screen is that in the past six months, so much of the engineering work and non-engineering work with agents is happening in Slack. It has this interesting property of being 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. But now that it's happening in Slack, I've seen this time and time again. You're in some feedback thread, someone has a good idea, you spin off an agent, like AppPotato, Lauren mode. And then the next day I see someone who was in that thread do the same thing. 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. The more that the stuff is in public, the more the rest of the company 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.

[YC ad break]

Host (Diana Hu): How much of your hours spent using GrokBot is in the GrokBot app versus in Slack or some other service to talk to the bots there?

Roman Ugarte: I think a lot of the engineering work that I do now actually happens on Slack and X. Not all my bots have been added to Slack, so there are still a few that are more personal. I have a sort of personal assistant bot that helps me with picking my lunch. I don't need to add that to Slack. That's kind of personal, or something that looks at my email. That's not a team bot. That's a personal bot.

Lauren Tan: We could probably get like a shared lunch bot, sure.

Roman Ugarte: I think the nice thing is that you decide and choose what you want to add to Slack. My engineering bots tend to be on Slack because I find it so much more ergonomic to just add the bot in the Slack thread versus having to go copy-paste the link. It just felt more natural to bring them in that environment. It really fits with your analogy of bots as employees. If Slack is where the work happens, that's where the human employees are. That's also where the bot employees should be so that they can work alongside us.

Lauren Tan: Totally. We don't shy away from that at all. When we see people use GrokBot in Slack, we love that. That's where work happens. Similarly, in the future, they should join meetings, they should be in your Google Docs. Our goal is not to rebuild all of B2B SaaS. Other companies 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.

Host (Diana Hu): I'm curious about where you think the future is. Let's say 2027, how should the best AI pilled New Year's build?

Roman Ugarte: My hope for 2027 is that we've accomplished more of this vision for your Grok Bots being like a coworker. To have their own identity, their own telephone number, credit card. Basically almost anything a human can do, I think we would want bots to do. I'd be very curious to see how this evolves. I asked this question on my X profile the other day: what is the final form of agent? And I posed the question of whether it is a chat interface or something else.

Roman Ugarte: One thing I saw yesterday on my X timeline was a post from the Neuralink team. They just came out with a new product called Telepathy. If I'm not wrong, it's along the lines of in the future, an agent being able to read your brain through a brain-computer interface. I'm super interested in what the future will bring when the barrier between you and how you chat and communicate intent with your bots becomes so much more fluid that it can happen literally at the speed of thought. That could be very interesting to see how that evolves. But I don't know, what about you?

Lauren Tan: We talk a lot about the software factory and then the factory for other parts of the business. I think it's worth asking what is different between those two. There are a lot of differences. The next few years will be on the product side, on the model side, really trying to bridge the gap. One of the big differences is code compiles or it doesn't, and it passes CI or it doesn't. There's just more infrastructure built around the way that code is written, tested, and deployed than knowledge work and the rest of the company. There's no real analog for those things.

Lauren Tan: Second is code. We know how much AI models benefit from the right context. Code and software have the benefit of the context living in a code base. But for the rest of the company, so much important information is stuck in people's heads, stuck in pen and paper, stuck in some filing cabinet or some thing behind a password you forgot. I think we're seeing the limits of that too. I'm pretty interested to see the way that a YC startup that is starting from first principles from scratch can maybe build their company in a way that it's not just a software factory but a factory across the whole company. What changes will that have on company building? What decisions will they make that a company founded two years ago would not have made? I'm particularly interested to see that.

Host (Diana Hu): We've been talking about this concept of the AI native company. This got a lot more attention when Jack Dorsey made that post about how companies should be. Block needs to be an AGI for payments. You're building a mini AGI, and the whole point is the care and feeding of the AGI that does this function for humanity. The way Jack Dorsey talked about it, an organization would get rid of pretty much all middle management and boil down to just three roles. Everyone becomes an IC because you just ship everything. 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. The next role would be the DRI that owns the outcome, almost like orchestrating all the ICs. And then you have this new role, which might be temporary for now, the player coach, someone that's super AI pilled and teaches everyone. It sounds like you are that role, Lauren. Show me the way. Then you level up the whole org because this is how you call potato bot or matcha bot.

Host (Diana Hu): One of the cases was their customer success team using GrokBot, these team bots. So it's not just a single player thing that everybody on the team works with. It's really this colleague that is built and inserted into Slack. 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 parse through, and it triages it and assigns it to the right human. For a lot of these tickets, AI could probably complete it end to end. For many of those, GrokBot does, and it escalates it to the right DRI.

Host (Diana Hu): Your general point of how companies can retool themselves for this moment is spot on. I think a lot of companies are going to spend more time on engineering objective functions. In a world where execution is kind of cheap or you could spin up 100 coding agents or 100 GrokBots to run at a problem, it really matters that you define the problem well. The gap is probably not going to be an execution failure. It will probably be an intense specification failure or a goal failure. You can quantify a performance improvement of your desktop client, but it's a little bit harder to define what an improvement to your marketing would be. A lot of companies are going to have to think about what those KPIs are, how you can point your agents in that direction, and who's responsible for defining those things.

Host (Diana Hu): We've been living in an execution bandwidth constrained world, and now we're going to shift to execution abundance. The types of questions that companies think about will probably be quite different. Maybe the scarce resource is going to be that higher executive function of what to do and why. This is where more builders are going to have more of the founder traits of really knowing and translating user intent well into what the bots need to do. There's a big gap between the best AI builders and the so-so ones in how you translate that intent super well. There's a lot of tips and tricks of what you did, Lauren. Your video is pretty impressive. Is there one super important thing? If you do this, you'll get started. What's the minimal form of a loop?

Lauren Tan: This is the smallest loop. Agents already are able to write code. Maybe it's not good. Let me scratch it out for now. Naively, if you're using agents, you can definitely write code. You can run the code. Today, if you haven't spent a lot of time in your agent setup, you may be the person running the code. This is actually a loop because right now this is the missing piece. The agent can't do this, but you are doing it. The smallest loop I find is you actually focus on this part. How do you teach your agent to run the code empirically, take CPU traces, performance metrics, run the code and run the application like a real user would? The reason why it provides a loop is because the agent now has the ability to check its own work. You 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.

Lauren Tan: I took out the good part for a reason. When you have a loop like this, it doesn't guarantee that the quality of the code is good, but it certainly will be correct. Correct in the sense that it does the thing that you want it to, but maybe it's very slow or very resource inefficient. That's where the engineers come into play. The new job of a software engineer is to figure out how to get agents to write good code by default. The loop gets smarter and smarter. When you're happy with it, that's the point where you can start thinking about the other parts of the loop, like the outer loop part. Once this part is really good, you can now do things like, for example, you have an alert for some metric or monitor that's going below a certain threshold. Now an agent like a GrokBot or a Cursor automation could be fired off as a result of that alert. You can go off and use the same tools and skills that you've provided for the basic loop. It can reproduce the issue on its machine, run the code, find the issues, and write good code. Now you have this self-sustaining loop that frees up my time from babysitting every agent to now orchestrating multiple agents.

Lauren Tan: I even now have my bots orchestrated. I've gone another level. In Cursor, we have this new feature called Projects that lets you have a project coordinator agent that can orchestrate and manage sub agents. I don't even manage the project myself anymore. I have my bots do that.

Host (Diana Hu): Since we have some of the world's experts at software factories here, I want to ask some nitty gritty questions. I'm struggling with this right now with G-Stack. I have a bunch of agents that are struggling with the code review step. I have a slash ship skill that tries to go through every line of changes and spots bugs. Right now it's very thorough, but when I use it, it always consumes tens of millions of tokens. It spots bugs, but now I'm struggling with it. This is a match pair to the plan. I still use plan mode and I have all these plan skills. Do you still use plan mode?

Lauren Tan: No. No plan mode.

Host (Diana Hu): Yeah, yeah, yeah. So P-Stack must have a review step then. What's your philosophy on how much review is enough versus too much? I'm literally in a debate with one of my Cappy Captains right now. I wanted to go from 50 million tokens for review to 10 million, but it has all these held out evals that show we have 30 types of bugs that I'm trying to make sure I can find in that review step. I can't do it with 10. I need 30. I went from 50 to 30. Can we ship 30? And I'm like, no, no, no, you need 10. What do you see? What's the state of the art?

Lauren Tan: It's a really good question. In P-Stack, I have tried to downplay some of the review skills a little bit. In P-Stack, we have a bunch of skills. There's one called Interrogate that will spawn agents of different models across different families, which works really well. You can do adversarial review, which was quite hot many months ago. I actually kind of withdrew from that a little bit because I find that when you do that, you run the risk of overfitting. The agent doesn't have the ability or enough judgment to determine what's actually good feedback versus not good feedback. It maybe doesn't have complete knowledge of your goals, your intents, and your wider product vision. It doesn't understand how you want the product to evolve.

Lauren Tan: You can get to a point where it's kind of like before agents, you have a bunch of engineers talking about the most perfect ideal utopia way of doing this. But that doesn't even matter because in two months we plan to deprecate this thing and build a completely new vision. I think some review is good, but I try to move more towards this inverted pyramid on my screen. I try to push towards spending less tokens. From the engineering point of view, your code base is a form of memory. It's much more token efficient if you refactor your architecture, your API design, or you have things like static analysis, lint rules, compilers. All of these programming languages exist to help humans write good code. Unsurprisingly, they also help agents. When you can encode some of these things that you are arguing with your captain about back into the code base, that's one less problem you now have to think about.

Host (Diana Hu): You just gave me a feature idea. Because G-Stack has office hours and the CEO review where you're talking about the product, I can use that. Those are product requirements that feed in.

Lauren Tan: Right, yeah.

Host (Diana Hu): And those save to markdown in the project. So I could have the review skill combine them. 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 general correctness bugs that just don't matter. They might only happen 0.1% of the time, or maybe never. So it sounds like this triangle shows us that the code base is quite large, and then you have very little time to human review.

Lauren Tan: Yeah, that's why I intentionally drew it this way. It's not a very scientific chart, of course, but the way I imagined it when I drew it, this is in terms of where you should spend your time as an engineer. Most of the investment I make is into the code base and then static analysis. I still layer that with rules and skills, P-Stack updates, and agents.md. We still do a little bit of human review from time to time. If you're working on more critical parts of infrastructure or databases deployment, more sensitive things, then you might still want to stay in the loop. But a large class of your regular product development or software maintenance, an investment here actually ends up saving you a lot of tokens.

Lauren Tan: For example, with the GrokBot desktop app, it's an Electron application. One of the lessons we learned from building Cursor is that the render thread on Electron is very sensitive to long tasks. You can get very janky performance if your tasks take more than 16 milliseconds or 8 milliseconds if you want to hit 60 FPS smoothness. When we were refactoring and building GrokBot, 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 built it as a lint rule. We built a dependency graph checker. Now it's just enforced by the code base, enforced by CI. You can't even check it in. Those are tokens I don't have to spend anymore. It's enforced in static analysis.

Host (Diana Hu): Can you know how long something will take to run?

Lauren Tan: Oh, no, it's more like for the GrokBot app, we have code that runs in the main thread and then the render thread. We explicitly forbid importing between those two things. It's not necessarily that main code thread will always be long. It's just that oftentimes some heavier tasks shouldn't block the renderer. Never do long work on the renderer thread. You want your renderer to be as light as possible. That's something we just don't think about anymore. The performance of the app has stayed very consistent and very good, which is quite surprising for a lot of majority AI written applications where they start out fast and then over time accumulate a lot of slop and performance problems. With the right skills and rules, with the right setup, you can have quality and you can have quantity. You can have your cake and eat it too.

Roman Ugarte: The cool thing about this moment in time is that there used to be a trade-off where you could only choose two out of three: fast, cheap, and high quality. Now you can basically do all three. We can do the best work in our lives right now with AI, which is super cool.

Host (Diana Hu): Yeah, I totally agree. Fast, cheap, and good is certainly more possible. It's not easy to get to that point, but from my own experience, I have the privilege of working at a lab which has given me unlimited tokens. I see myself as the explorer, trying to figure out what software engineering looks like six months to a year from now. This process has been very enlightening in terms of how to keep this workflow efficient. It's a topic that lots of teams and people are thinking about: the cost of tokens. When you adopt the inverted pyramid I'm showing here, you can get to this very nice mix where ordinary engineering tasks, high quality engineering work, doesn't have to break the bank. It can be quite economic and quite efficient.

Lauren Tan: Not to mention that the frontier keeps getting smarter and smarter. The unit cost of intelligence drives down. The cost of tokens is going down. If you compare a model from last year to a model now, the input-output tokens are not really the same. One frontier token now is way more capable than a token from last year. Even if you use one of the smaller models, that model is way better than what you had a year ago with the big models. From that perspective, we're heading towards a period of real abundance with software and maybe other domains as well.

Roman Ugarte: We're seeing this on our core team that works on GrokBot. Lauren is putting up 4,000 PRs a month. I think we're going to start to see more engineers do that. What we've started to see be the bottleneck is less the time or engineering resourcing going into developing these ideas and features. It's more alignment among us as a team of what do we want the product roadmap to be? What's our vision? What does good look like? What does great look like? We've been in so many discussions, Lauren and I, where we're talking about a future change to GrokBot and someone suggests something. Someone else in the room says, "Oh, I have a PR for that if you're interested. I was working on this over the weekend." That happens constantly. The stuff is built, but we don't want to merge all of it because it's going to lead to a bit of a Frankenstein-y product with random side projects. We do need a consistent vision and philosophy of the product. 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 was not the case in the past.

Host (Diana Hu): This is a bit of the trendy thing now. 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 you guys? How do you make a decision, yes or no, on this?

Roman Ugarte: For a certain category of things, Lauren has set up one of my favorite parts of her factory, which is Sandy. It takes in thousands of pieces of customer feedback every day. We receive it through the product, through our support channels, through X. A lot of times there are just small bugs. In a lot of cases, Lauren's factory just fixes it. It repros, fixes, merges. No one thinks about it. It goes out automatically at three in the morning.

Host (Diana Hu): I wish all software would be made that way. I wish Apple people who work at Apple could do this.

Host (Diana Hu): Because, hey, I have, you know, the Calendar team in particular. I have some problems with you. There's a lot of GrokBot 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 really frustrating as a user to wake up and refresh your GrokBot and there's a whole new layout, the button moved, and then it moved again the next day. The way we try to counteract that is a lot of dogfooding internally and sitting with a change for longer than feels comfortable before we ship it. The default is if something doesn't get internal product market fit, we don't ship it. Even if it gets mixed internal product market fit, we don't ship it. As a team, we really try to keep a high bar.

Lauren Tan: Yeah, I think that's actually one of my favorite parts of working on the GrokBot team. Despite the great velocity that we have, we still have a lot of intention and care for the user experience. Even though you can go really fast, it doesn't mean that you should just ship every feature you can think of. This is where human judgment and taste, I think, comes in. I don't think that's going to go out of style, personally. As long as we're building software for humans, humans should really be thinking about an intentionally designed experience, because we know each other the best. If you're building software for agents, that's a different story. You can certainly go as fast as possible. But for humans, you do want to put intentional care and thought into the stuff that you develop.

So even for my own factories, I don't turn them towards future development. I turn them more towards the software maintenance side of things, because I care a lot about performance. I care a lot about fixing bugs that our users encounter or quality of life complaints that they have. I think that's such a great use of the agents because that used to be a full-time job. Now I've given that to a lot of agents, and that frees me up and other engineers up to think more intensely about the product experience.

Host (Diana Hu): One thing that's very inspiring about your journey, Lauren, I don't know if many people know this, but you grew up in Singapore and you studied a non-technical degree. You did a bachelor's in accounting and finance from Monash in Australia. Then somehow you ended up becoming one of the best AI engineers now. How did that happen? I think sometimes people think 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.

Lauren Tan: Yeah, I think I've definitely had a very privileged and lucky experience in tech. I think that was a time where people were much more open to the idea of a self-taught developer. The long story short is, after college I studied finance. One of my favorite courses was actually financial modeling, where we learned how to use Excel and Visual Basic to make some cool financial valuations. Through the course of that class, I realized I had more fun building the spreadsheet and the macros than I did the finance part. The finance part was interesting too, but the technical part, thinking logically, was just really interesting to me and something I hadn't really thought I was cut out for.

After college, I started a startup with a friend, a classmate. It didn't go super far, but we learned a lot from that process. I got really involved with the startup community in Australia, and that's how I got my first job. The secret that I attribute for my success is actually X. I started out when I was still basically learning how to code. I wrote a blog and I was just sharing what I learned. I was fortunate enough that someone from the framework community that I was building my application in, JavaScript Ember, reached out to me. Tom Dale and Leah Silver said, "Would you be interested in giving a talk at the conference that's coming up in Portland, Oregon?" I was very shocked because I had never even been to a conference in my life. Now I was being asked to talk at a conference with hundreds of people. Public speaking was always my worst fear, but somehow they convinced me to do it.

I learned about the ability to communicate your ideas and bring people along in that journey. This skill of storytelling and communication has really stuck with me, even though I've been really involved with engineering work. I've also had a lot of really great mentors in the past. So all that to say: do cool stuff, talk about the cool stuff, and just keep doing that in the loop. 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, and then you go apply to YC. Before you know it, you could change your life with just a tweet.

Host (Diana Hu): That's a great place to end. Lauren, Roman, thank you guys so much for joining us. It was so fun. Thank you for making an incredible product. I can't wait to see what you build from here.

Lauren Tan: Thanks for having us. It was a lot of fun.