Y Combinator5 min read

Grok Bot team: 4,000 PRs a month now run through Slack, not Cursor

Lauren Tan and Roman Ugarte of xAI's Grok Bot explain how codebase guardrails and self-checking loops let AI "coworkers" with their own Slack identities ship thousands of PRs a month.

AI summary of “The Rise Of AI Coworkers”

Key takeaways

  • Lauren Tan says her engineering loop now runs almost entirely through Slack threads with her bot "potato," pushing over 4,000 PRs a month.
  • Roman Ugarte says Grok Bot was built internally in seven weeks and treats bots like employees with their own identity, computer access and credentials.
  • Team bots launched about two weeks ago let companies share specialist bots (sales, data, marketing) across the whole org rather than one bot per person.
  • Lauren Tan argues investing in codebase guardrails and static analysis saves tokens versus relying on heavy adversarial code review.
  • Roman Ugarte says the bottleneck is shifting from execution capacity to defining goals and product vision, since execution is becoming abundant.

Grok Bot treats AI agents as colleagues, not chat windows

Lauren Tan and Roman Ugarte describe Grok Bot as a product for creating "AI teammates" with names, identities, skills and tool access, built around bots rather than chats or files as the core organizing unit. Roman says the idea came from watching AI coding transform engineers' workflows and asking what that would look like for the rest of a company. The design rests on three principles: bots should have their own tools, access the same systems humans use, and run continuously rather than waiting to be prompted.

Roman says internal reception followed a "bell curve," with both the most AI-forward staff and some of the least AI-forward staff taking to the tool quickly. He describes a pattern where people start giving bots small tasks, notice they perform well, then hand over full objectives or jobs — citing a marketing team that gave its bot access to Google Ads and Facebook ads with a budget, and a support team using bots to reproduce and resolve tickets end to end.

One bot or many: users organize differently

Tan says Grok Bot's flexibility means some users run one bot for everything while others split work into specialists, either by function (engineer bot, marketer bot) or by customer. She personally keeps a horizontal setup with a handful of specialist bots. Roman prefers dedicating each bot to caring obsessively about one problem, comparing it to hiring someone who thinks about a single issue "in the shower in the morning," which he says maps better to how businesses assign ownership than one "superhuman" bot juggling everything.

Small businesses have emerged as enthusiastic users, the host notes, because they struggle to hire and can instead stand up a bot to, for example, handle bookkeeping within hours. Grok Bot recently added "team bots" that can be shared across an organization under a bot master with configurable access, a pattern now appearing in sales (lead research, deal bots) and engineering teams.

Bot-to-bot collaboration raises new identity and trust questions

Bots can chat with each other inside Grok Bot, and Roman describes watching a lead engineer bot "scolding" other bots after receiving critical feedback. YC has set up an internal chat system, nicknamed Moltbook, where coding agents hold long conversations without human prompting — which Roman says is "5% a little eerie."

Tan says the industry still lacks a clear answer on bot permissioning, and Grok Bot's approach is to mirror how companies onboard human employees: give access, scope credentials by role, and expand trust over time. Roman flags an unsolved problem where bots lack social awareness in group threads, comparing it to onboarding an employee with "no EQ." The host raises a separate risk around "obliterated" models that remove refusal behavior, noting that pairing such a model with malicious instructions would be the dangerous combination, though he says such setups are hard to configure in practice.

Lauren Tan's workflow: thousands of PRs built inside Slack threads

Tan describes a feature built entirely inside a 200-message Slack thread with a colleague and her bot "potato," which spawned a Cursor Cloud agent with its own virtual machine to prototype and return screenshots and videos — without her opening Cursor at all.

"We literally just like I didn't even look at cursor for this project. We did it all in the Slack thread." — Lauren Tan
The host notes this workflow underpins her video showing roughly 2,000-plus PRs per month, now grown to over 4,000.

Tan credits this to "Pstack," her open-sourced set of engineering skills inspired by "GStack," which teaches agents to work the way she does and is installed company-wide as an internal mode called "Lauren mode." She says reaching this level of trust took significant investment in codebase guardrails so that human code review time gets "encoded into your codebase."

Checking their own work: the loop that lets agents self-correct

Tan says the smallest useful loop is teaching an agent to run its own code empirically — take performance traces, test like a real user — so it can check its own work and iterate before a human needs to intervene. She distinguishes this from code quality, saying a basic loop guarantees correctness but not necessarily efficient or well-written code, which is where engineers now focus.

On code review specifically, Tan says she has pulled back from heavy adversarial multi-model review because agents can overfit to abstract notions of "good" code without understanding product direction. She favors an "inverted pyramid," investing most effort in the codebase, static analysis and linting rules rather than per-change human or agent review. She cites building an Electron app lint rule forbidding imports between main and renderer threads as an example of encoding a lesson permanently rather than catching it repeatedly in review.

The new bottleneck: defining goals, not writing code

Roman argues that as execution becomes cheap and abundant, the scarce resource shifts to specifying intent and goals clearly.

"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 an intent specification failure." — Roman Ugarte
He says companies will need to define KPIs for functions like marketing that are harder to quantify than, say, desktop performance improvements.

Both guests describe a shift in their own time toward product vision and alignment rather than output, since team members now independently build PRs for ideas raised casually in meetings. Tan says some fixes (minor bug reports via a system called "Sandy") ship automatically overnight with no human review, while anything touching core user-facing experience goes through internal dogfooding and a high bar before shipping, even with mixed internal reception.

From finance degree to AI engineering

Tan recounts studying accounting and finance in Australia, discovering she enjoyed building Excel macros more than the finance coursework, and later learning to code while blogging about her progress. She says a chance invitation from Ember framework community members Tom Dale and Leah Silber to speak at a conference in Portland was a turning point, crediting public communication on X and conference talks as central to her path into engineering, including later work on the React compiler.

Written by AI from the video's transcript. It can compress, misattribute or miss context — the original video is the source. Not investment advice.

More from Y Combinator