This video presents Grok Bot as a manager that plans work, manages coding agents, and verifies results, rather than a developer writing code itself. Before adding more agents, build an environment whose results you can trust, with automated checks, risk-based review, and access restrictions. Drawing on Lauren Tan's example and his own setup, the presenter recommends starting with one small workflow.
1. Why Use Grok Bot as a Manager?
The presenter introduces Lauren Tan, pstack's creator and an engineer at Grok Bot and Cursor, who uses Grok Bot to manage agents and process thousands of pull requests each month. A pull request, or PR, is a proposal for reviewing code changes before incorporating them into an existing project.
He notes that Lauren also promotes these tools, which should be kept in mind when assessing the example. He adds that Theo, the developer YouTuber behind T3 Code, demonstrated similar agent management despite not being directly involved with Grok Bot.
After trying various tools and agents himself, the presenter kept using Grok Bot because it was simple to use. It has replaced substantial parts of his business workflows. In recent weeks, it has also coordinated his software development system using Claude Code and Cursor.
Replicating Lauren's scale is difficult. According to the presenter, Lauren handles more than 2,000 PRs monthly with an effectively very generous token budget. Still, the approach shows ideas ordinary developers can adopt and the direction of the technology.
2. Give the Bot Planning and Verification; Give Specialists the Coding
The proposed division of responsibility is clear:
"Your bot here is the manager, not the coder."
Grok Bot is particularly useful at the beginning and end of work. At the beginning, it identifies what to build: the purpose and requirements. Connecting Slack, email, X, Linear, and other channels lets it collect context for future features and problems from conversations and reports.
At the end, it checks results, reports progress, and manages task lists. The coding between those points goes to coding agents such as Claude Code, Codex, and Cursor. Grok Bot makes a plan, hands it off, checks the returned result, and informs the user.
As in Lauren's example, a team engineering bot can join Slack and be tagged when coding work is needed. The presenter says companies he examined, including Stripe, likewise use Slack to manage agents.
"Grok Bot plans and hands off the work. When it comes back, it can check the result and tell you what happened."
Grok Bot is not mandatory. The same principles apply with a custom agent or another project tool acting as coordinator.
Cost is another reason the presenter sends coding to a Claude Code subscription or Cursor cloud agents. In the video, Grok Bot usage draws on a weekly allowance shared by Grok and Cursor, so sending all coding to Grok can quickly exhaust credits or quota.
Separating work also supports isolation: each agent can have a separate computer, context, and stopping mechanism. The presenter connected Grok Bot to environments in a local Mac container and on a VPS.
3. Sponsor Segment: Neon Realtime
The next segment is a paid sponsorship from Neon. The presenter says he uses Neon databases for most projects he builds with agents and introduces Neon Realtime.
Live updates such as chat messages, notification counts, or colleagues' document edits often require a separate, complex system. He explains that Neon Realtime lets the database handle these updates: after an initial query for unread messages, for example, the result updates automatically.
It can also display agent progress in real time. Viewers are directed to a link in the video description to try it free.
4. Lauren's Daily Workflow: Feedback to Automatic Merge
Lauren's routine follows five stages from feedback collection through fixes and verification:
- Watch Slack channels containing app feedback.
- When Grok Bot finds a problem, create a Linear ticket.
- A Linear or Jira ticket triggers a Cursor cloud agent, which reproduces the issue in its own environment.
- The agent fixes the bug and creates a "fix and fuzz" PR, with several agents helping verify it.
- After fuzzing passes, notify Lauren in Slack and merge automatically one hour later if no further changes are requested.
Here, fuzzing means trying the modified functionality in different ways to find problems. Agents click randomly or use tools such as Playwright to interact like actual users and check that the fix holds up.
"A team of agents opens a pull request, then tries to break it or find errors."
The presenter stresses that this must not be applied equally to all changes. Risk should be classified by blast radius, the extent of damage if a change goes wrong. Minor fixes may merge automatically; critical areas such as transactions require human review.
Lauren reportedly prefers the metaphor of a Michelin-starred restaurant kitchen to a software factory. Developers remain responsible for final results like executive chefs directing a team, even when they do not cook every dish themselves.
"Even when the team cooks, your name is on every plate."
5. Four Layers of Verification for Trustworthy Agents
Companies operating many agents did not simply increase their agent counts. They first built trustworthy foundations and verification systems.
"If you cannot trust one agent, how will you manage fifty?"
Lauren's inverted pyramid has four layers, with more investment in the foundations at the top:
- Codebase: Establish good structure, strict types, and clear component boundaries. Agents tend to copy existing code and take the easiest path, so design the easy path to be the correct one.
- Automated checks: Use established tools such as lint rules, tests, and continuous integration. Turn repeated agent mistakes into automatic rules rather than fixing them manually every time.
- Written guidance: Use rule files such as
AGENTS.mdandCLAUDE.md, skills, bug-review bots, and security bots. The presenter also recommends his video on Cloudflare security skills. - Human review: Still necessary, but the least scalable layer, so avoid relying on it alone.
"Agents like copying what exists and taking the shortest path. Make the easy way the right way."
The presenter reports similar changes at Anthropic. Materials cited in the video say Claude Code's merged PRs more than doubled from June to September while the percentage requiring reverts fell by more than 40%. Review did not disappear; much of it moved to machines.
Reaching that level of trust requires upfront investment. He cites Alan Wells' three-person team, which reportedly paused new product development for about six weeks to build verification procedures supporting deployment without human code review.
6. His Setup: Talk to Chief, Delegate to Multiple Bots
The presenter separates bots by business function but does not want fifty bots to manage. Users primarily talk to Chief, which distributes work to specialist bots behind the scenes. Group chats can let bots talk to one another when necessary.
Each bot's connections are restricted to keep permissions narrow even when shared with others. However, he worries that he cannot sufficiently inspect Grok Bot's credential vault, memory, and skills.
"It is disappointing that I cannot see what memory accumulates, what skills exist, or how my vault is managed."
Convenience alone is not enough for long-term trust; he wants greater transparency and evidence. For now, he accepts the risk to explore the possibilities and share results with viewers.
For a marketing-site change, for example, he asks Chief, which launches a Cursor cloud agent or a Claude Code instance on his Mac, depending on specified conditions. A VPS is also connected. Defining which agent to use under which conditions and Claude Code's default model appears to make Grok Bot store those preferences as a skill.
He cannot see exactly where that skill is stored. Anyone uncomfortable with this opacity can build an equivalent coordinating agent themselves.
A benefit is easy access and coordination from a phone, Mac desktop, or another PC. Similar connections can be built with tools such as Tailscale. Each folder and execution environment has separate security permissions and rules. When needed, Grok Bot runs Claude Code with a selected model in headless mode, without operating a graphical interface.
Connected to Slack and documents, Grok Bot can also find some answers when subagents get blocked by questions, allowing work to continue without asking the presenter. Theo is experimenting with a similar flow controlling several devices through Grok Bot using T3 Code, though it remains early.
7. Organize the Backlog by Priority and Risk
Information Chief gathers from Slack and conversations enters the presenter's backlog, the list of future work. He stores it in Notion, though Linear or Jira would also work.
Priorities use RICE scores: reach, impact, confidence in estimates, and effort. He adds a blast-radius score for the damage a failed change could cause.
This can prioritize small-effort tasks that help many people. Bots can proactively suggest what to do next, but if generating suggestions becomes an end in itself, unnecessary work can quickly fill the backlog.
Lauren also gathers Slack bug reports and X complaints into a long-term improvement workflow. Frequent collection consumes tokens, however. Someone with ample resources may afford it, but individuals should consider the cost before running it hourly.
The presenter instructs agents to use each change's risk to decide whether humans review it, how much AI review to apply, and how extensively to run Playwright and security tests.
8. Secure Shared Environments and Start with One Small Loop
Several Grok Bot bots may share one cloud computer, containing files, signed-in browser sessions, and CLI credentials. Logging into a coding tool there with an API key may therefore make that key available to other bots.
Connecting many tools and granting broad permissions is powerful, but moving fast can ultimately create problems for you. Referring to a secure software development reference architecture from Docker and security companies, he summarizes:
"The more autonomy you give agents, the less you should trust them to police themselves. Controls must live in the execution environment."
Run agents in isolated environments such as sandboxes, restrict credentials, and prefer read-only access where possible. Until verification is sufficiently trustworthy, agents may open PRs but should not merge them on their own. Grok Bot alone does not solve every security problem; people must decide based on each codebase's risk.
Beginners should build one work loop, rather than dozens of agents. He proposes this basic bot rule:
"For anything larger than a simple question, do not code it yourself. Hand it to a coding agent with acceptance tests, check the evidence, then open a pull request and report back."
Acceptance tests are checks establishing whether the requested work is complete. Each time an agent mistake is corrected, move the solution as early in the system as possible: first consider code structure, then automated checks, instruction files, and finally human review.
9. Closing Remarks and a Farewell to Patrick Stewart
The presenter directs viewers interested in building similar systems with others to his Switch Dimension course and community. He also recommends earlier videos on Conway's law and subagent organization.
At the end, he offers a personal tribute, saying he has heard sad news about Patrick Stewart. He recalls hurrying home as a child to watch Star Trek: The Next Generation on Sky TV. Stewart's Captain Picard demonstrated good leadership: an intelligent, articulate, strong, and fair person in Gene Roddenberry's vision of the future.
"Patrick, thank you for everything. Goodbye."