The software production line practice where Grok Bot handles orchestration while Claude Code and Cursor write code
Shao Meng relays Rob Shocks' video sharing, arguing that the orchestration bot is responsible for intent collection and progress acceptance, while code writing is handed off to coding agents with their own dedicated machines, such as Claude Code, Cursor, and Codex. The article outlines Lauren Tan's daily workflow: triggered via Slack, opens a Linear ticket, a Cursor cloud agent reproduces the issue and opens a fix and fuzz PR, and once fuzzing is clean, it can be auto-merged after about an hour with no objections. The author emphasizes that trust should be stacked on the codebase structure, static analysis and CI, and rules and skills, with human review placed at the very bottom, and warns that multiple Grok Bots sharing a single cloud computer carries the risk of shared credentials.
Why read this
AI score 53
The original article breaks down the division of labor between the orchestration layer and coding agents into a replicable process, and presents the inverted pyramid order for trust infrastructure.
Topics
Body · AI translation
Grok Bot as manager, Claude Code / Cursor doing the work: the orchestration layer is the new interface of the software production line
From a video shared by @robshocks, based on a review of how @poteto and @theo put these tools into practice. Rob argues: the orchestration bot handles the "first mile" (intent) and the "last mile" (chasing progress, acceptance), while the actual coding is handed to coding agents with their own machines, such as Claude Code, Cursor, and Codex. Lauren Tan (pstack; engineer on the Grok Bot / Cursor side) ships over a thousand PRs a month, triggers from Slack, has cloud agents reproduce issues and run "fix and fuzz," and auto-merges once things are clean; Theo (T3 Code) also uses Grok Bot to manage a fleet of machines. The point is not to pile up more bots but to trust the infrastructure, an inverted pyramid: codebase structure → static analysis/CI → rules and skills → human review at the very bottom, the layer that should scale the least. https://t.co/11x8wnJ1Eb
How should the work be split between Grok Bot and Claude Code / Cursor? Grok Bot is good at connecting to Slack, email, X, Linear, and the like, gathering the full context of "what should be built," and then watching whether the task gets done. Don't burn the middle coding stage on the orchestration bot: first, its quota shares a pool with Cursor/Grok and is easily exhausted; second, workers have their own computers, their own context, and a kill switch, so isolation is better. The author often assigns work to a Claude Code subscription or a Cursor cloud agent; you can also build your own orchestration (Claude/Cursor Projects), and the pattern transfers. In big-company production-line cases, Slack as the command surface is very common.
Lauren's daily loop (simplified) Watch product-related Slack → open a Linear ticket → a Cursor cloud agent reproduces it on a separate machine → open a "fix and fuzz" PR (a small group of agents tries to break the fix with random clicks / Playwright, etc.) → if fuzzing comes back clean, notify via Slack, and auto-merge after about an hour with no objections. The author stresses benchmarking against Anthropic's approach: classify by blast radius into green/yellow/red, and critical paths like payments must not be auto-merged blindly. Lauren dislikes the "factory" metaphor and prefers "Michelin kitchen": you are the head chef, the team makes the dishes, but your name is still on the plate—echoing Addy's "accountability stays with humans."
The inverted pyramid: where trust piles up 1. Codebase: clear boundaries, strong typing; agents love to copy the shortest existing path, so make "the easy thing the right thing." 2. Static analysis / lint / tests / CI: if the same mistake keeps needing manual cleanup, write it as a deterministic rule. 3. Documentation layer: AGENTS.md, CLAUDE.md, skills, various bots. 4. Human review: the most expensive, the least scalable. Quoting a passage from Anthropic: merge volume up and rollback share down comes from moving a lot of "reading for review" to machines, not from abolishing review. One team paused new products for about six weeks to build out verification, and afterward felt it was worth it.
Rob's own rollout and pitfalls Build fewer than fifty bots; use one "Chief" to coordinate and delegate; narrow permissions; put credentials in a vault—he has reservations about not being able to see the details of memory/skills/vault clearly, but still uses it. Backlog goes into Notion, routinely scored with RICE + blast radius; it can proactively suggest improvements, but don't spam tasks just to fill the backlog. Lauren uses routines to pull context from Slack bugs and X complaints into the outer loop; only a high reasoning quota can sustain that frequency. Security reminder: Grok Bot has multiple bots sharing one cloud computer (files, browser sessions, CLI credentials), one API key login, and other bots may use it too. The core of reference architectures like Docker's "secure software factory": the more autonomous things get, the less you can count on agents to self-regulate—controls must live in the environment: sandboxes, least privilege, PRs allowed but no merge by default.
Starter rules you can copy quickly The orchestration bot doesn't write code itself; hand it to a coding agent with acceptance criteria; check the evidence; open a PR; report back. Every time you correct an agent, move the fix up a level: first change the code structure, then lint, then rule files, and human review last. A Neon Realtime sponsorship segment is inserted in the middle; its explanation is omitted.