# GrokBot: AI Teammates and the New Software Factory

**Podcast:** Y Combinator Startup Podcast
**Published:** 2026-11-14

## Transcript

GrokBot 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 does software engineering look like six 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 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.
Thanks for having us.
Thanks so much for having us.
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?
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.
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 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.
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 have these goals that they run at for long amounts of time.
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 would be too much to expect these bots to actually contribute to a company without having their own computer, for example.
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.
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 it 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 GrokBot.
It just kind of clicked and 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 GrokBot, 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 has been really exciting to see.
There's still a lot more work to do, and I think it's quite early, but that's a lot of how GrokBot came to be.
What are some of the use cases that you're seeing?
Like who's using GrokBot, and are there 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 GrokBot personally and maybe use it to do some basic task.
They realize, wow, GrokBot is pretty good at this thing.
I'm going to trust my bot with more.
I'm going to give it access to more 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 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 logins, 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 A-B test a bunch of them.
So that's one example in marketing.
Our support team, I think it started 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 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?
For me, definitely, I use GrokBot a lot for my engineering work.
I think where...
it sort of made a big difference for me outside of, you know, the tools that we had before.
Like I use Cursor a lot, is the fact that GrokBot forms my, I don't know if there's a good term for it.
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 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 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 GraphBot 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.
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 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-worker in the Slack chat, a thread, or even on X now, you can tag bot and it feels so natural that it's really boosted my productivity a lot.
Do you have personal bots that know, I mean, they're in 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?
I think for me, the beauty of GrokBot is that you can create all these different bots, but how you split them up or how you set them up is very much up to you.
What I like to tell people is you can set up your bots in a way that makes sense for your brain.
So if you are the kind of person who likes to, you know, compartmentalize like different pieces of buckets of work, then you can set up your bots that way.
You can have like specialist bots.
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 an 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 horizontally.
So I don't have a ton of bots, but I do have some specialists.
That was like 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 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 crons with web hooks on top of skill files, right?
And then this actually maps inside this world of having AI employees a lot better.
Because you were saying earlier you guys had just talked to all of, you know, some of your top users of GrokBot.
And then surprisingly, or maybe unsurprisingly, some of the first ones that are most...
just like kind of crazy about it.
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 GrokBot.
And actually within the course of probably hours, you know, 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.
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 bots, but each of them care.
about a different thing and come to me proactively with what they're picking up on.
And so I think to your point, as these bots really enter businesses and enter the workforce in kind of a somewhat futuristic way, I think that's why small businesses 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 omniscient or just like kind of single approach to every problem.
And you support that now, actually.
um like 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 is recent but about two weeks ago uh 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 um 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 their peers and kind of the company.
I guess one thing that brings to mind is basically went through, maybe it was...
A year ago-ish, when Steve Yege posted the whole Gas City post that then started- Software factories.
Software factories.
Gas Town or something?
Gas Town, right.
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 functions that are non-tech.
So you're mentioning your- customer support person, your communities person.
Let's talk about this pattern.
It's an everything factory.
Yeah, let's talk about that.
What is this AI employee, 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 GropBot is that it's given that ability to anyone.
And then here on my screen, I have an example from our GrokBot 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 deals that they might be interested in.
And then going all forth and...
taking some of the 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 quote bot or deal bot.
We have a shared, 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 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, the skills that we've developed and use them and everybody benefits from these team bots.
There's this new concept that is actually very powerful.
It's like, it's not a mistake that OpenAI 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 Navier 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's, you know, using these bots, it's like feels very different.
And there are so many.
unsolved problems still in making bots multiplayer, just making AI multiplayer in general.
I mean, we face this on a constant basis where now that GrokBots have entered 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, you're going back and forth with your coworkers, 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.
Just the models weren't trained that way.
The harness wasn't built that way.
And so I think 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 really interesting next few years.
I mean, it could probably look at who the owner is in its metadata and say, well, I know that Lauren's the one I need to listen to.
Run everything by Lauren or something like that.
We do have the concept of 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, authentication, authorization.
There's still a lot to do in terms of exactly what you're pointing at.
How do you think of that?
How do you think of permission and auth and access?
How does GrokBot do it?
I think this is an industry-wide question.
I don't think anyone has the silver bullet answer yet.
I think 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?
And 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 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.
This is what we did with Quartermaster.
This is the YC project that we open sourced.
It's a bit kind of rockbot-ish.
And the permissions that it gets per Slack channel or working with someone, it inherits 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 that 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?
They can talk to each other.
I mean, in the GrokBot application, both desktop and mobile, you can see their chat.
So we have 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 looked and 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 was quite funny.
It's very mean.
Not mean, but, you know, it was like kind of a disciplinarian.
I find it very powerful.
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 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.
There's Maltbook internally at YC.
It's Maltbook internally at YC.
And kind of like Maltbook, 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 or something like that.
Do you ever worry about that?
I think that's like a, like, you know, like the safety 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 seen anything like that.
They're so helpful.
They're so kind and helpful these days.
Where we tend to, for me at least, have these bots chat with each other is through Slack.
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 a specialist at getting data from our data warehouse and things like that.
And then I have my own personal engineer bot called Potato, of course.
And then sometimes I'll just be in a thread and I'll ask Potato, hey, look into this and talk to a data bot and get some data for this.
Is this a real user problem?
How many people are impacted?
Oh, that's so useful.
And then I can see them chat in Slack.
So I think right now, at least, the communication is very explicit.
We can see it all.
So I think if 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.
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, they're actually still very, very helpful.
It's just that if you instruct them, they won't refuse.
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 obliteration is actually removing the refusal, like, 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 um and set up an obliterated model and get it going 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 in a lot of the way that they build that trust as you start with something really small, it's read only, you know, has no, no real access to your tools.
You see that 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.
Databot 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.
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?
It 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 GrokBot 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 it 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.
I'm curious, what is the, for you, Lauren, what is your loop from requests in Slack to PR?
I think when you did the 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 like over 4,000?
Yeah.
Wow, definitely is wild.
So what do you do?
I can show some examples.
My loop is kind of interesting now, where I actually 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.
And basically, I kind of started with saying, I gave it a link to a video or something that I found on X.
And I asked my bot, 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 has its own virtual machine as well as its own computer.
So it can actually run the GrokBot app on its computer and prototype and come back with videos and screenshots.
And then it actually did.
Wow.
This is quite powerful because now, you know, 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, 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 feedback process, it comes later in the process, and the loop is sort of lengthened rather than shortened.
And here I felt like 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.
How often would you jump back into Cursor and sort of complete a PR?
Occasionally, I think.
So not that often.
I mean, you basically can stay in GropBot, 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 reason we can sort of do this, you know, workflow.
To ship the whole feature just like that.
Yeah, we literally just like, I didn't even look at cursor for this project.
I just, we did it all in this Slack thread.
It's got 200 messages.
So it was quite a long, a lot of back and forth.
But we came up with something that, you know, me, Samantha, and another PM were really, like, happy with the result.
We should ship this feature a lot faster than, you know, a longer process.
And so the whole feature is built end-to-end in that one Slack thread with you and Samantha and Potato building it.
Yeah.
I mean, basically, like, this is the gold standard for how to do it.
And then I would say...
maybe like 5% 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 just unbelievable that so few people are doing feature work this way.
Yeah, I'll say 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 investment into making sure you have the right skills.
Your code base has good guardrails and constraints so that the time that you would otherwise have to spend on human code review is encoded into your code base and your static analysis and your tooling.
Like P-Stack.
Yeah, like P-Stack.
And so your engineer's time is freed up to actually...
focus on the actual 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.
So 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.
So this cursor environment, does it already have Pstack?
And is that the way it sort of creates, decides how to build it?
Yeah.
So for internal, Pstack is installed into our repo.
There's an internal version of Pstack.
Instead of calling it potato mode, it's Lauren mode.
And it just started because I wanted a place to put my skills.
And so, yeah, everyone in the company can actually use PSAC.
And my cloud agents that the bots spawn have the same access to those skills.
We haven't really explained what PSAC is.
Can you explain what PSAC is for people who don't know?
PSAC is actually inspired by GSTAC.
Oh, thank you so much.
I'm honored.
You know, I think, Gary, your, you know, GSTAC was like...
quite inspiring in the sense of, I thought of it as like your personal set of, you know, chef knives.
Oh, yeah.
Right.
Like, you know, every chef, 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 to think about, you know, like what would a G-Stack look like for, you know, design more for like the engineering flows that I personally like.
So I often tell people like you should actually go and create your own stuff.
Yeah, go fork it, you know, take our skills, combine them, you know, find what works for you.
But I think the trust element is so important.
Like when you trust, you know, your own tools empowers you and your agents to do so much more.
I didn't really answer the question.
Oh, no.
But PSTACK, yeah, it 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.
Congrats.
Yeah, it's awesome.
Yeah, I am very inspired by it.
And GStack is like pulling things from it whenever I can.
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...
GrokBot, the bot 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 sort of merge queue.
Like I basically have like 10 or 15 threads working all the time.
And then one of them is like Theo.gg, he released T-Stack and then P-Stack.
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.
And then the really interesting thing about Cappy is because all of my interactions with my 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 sort of this very personal element that's emerging really through the idea of memory.
And so as you use the agents more, the more it knows what you want.
thank you for making P-Stack.
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 compatriot.
I'm not crazy.
Like, this is actually something that is happening.
And honestly, like, I'm so convinced that in five 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.
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 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 AppPotato, 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 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.
YC's next batch is now taking applications.
Got a startup in you?
Apply at ycombinator.com slash apply.
It's never too early, and filling out the app will level up your idea.
Okay, back to the video.
How much of your hours spent using GrokBot is in the GrokBot app versus in Slack or some other service 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 are more personal.
I have, I guess, 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 not a team bot.
That's a personal bot.
We could probably get a shared lunch bot, sure.
I think that the nice thing as well is you decide and choose what you want to add to Slack.
So my engineering bots tend to be on Slack.
uh 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 just felt more natural to bring them in that environment 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 Grockbot in Slack, we love that.
I think 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.
Our goal is not to...
rebuild all of B2B SaaS.
You know, like 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.
I guess one thing that I'm curious about is where do you think the future, let's say 2027, how should the best AI build engineers build?
So my hope for 2027, I think it's like much more, you know, like we've...
maybe accomplish more of this vision that we have for your grot bots being like a co-worker.
You know, 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.
And I'd be very curious to see like how this evolves.
You know, I asked this question on my X profile the other day as well, of like, what is the final form of agent UI?
And I posed the question of like, is it a chat interface or is it something else?
One thing actually pretty interesting that I saw yesterday on my X timeline is a post from the Neuralink team.
And just came out with this new product called Telepathy that I think, if I'm not wrong, is along the lines of in the future, an agent being able to essentially like read your brain, your mind through like, you know, a brain computer interface.
And I'm super interested in what the future will bring when the sort of barrier between you and how you chat and communicate intent with your bots becomes so much more fluid.
That can happen 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.
We know how much AI models benefit from the right context.
And code and software has 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.
It's stuck in pen and paper.
It's stuck in some filing cabinet or some thing behind a password that you forgot, whatever.
And I think we're seeing the limits of that too.
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 it's not just a software factory, but it's 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 made the same decision or trade-offs?
So I'm particularly interested to see that.
We've been talking a bit about this concept of the...
Yeah, a 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 an AGI for payments.
Right.
It's like 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 way Jack Dorsey talked about it is like in an organization, we'll 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.
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 DRI that owns the outcome.
It's almost like orchestrating all the ICs.
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 pilled 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.
called potato bot or matcha bot, right?
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.
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 parse through and triages it, assigns it to the right.
human.
I think for a lot of these tickets, AI could probably complete it end to end.
And so for many of those, Grockbot does, and it escalates it to the right DRI.
But I think your general point of how companies can retool themselves for this moment, I think you're spot on that.
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 grokbots to like run at a 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.
And how do you quantify these things?
I think you can quantify a performance improvement of your desktop client.
But I think it's a little bit harder to maybe define what an improvement to 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 execution abundance.
And the types of questions that companies think about will probably be quite different.
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 of the founder traits of really knowing, translating user intent well into what.
the bots need to do.
Because I think that there's a big gap between the best AI builders to the so-so ones is really how 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 super important...
just like, if you do this, you'll get started?
Like, I think, was it like, 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 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 is an actually a loop.
really, because right now this is the missing piece.
The agent can't do this, but you are doing it.
So the smallest loop I find is you actually focus on this part.
How do you teach your agent to run the code empirically?
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 we 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 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.
It's like the new job of a software engineer is to figure out how to get this to happen.
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 the other parts of the loop, like the outer loop part, where 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 going below a certain threshold.
Now an agent like a GroffBot, a cursor automation could...
be fired off as a result of that alert.
And then you 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 and it's on machine.
And then, you know, like it runs the code and then it finds the issues of 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 orchestrated.
I've gone another level where I, you know, in Kirsten, 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.
So 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 No.
No plan mode.
Yeah.
So then, but PSTAC 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 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.
What do you see?
Like, I mean, what's the state of the art?
It's a really good question.
I think, so for me, actually, in P-Stack, I have tried to downplay some of the review skills a little bit.
You know, in P-Stack, 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 like adversarial review.
That was like quite hot 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 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 kind of like imagine before agents, you have a bunch of engineers talking about the most.
perfect ideal utopia way of doing this.
But actually, you know, that doesn't even matter because in two months, we plan to deprecate this thing and build a completely new vision.
Right.
And so I think there's some similar analogy there where I think some review is good, but I try to move more towards like on my screen here, I have this inverted pyramid where, you know, like I try to push, like you mentioned, you know, spending less tokens.
And so from the engineering point of view, I like to think of this as your code base is a form of memory.
And so it's much more token efficient if you refactor your architecture, your API design, or you have things like static analysis, lit rules, compilers, all of these languages, programming languages.
These all exist to help.
In the past, humans write good code.
And unsurprisingly, they also help agents.
And so when you can encode some of these things that you are arguing with your captain about back into the code base, that's just like one less problem you now have to think about.
You just gave me a feature idea, which is like because G-Stack 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.
Right, yeah.
And those saved a markdown in the project.
So I could have the review skill.
You could combine them, yeah.
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 0.1% of the time or maybe never.
So it sounds like this triangle shows us that, you know, the code base is quite large and then like you have very little time.
Yeah, I think that's why I intentionally drew it this way.
I guess it's not a very scientific chart, of course, but the way I imagined it when I drew it, I think this is in terms of where you should spend your time as an engineer.
So for me, most of the investment I make is into the code base and then static analysis.
And I still layer that with rules and skills, P-stack updates.
agents.md.
And we still do kind of like a little bit of human view 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 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 software maintenance, like an investment here actually ends up saving you a lot of tokens.
Because, like, for example, you know, with the GrafBot desktop app, it's an Electron application.
And one of the lessons we learned from building Cursor is that the render thread on Electron is very sensitive to long tasks.
Yeah, so 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 60 FPS.
smoothness.
We literally just built that when we were refactoring and building Rothbot.
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 code base, enforced by CI.
So it's tokens I don't have to spend anymore.
It's somehow enforced in static analysis?
Actually, like, can know how long something will take to run?
Oh, no, it's more like, so for the GraphBot app, we have code that runs in the main thread and then the render 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.
It's just like oftentimes, you know, some like heavier tasks that shouldn't, you know, block the renderer.
Never do long work on the renderer thread, man.
Yeah, you want your renderer to be as light as possible, you know.
So yeah, that's something 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.
But with the right skills and rules.
With the right setup, I think you can actually, you can have quality and you can have quantity.
I think you can have your cake and eat it too.
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 can basically do all three and we could basically do the best work in our lives right now with AI, which is super cool.
Yeah, I totally agree.
I think, yeah, I think fast, cheap and good is certainly more possible.
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 which has given me unlimited tokens.
So I think I sort of see myself as the explorer, trying to figure out what does software engineering look like six months to a year from now?
And I think this process has been very enlightening for me in terms of how to actually keep this workflow efficient.
Because I think it's a topic that lots of teams and...
people are thinking about is the cost of tokens.
And I think when you adopt, you know, like the inverse pyramid like I'm showing here, I think you can actually get to this 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 unit cost of intelligence.
The cost of tokens going down.
Like if you compare a model from last year to a model now, like the input-output tokens is not really the same.
Like 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 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 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 GrokBot.
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?
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 GrokBot 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 or 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 Frankenstein-y product with random side projects.
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.
Which, actually, I'm very curious.
I mean, 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 you guys?
How do you make a decision, yes or no, on this?
Yeah.
For a certain category of things.
So Lauren has set up 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, Lauren's factory just fixes it.
Like repros, fixes, merges.
No one thinks about it.
It goes out automatically at three 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...
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 like really frustrating as a user to wake up and you refresh your GrokBot and there's a whole new, the button moved and then it moved again the next day.
And so 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.
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.
Yeah, I think that's actually one of my favorite parts of working on the GraphPod team is that, you know, despite 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 because we know each other the best, right?
You know, if you're building software for agents, that's a different story that, you know, you can certainly...
Probably go 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 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.
And I think that's actually such a great use of the agents because that used to be like a full-time job.
And 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.
One thing that's very inspiring about your journey, Lauren, I don't know if many people know, is you grew up in Singapore and you studied a non-technical degree.
You did a bachelor's in accounting and finance for Monash in Australia.
Then somehow you ended up becoming one of the now best AI engineers.
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.
Yeah, I think I definitely feel like I've had a very privileged and lucky experience in the tech.
I think that was a time where people were much more open to the idea of a self-taught developer.
So I guess the long story short is, you know, after college, 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 course, I realized I had more fun building the spreadsheet and the macros than I did the finance part.
I mean, the finance part was interesting too.
But the technical part, you know, thinking logically just was really...
interesting to me and something I hadn't really thought I was cut out for.
So after college, 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.
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 framework community that I was building my application in, the JavaScript framework, Ember.
So yeah, Tom Dale and Leah Silber, they reached out to me and said, would you be interested in giving a talk at the conference that's coming up in Portland?
Oregon, and I was very shocked because I had never even been to a conference in my life.
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 in that journey.
And this skill of storytelling and 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, 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 that's a great place to end yeah 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