Amp responds to "anyone can push to main": how a 21-person team uses culture to block slop
English text is being prepared.
The Amp team responds to "how do you avoid shipping slop when anyone can push to main": not through mandatory PRs, but through a small 21-person team, direct accountability to customers, and shared taste. The big architecture change for self-hosted Orbs had no RFC; it was finalized in a single Slack thread at a customer site and shipped within a week. The adapter interface exposes only three requests—spawn/pause/delete—so customers can write their own hypervisor adapter with an agent in half a day. The team says measurements show Mac time accounts for only 35%–40% of agent time, and argues for using videos, screenshots, and end-to-end runs instead of unit tests as evidence.
View original post“How do you not ship slop if everybody can just push to main?” @sqs and @thorstenball answer the replies to The Company of the Future, and explain how Culture Stops Slop. 00:00 Intro: Tough luck, get the tokens 01:08 The responses to The Company of the Future 02:06 Don't meet people where they are 03:45 Self-hosted Orbs: a big architecture change without an RFC 09:16 Adapters are cheap now: customers fill in the last 20% 12:51 "You're only 21 people" is the point 15:58 Do what gives you energy & Quinn's secret Android app 20:44 macOS Satellites & capital-A Agile 27:21 A feature's whole life in one thread 29:26 Culture stops slop 33:21 No PMs in the middle & adopting a customer 36:54 Avoiding the everything app & not hiring your way out 40:43 A shared sense of urgency & removing features 46:29 "Why believe you?" You've got it backwards 48:29 Unit tests vs proof: videos & screenshots 53:53 The real cost of code review 58:17 Get to the tokens
View original
“How do you not ship slop if everybody can just push to main?” @sqs and @thorstenball answer the replies to The Company of the Future, and explain how Culture Stops Slop. 00:00 Intro: Tough luck, get the tokens 01:08 The responses to The Company of the Future 02:06 Don't meet people where they are 03:45 Self-hosted Orbs: a big architecture change without an RFC 09:16 Adapters are cheap now: customers fill in the last 20% 12:51 "You're only 21 people" is the point 15:58 Do what gives you energy & Quinn's secret Android app 20:44 macOS Satellites & capital-A Agile 27:21 A feature's whole life in one thread 29:26 Culture stops slop 33:21 No PMs in the middle & adopting a customer 36:54 Avoiding the everything app & not hiring your way out 40:43 A shared sense of urgency & removing features 46:29 "Why believe you?" You've got it backwards 48:29 Unit tests vs proof: videos & screenshots 53:53 The real cost of code review 58:17 Get to the tokens
Body
Amp 回应「人人都能推 main」
@AmpCode 团队不靠强制 PR 拦 AI 时代的「水货」代码，而是靠小团队、皮肤在局、公开反馈与共同品味；大架构变更可以在一条 Slack 线程和一次客户现场里定稿；适配器变便宜后，客户用 agent 自己补最后 20%；别用扩招逃避优先级，别迷信单测，用视频和截图当证据；token 不是外挂，是新基建。
反馈两极，以及「别迁就现状」 上一集讲完 21 人公司怎么干活之后，有人真的停了 PR、全公司上 Amp、全面用 Orbs；也有人说安全组强制要 PR，或批评「你们不该不做 PR，要迁就用户习惯」。他们的回应很硬：2026 年若迁就现状，半年后产品就废了，迁就会一起落后，也会浪费客户时间。他们的承诺是一起走在前沿，路会颠，但要比停在半年前的人领先得多。
大改架构，不必写 RFC：Self-hosted Orbs 有人问：周一开完会各自干活，大架构怎么改？例子是上线 self-hosted Orbs。Thorsten 先画出接口：客户起一个服务，听 Amp 的「起 Orb / 暂停 / 删」；怎么起由客户自己填空。Hitesh 接过去，和 Karl、Jesse、Alex 飞到客户现场做原型，安全组不准入站连接，现场当场在 Slack 里改方案、贴白板图、定新架构。新闻帖当设计文档反复迭代，边拉设计伙伴边改，最后一周上线。Quinn 拆开看：高信任小团队、现场有决策权、没有层层审批；agent 又把「客户写适配器」变成可落地的赌注，以前大家怕写代码，现在写适配器几乎零成本。
适配器便宜了：把最后 20% 留给客户 接口刻意做成「spawn / pause / delete」三请求，客户按自己的基础设施接。以前大家想要 YAML、blessed provider；现在 Andrew（Amp Labs）半日用文档让 agent 一枪写出自有 hypervisor 适配器。Quinn 说：若还要销售、市场、PM、财务各管一摊，产品和体验只会更差。
「你们才 21 人」——这正是原因，不是借口 客户并不在乎你几个人，在乎 30 分钟能否修完。人多却跑不过人少，就要改组织结构。两人把「only 21」比作当年 two-pizza team：理想规模本身就是设计目标；大公司若又慢又取悦不了客户，就要重新解释「为什么要这么大」。
跟着能量走：秘密 Android App 有人问「跟着能量走是不是营销」。Quinn 周五没告诉任何人，让 agent 试做 Android 应用；没平板就先藏 URL 发 APK 收反馈，再 Instacart 买三星平板验证，若先开会证明「这是最重要的事」，能量会被抽干。日常也有「拖沓感」：改名、想清楚怎么发新闻帖，能量又回来。成年人不甩锅，但目标仍是让该干的活尽量有能量。
macOS Satellites 与大写的 Agile 用户想在 Orbs 上做 iOS/macOS。全量「Morbs」贵、稀缺、Docker 慢，实测 Mac 时间往往只占 agent 时间的 35%–40%。Jesse 提出 sidecar（后称 Satellites），Hamish 半日原型、feature flag 内测，再写新闻帖迭代，Quinn/Thorsten 几乎没看代码。他们自称真正大写 Agile：小步、碰现实、收反馈；agent 不仅加速写代码，也改变「怎么交付、怎么灰度」。敏感数据场景也一样：先问「怎样的工具和流程能让你一天发 50 次」，那些以前只有大厂才有的影子副本、更好回滚，现在可以自己用 agent 造。
文化拦水货：skin in the game 核心反问：人人可推 main、无强制评审，如何不灌水货？Quinn：不是招「从不灌水」的超人，把 Amp 人放到别的激励和文化里也会灌。关键是不想灌、知道什么是水货：直接对客户负责、要自己维护、人人都是对外面孔（「21 个联合创始人」）、高信任下敢当面说「这是什么水货」。Thorsten：文化是你奖励什么、开除什么；频道里实时表扬与叫停比被动攻击式 PR 评论更管用。若不敢说别的队在灌水，根因往往是管理与恐惧，不是缺流程。
没有中间的 PM：认养客户要真养 Hitesh 背景是机器学习，却因泡在客户频道里，周末做出「个人自托管 Orbs」，周一主动通知感兴趣客户，没有 PM 挡在中间，劳动果实看得见。认养客户不够：要按 agent 时间尺度改产品，有时 15–30 分钟修好，你是对方眼里整家公司的大使。
别变成万能应用；别用招聘逃避优先级 修小问题很爽，大东西（self-hosted Orbs、macOS）容易被挤掉。周一会上会清空某人整盘任务做深活。扩招「专门做那件谁都不做的重要事」往往是信号：你们其实没把它排进优先级。容器船比喻：该扔的是次要货，不是把最重要的活外包给新人。共享紧迫感：不能只是打磨同一辆车，要推车前进；砍功能也常态，Quinn 砍了 Thorsten 实验性侧栏，对方反而如释重负。Agent 擅长零到一、一到多、删东西、迁兼容；不擅长的是跨部门说服会，那就尽量消灭这类会。
「凭什么信你们」：因果反了 有人说卖 agent 的人当然吹 agent。Thorsten：不是因为在 Amp 才吹 AI；是因为相信 AI 在改软件开发才加入 Amp。Quinn 用「当然你会说爱妻子，因为你娶了她」的比喻：因果是反过来的。
证明重于单测；看见评审的隐性成本 Thorsten 很久不看单测，看 UI、图、端到端是否跑通；信任模型和「闻得出不对」的直觉。GitLab 集成例子：给 agent 一台机装 GitLab，对着 GitHub 流程实现，产出视频、截图和可点的 MR，文件名对齐即可，不必再抠单测。架构走偏、迁移搞砸？回滚成本也在下降，但仍要盯生产迁移这类高危动作。Quinn：历史上 agent 迁移糟糕时，他们加过「create/alter 须对照生产查询计划」一类约束，目标是让 agent 能做，而不是放弃 agent。Niko 修多余请求、Thorsten 误删仍被写的列导致短时 500：人工评审未必拦住，却可能拖五天；应用 Bastiat「看见与看不见」，严苛评审挡住的 bug 看得见，掐死的能动与速度看不见。
收尾：去拿 token 「你们只是因为 token 无限」，他们说自己也在付费订阅，用量远没到天价。更重要的一句：抱歉，认命吧；每月只肯花 50 刀 token 却要和别人拼，本就不是公平赛场。像 2003 年抱怨对手网速好，该做的是上网。没有教授按「花了多少 token」曲线打分，只看产出；所以要去拿 token。价格相对智能在降，这不是可选项。