YC's Grok Bot team: AI teammates now file 4,000 PRs a month

Grok Bot turns AI agents into named coworkers with their own tools

Lauren Tan and Roman Ugarte, who took Grok Bot from first line of code to launch in seven weeks, describe it as a product for creating AI teammates with "their own identity, their own telephone number, credit card, like basically almost anything a human can do." Roman explains the design rested on three principles: organizing work around bots rather than chats or files, giving bots access to the same tools humans use, and keeping them always on rather than waiting to be prompted.

Internal reception was a "bell curve," with both the most AI-forward staff and some of the least AI-forward employees responding well. Roman says usage tends to escalate: people start with small tasks, build trust, then hand bots an "outcome or an objective" instead of a task, and eventually a full job. He cites the performance marketing team giving a bot its own ad logins and budget to run A/B tests in coordination with a design team's bot, and a support team bot that reproduces issues and resolves some tickets end to end.

One bot or many: users organize teammates differently

Lauren says she prefers a more "horizontal" setup with a small number of bots, while others split by customer or by function. Roman says he likes dedicating each bot to caring about one problem, comparing it to hiring someone who "wakes up in the morning and really cares about a problem." The hosts note small businesses, particularly ones that struggle to hire, have been enthusiastic early adopters, using bots for tasks like bookkeeping.

Permissions, identity, and bot-to-bot chat raise new trust questions

Grok Bot supports owners, managers, and collaborators for each bot, but Roman says the industry lacks a clear answer on authentication and authorization for AI coworkers. His approach: "what would you do for a human?" — scope credentials by role and expand access as trust builds. Bots can chat with each other inside the app, and Lauren recounts a case where she told a "lead engineer bot" to supervise others; after she gave it feedback, it began "scolding" the other bots in their shared chat.

Roman raises an open concern about bots in shared Slack threads lacking social awareness — "it's as if you were to onboard an employee who has no EQ." Asked about bots staging a "rebellion," Roman says he personally hasn't seen malicious behavior and that it would likely require aggressive instruction, though a host flags "obliterated" models as a separate risk since they remove refusal behavior.

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

Lauren describes shifting her engineering work largely into Slack and X rather than cursor directly. She gives an example of collaborating with a colleague and her bot "Potato" in a public Slack thread with roughly 200 messages, where Potato spawned a cursor cloud agent with its own virtual machine to prototype a feature and return screenshots and videos for feedback — she says she "didn't even look at cursor for this project." A host calls this "the gold standard" but notes only a small fraction of engineers currently work this way.

Codebase guardrails, not endless review, are the key lever

Lauren describes "Pstack," her open-sourced skill set inspired by Gary's Gstack, which she compares to "your personal set of chef knives." She argues that investing in refactored architecture, API design, static analysis and lint rules acts as a form of memory that reduces token spend on review. She cites building a dependency-graph checker as a lint rule to prevent long tasks blocking the Electron app's renderer thread, rather than relying on code review to catch the issue repeatedly.

On how much review is enough, Lauren says she has pulled back from heavy adversarial review across model families because agents can overfit to feedback without full context of product intent. She favors an "inverted pyramid" where most investment goes into the codebase and static analysis, with only limited human review reserved for sensitive areas like infrastructure or databases.

Execution is abundant; the bottleneck is now direction and taste

Roman says the team's bottleneck has shifted from engineering time to alignment on product vision: team members now frequently find a PR already exists for an idea raised in conversation, but merging everything risks a "Frankensteiny product." He says questions about what is "good" or "great" now dominate team discussions more than before. Lauren adds that human judgment on user-facing design still matters, noting she directs her own automation toward maintenance and bug fixes rather than new feature shipping, since changing "core pixels" users see daily requires more intentional care and internal dogfooding before release.

Looking ahead: AI-native companies and new roles

The hosts reference Jack Dorsey's idea of companies reducing to three roles — ICs who ship outcomes directly, a "DRI" orchestrating them, and a temporary "player coach" who teaches AI fluency, a role a host suggests fits Lauren. Roman notes code benefits from compilers and CI in ways other business knowledge work does not, since context "lives in a codebase" for engineering but is often "stuck in people's heads" elsewhere, leaving open how non-engineering "factories" will close that gap. Lauren says her hope for 2027 is bots approaching full coworker status, and separately speculates about future interfaces, citing a Neuralink product called Telepathy as a possible direction for communicating intent to agents "at the speed of thought."