The software production line practice where Grok Bot handles orchestration while Claude Code and Cursor write code
English text is being prepared.
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
Grok Bot 当经理、Claude Code / Cursor 干活：编排层才是软件产线的新界面
来自 @robshocks 的视频分享，基于对 @poteto 和 @theo 使用实践的梳理。Rob 提出主张：编排 bot 管「第一公里」（意图）和「最后一公里」（追进度、验收），真正写代码交给 Claude Code、Cursor、Codex 等有独立机器的 coding agent。Lauren Tan（pstack；Grok Bot / Cursor 侧工程师）月级上千 PR、Slack 触发、云 agent 复现与「fix and fuzz」、干净后自动合；Theo（T3 Code）也在用 Grok Bot 管机器舰队。核心不在多堆 bot，而在于信任基础设施，倒金字塔：代码库结构 → 静态分析/CI → 规则与 skill → 人审放在最底、最不该扩规模的那一层。 https://t.co/11x8wnJ1Eb
Grok Bot 和 Claude Code / Cursor 分工怎么拆？ Grok Bot 适合连 Slack、邮件、X、Linear 等，收齐「该建什么」的上下文，再盯任务是否做完。中间写代码别耗在编排 bot 上：一来额度与 Cursor/Grok 共用池容易烧光，二来 worker 有独立电脑、上下文和可杀掉的开关，隔离更好。作者自己常把活派给 Claude Code 订阅或 Cursor 云 agent；也可自建编排（Claude/Cursor Projects），模式可迁移。大厂产线案例里，Slack 当指挥面很常见。
Lauren 的日环（简化版） 盯产品相关 Slack → 开 Linear 单 → Cursor 云 agent 在独立机复现 → 开「fix and fuzz」PR（一小群 agent 用随机点击 / Playwright 等试着打破修复）→ fuzz 干净则 Slack 通知，约一小时无异议可自动合。作者强调要对标 Anthropic 的做法：按爆炸半径分绿/黄/红，支付等关键路径不能无脑自动合。Lauren 不爱「工厂」比喻，更近「米其林厨房」：你是主厨，菜是团队做的，盘子上仍是你的名，和 Addy「责任在人」同调。
倒金字塔：信任从哪堆 1. 代码库：清晰边界、强类型，agent 爱抄现有最短路径，要让「容易的事就是对的事」。 2. 静态分析 / lint / 测试 / CI：同一错反复人工收拾，就写成确定性规则。 3. 文档层：AGENTS.md、CLAUDE.md、skills、各类 bot。 4. 人审：最贵、最不扩。引用 Anthropic 一段：合并量升、回滚占比降，是把大量「读审查」挪给机器，不是取消审查。有团队为铺验证停新产品约六周，事后觉得值。
Rob 自己的落地与踩坑 少造五十个 bot，用一个「Chief」统筹委派；权限收窄；凭证进 vault——他对「看不清记忆/skill/vault 细节」有保留，但仍在用。Backlog 进 Notion，例行 RICE + 爆炸半径打分；可主动建议改进，但别为了填满 backlog 而刷任务。Lauren 用 routine 从 Slack bug、X 抱怨收上下文进外环，推理额度高才扛得住高频。安全提醒：Grok Bot 多 bot 共享一台云电脑（文件、浏览器会话、CLI 凭证），一个 API key 登录，别的 bot 也可能用到。Docker 等「安全软件工厂」参考架构的核心：越自主，越不能指望 agent 自律，控制要在环境里，沙箱、最小权限、可开 PR 但默认不合。
可快速复制的起步规则 编排 bot 自己别写代码；交给带验收标准的 coding agent；检查证据；开 PR；汇报。每次纠正 agent，把修复上移：先改代码结构，再 lint，再规则文件，人审最后。中间夹 Neon Realtime 赞助，解读略。