AMP 为何悄然弃用 GitHub？AI 代理重塑开发流程

导读

6月11日，一篇题为《The End of Code Review》的论文在 arXiv 上线，提出编码代理已经跨过使人类代码审查变得多余的能力阈值，人类代码审查应当被取代。这一论断把持续多年的代码审查争论推到了临界点：问题不再是 AI 能否辅助审查，而是传统强制审查是否还有继续存在的必要。

9月7日发布的 Latent Space 访谈中，Quinn Slack 给出的回答不是一个理论推演，而是一个已经在运行的操作系统。他明确表示 AMP 团队已正式结束合并到主分支前的强制代码审查，前提是团队具备真正的信任与端到端责任感。这个前提是关键：取消审查不是放弃质量，而是把质量责任重新放回能够并行交付的团队。

Quinn Slack 进一步解释了 AMP 的质量逻辑：用平均恢复时间取代平均故障时间来管理快速演进的终端用户软件。团队可以在发现日志问题或收到客户报告后 15 分钟内发送修复，这种快速恢复比等待数天才能发布带来更高的质量。这提供了从“能不能取消”到“怎么取消”的决策标准：以恢复速度换取演进速度，而不是追求永不失败。

视频还解释了为什么这种转变必须伴随云端代理。云端代理通过 OIDC 获得有限且有意的生产访问权限，而本地 CLI 代理天然拥有几乎无限制的开发者权限，更容易逃逸并触及生产环境。Orbs 的远程并行执行能力让开发者可以关闭笔记本、同时运行大量任务，使本地开发在效率和安全两个维度上都失去优势。

在这种范式下，GitHub 的传统协作界面也在从 AMP 日常工作流中退出。团队几乎不再使用 Issues、Pull Requests 和 Actions，Quinn Slack 本人已把个人仓库全部迁移到 AMP 托管仓库，并认为代码托管正在商品化，竞争焦点转向 CI/CD 与可复现环境。视频因此不只回应代码审查，也解释了开发者工具平台的更替逻辑。

论文提出了“代码审查已经结束”的判断，而 Quinn Slack 的访谈给出了一个团队如何执行这一判断的真实样本。它补充的不是能力声明，而是组织与安全条件：只有用 AI 构建可信、端到端负责的团队，并把代理迁移到云端，取消强制审查才不会变成失控。对正在重新设计开发流程的团队来说，这比争论模型是否足够聪明更接近可操作答案。

核心结论

主动删除旧功能是保持技术前沿的必要策略，而非产品失误：Quinn Slack 认为在 AI 快速迭代周期中，保留旧功能的价值已变成负数，AMP 通过取消编辑器、推出 Orbs 云端运行等方式逼迫用户和团队留在技术前沿。这种“烧船”策略同时筛选员工和客户，确保产品不被旧工作流拖累。
取消强制代码审查的前提是用 AI 构建端到端负责的团队：AMP 已正式结束合并前的强制代码审查，目的是释放并行交付能力而非放弃质量。Quinn Slack 用“平均恢复时间”取代“平均故障时间”来管理快速演进的软件，强调快速修复比追求永不失败更符合 AI 时代的质量逻辑。
云端代理在安全性和效率上同时取代本地开发模式：云端代理通过 OIDC 获得有限且有意的生产访问权限，而本地 CLI 代理天然拥有几乎无限制的开发者权限，更容易逃逸并触及生产环境。Orbs 的远程并行执行能力让开发者可以关闭笔记本、同时运行大量任务，使本地开发在效率和安全两个维度上都失去优势。
智能代理正在取代传统软件界面，编程成为最终设置界面：Quinn Slack 提出“代理是任何软件的理想设置界面，编程是任何软件的最终设置界面”，认为与其构建复杂的设置面板或 MCP 集成，不如让代理直接通过代码修改软件。这一判断重新定义了软件的构建、运行和分发方式，具有前瞻性的传播价值。
GitHub 的替代不会以戏剧性方式终结，而是被托管临时仓库逐步取代：AMP 团队几乎不再使用 GitHub 的 Issues、Pull Requests 和 Actions，Quinn Slack 本人也将个人仓库全部迁移到 AMP 托管仓库。代码托管本身正在商品化，真正的竞争焦点转向 CI/CD 与可复现环境，这意味着 GitHub 的传统优势正在被解构。

观点拆解

1. AMP 的战略核心是主动删除旧功能，以“烧船”方式逼迫用户和团队留在技术前沿

在 AI 快速迭代周期中，保留旧功能的价值已经变成负数：Quinn Slack 认为，过去技术周期长达 5 到 10 年，留住用户十年是可行的；但在 AI 时代，如果产品不把用户推向技术前沿，三个月后用户就会认为产品过时并降低对公司的评价。这构成了 AMP 主动删除旧功能的底层逻辑。

“随着 AI 的快速发展，让用户停留在旧方式上的价值实际上已经变成负数。”

“如果你不推动并吸引他们和你一起站在技术前沿，三个月后他们会说：“等等，这些傻瓜和他们的产品是什么？太旧了。”他们对你的评价也会因此下降。”
AMP 通过主动取消编辑器等功能，迫使产品只保留面向智能代理的最佳路径：Quinn Slack 明确表示 AMP 的承诺是删除没有意义的旧功能，并率先取消了编辑器插件。这种主动做减法的策略，让用户只能按照 AMP 认可的方式使用智能代理，而不是退回旧工作流。

“我们如何取消旧功能，让 AMP 成为使用智能代理的最佳方式？如果你使用 AMP，你就是按照我们认可的方式在使用。你走在正确的道路上。这是我们对你的承诺。我们会删除一些没有意义的功能。”

“我们率先取消了编辑器插件。我们取消了很多功能。过去几个月里，一些人开玩笑说，我们因取消功能而闻名。”
Orbs 远程运行方式让用户无法退回本地开发，从而锁定新的工作范式：AMP 用 Orbs 把代理运行、开发服务器和桌面访问都搬到云端，并支持大规模并行执行。Quinn Slack 认为这种体验足以让用户不再想回到本地开发，并直接宣告本地开发已经结束。

“现在有了 Orbs，这是一种使用 AMP 的方式，可以远程运行。你可以合上笔记本电脑，可以并行做 100 件事。这种工作方式改变了我们团队所有人的工作方式。”

“这足以让你不再想使用本地开发。所以，在我们看来，本地开发已经结束了。”
“烧船”策略同时筛选员工和客户，只留下愿意站在技术前沿的人：Quinn Slack 将 AMP 的公司建设方式描述为“烧掉身后的船”，即不被旧系统束缚，完全致力于站在技术前沿。这种策略会自然筛选出认同这一理念的员工和客户，并排除那些要求产品十年不变的用户。

“我认为你做的关键事情是，你以烧掉身后船只的方式建立了公司。我们不会被旧系统束缚。我们完全致力于站在技术前沿，跟上一切新事物。因此，相信这一点的人，无论是员工还是客户，都是你想要的那种人。”

“还有另一种客户会说：“我已经用了 10 年，什么都别给我改，好吗？我在这工具上受过培训、有认证，别碰它，因为我喜欢它现在的样子。”这是完全不同的客户类型。”

2. AMP 团队已经彻底取消强制代码审查，前提是用 AI 构建一个高度负责、端到端负责的团队

强制代码审查在 AMP 已经正式结束，前提是团队具备真正的信任与端到端责任感：Quinn Slack 明确确认，合并到主分支前的强制代码审查已经取消。他认为最关键的不是流程本身，而是拥有一个真正可信、对工作从始至终负责的团队；AI 的作用正在于帮助构建这样一支更可靠、更有责任感的团队。

“合并到主分支前的强制代码审查，是的，已经结束了。”

“最重要的系统是拥有一个真正可信的团队，AI 让你能够建立一支更可靠、更有责任感、从始至终掌握主导权的团队。”
取消强制审查是为了释放并行交付能力，而不是放弃质量：Quinn Slack 指出，当公司强制要求代码审查时，开发者无法从更高的并行度中获益，任务会堆积在等待审查的环节。AMP 团队因为不需要等待审查，能够更充分地利用远程并行工作模式，这也是他们敢于取消强制审查的直接原因。

“如果公司强制代码审查，那堆积 20 个等待审查的任务有什么意义？我无法从更高的并行度中获益。”

“在 AMP 团队，我们 20 个人都是联合创始人，大家共享同样的愿景，我们能够从远程并行工作中获益，因为我们不必等待审查。”
AMP 用“平均恢复时间”取代“平均故障时间”来管理快速演进的终端用户软件：Quinn Slack 认为，对于快速演进的终端用户软件，正确的质量思维不是追求永不失败，而是追求快速恢复。他举例说，团队可以在发现问题后 15 分钟内发送修复，这种模式反而比等待数天才能发布带来更高的质量。

“你可以在发现日志问题或收到客户报告后 15 分钟内发送修复。这当然不是适合所有软件的方法。这是“平均恢复时间”与“平均故障时间”的对比。”

“对于快速演进的终端用户软件，这对我们来说是正确的做法。而且我认为它的质量比我们不得不等待数天才能发布任何东西要高。”

3. 本地开发已经过时，云端代理运行是更安全、更高效的软件构建方式

云端代理让开发从“本地阻塞”转向“远程并行”，本地开发模式已经过时：Quinn Slack 以 Orbs 为例说明，云端代理运行让开发者可以关闭笔记本、并行执行大量任务，这种工作方式已经改变了团队协作模式，并迅速被客户采用。这直接支撑了“本地开发已经结束”的判断：当远程执行足够简单可靠时，继续依赖本地开发就不再是效率最优解。

“现在有了 Orbs，这是一种使用 AMP 的方式，它在远程运行。你可以合上笔记本电脑，可以并行做 100 件事。”

“所以在我们看来，本地开发已经结束了，这是一个巨大的变化。”
云端代理可以通过 OIDC 获得有限且有意的生产访问权限，比本地 CLI 代理更安全：Quinn Slack 指出，云端代理可以通过 OIDC 获得限时、只读的生产资源访问权限，例如 30 分钟只读 G-Cloud 日志或生产数据库只读访问。这种“有限且有意”的授权模型，与本地 CLI 代理天然拥有开发者设备上几乎所有权限形成鲜明对比，是云端代理在安全范式上的核心优势。

“如果你能给你在云端运行的代理授予有限且有意的资源访问权限，让它通过类似 OIDC 的方式获得一个令牌，从而获得 30 分钟只读 G-Cloud 日志或生产数据库只读访问权限。”
本地 CLI 代理拥有几乎无限制的开发者权限，更容易逃逸并触及生产环境：Quinn Slack 对比了当前普遍做法：开发者笔记本上的代理拥有开发者已授权的几乎所有权限，而代理又擅长突破限制。他引用 Hugging Face 事件和客户案例说明，本地代理可能意外找到通往生产控制台的路径。这使本地 CLI 代理在安全上显得不可接受，从而强化了向云端迁移的必要性。

“但如果你把它和今天大家普遍的做法相比——给一个运行在开发者笔记本上的代理授予开发者设备上已授权的几乎任何东西的无限制访问权限。我们已经看到代理非常擅长突破限制，就像 Hugging Face 发生的事情那样。”

“现在有了一个比在开发者笔记本上运行一切更好的替代方案，而笔记本本质上几乎可以做任何事，并且可以突破障碍到达生产环境。既然有了替代方案，我认为 CLI 编程代理看起来真的不安全，你会想迁移到云端。”

4. 智能代理正在取代传统软件界面：编程成为最终设置界面，代理成为理想设置界面

智能代理正在同时改变软件的构建、运行和使用方式：Quinn Slack 认为，智能代理的影响不止于编写代码，而是延伸到软件如何被运行和消费。他展示的“应用”概念让用户可以在隔离环境中按需运行定制软件，并由代理直接对程序进行即时修复，这意味着软件生命周期正在被代理重新定义。

“我认为我们看到智能代理不仅改变了软件的构建方式，也改变了它的运行和使用方式。”

“那里有一个智能代理，你可以指示它对程序进行即时修复。”
代理是任何软件的理想设置界面，编程是最终设置界面：Quinn Slack 质疑了为智能代理专门构建 MCP 集成或复杂设置面板的必要性。他认为，当用户可以通过代码直接修改软件时，传统的设置界面和集成层就变得多余，代理本身成为最灵活、最理想的配置入口，而编程则是所有软件配置能力的最终形态。

“你不需要设置界面。你不需要复杂的集成、MCP 协议，或者购买现成控制面板软件包带来的所有负担。实际上，智能代理是任何软件的理想设置界面，而编程是任何软件的最终设置界面。”
可修改的软件比完整的开源更重要，稳定的接口契约让用户自由定制：对话进一步指出，用户真正需要的是能够有效“分叉”和修改软件的能力，而不一定要求软件完全开源。只要前后端接口契约稳定，并尊重安全与隐私，用户就可以把界面当作可自由改动的表层，这为代理驱动的软件定制提供了现实基础。

“我认为对人们来说，重要的是获得能够有效分叉的软件，即使它并非完全开源。只要前后端接口契约稳定，并尊重安全、隐私和所有那些事项，你就可以做任何你想做的事；它只是用户界面，他们并不在意。”

5. GitHub 正在从团队工作流中消失，但不会以戏剧性方式终结，而是被 AMP 托管的临时仓库逐步替代

AMP 团队几乎不再访问 GitHub，Issues、Pull Requests 和 Actions 正在从日常工作流中退出：Quinn Slack 明确表示，团队唯一访问 GitHub 的场景是处理 GitHub Actions 的故障，而 Issues 和 Pull Requests 已不再使用，Actions 也几乎弃用。这说明 GitHub 在 AMP 团队中的角色已经从协作平台退化为一个被动使用的代码托管端点。

“我们实际上几乎从不去 GitHub。我们唯一去 GitHub 的时候，是我们的 GitHub Actions 出了问题。”

“我们不再使用 Issues，不使用 Pull Requests，几乎不用 GitHub Actions，并且期待彻底停止使用。”
GitHub 的替代不是戏剧性终结，而是被 AMP 托管的临时仓库以“呜咽”方式逐步取代：Quinn Slack 将 AMP 定位为“下一个 GitHub”，并强调这类平台更替不会以巨响结束，而是以呜咽结束。团队越来越多地使用 AMP 托管的临时仓库，甚至他本人已将个人仓库全部迁移到 AMP，且完全不怀念 GitHub。

“我们发现，我们越来越多地使用由 AMP 托管的临时仓库。并不是说 AMP 是 GitHub 的杀手，它就是下一个 GitHub。这些事情不会以一声巨响结束，而是以一声呜咽结束。”

“我已经把我所有的个人仓库都迁移到了 AMP 托管的仓库，它们只运行在 Pierre 代码上，我一点都不怀念 GitHub。”
代码托管本身正在商品化，真正的难点转向 CI/CD 与可复现环境：Quinn Slack 认为存储代码是容易的部分，真正困难的是 Actions 和 CI/CD。他指出，自托管解决单人问题的工具很容易构建，但多租户系统会成倍增加复杂度。这意味着 GitHub 的传统托管优势正在被解构，而竞争焦点正在向执行环境迁移。

“他们提供存储，但不提供 Actions。他们不提供 CI/CD，而这正是我真正感到困难的部分。存储东西很容易，存储东西有什么难的？”

“构建一个只解决你自己问题的自托管工具要容易得多，而且可以做得非常强大。但如果你试图构建一个多租户系统，复杂度就会成倍增加。”

6. 代理正在从编程扩展到运维：复杂数据迁移可以由代理分阶段执行并自动监控回滚

代理的能力边界正在从写代码扩展到运维部署：Quinn Slack 指出，除了编程之外，代理还可以帮助完成另一大类工作：确保已发布内容能够顺利上线。这意味着代理的应用场景正在从开发环节延伸到运维环节，成为软件交付过程中的执行者。

“另一件事是看到这些代理如何帮助你在编程之外的事情上，也在运维方面帮助你。还有一整类工作是关于如何确保你能把已经发布的东西部署出去。”
复杂数据迁移可以由代理分阶段执行并自动监控：Quinn Slack 以 AMP 的 1B2 多工作区迁移为例，说明这类触及核心数据模型的复杂变更需要分多个阶段推进。代理在部署每个阶段后，会主动检查日志和数据库，确认约束条件未被破坏、没有出现大量意外错误，从而替代人工盯守。

“这基本上是把 AMP 从用户只能在一个工作区中的状态，转变为可以在多个工作区中的状态。任何以前构建过软件的人都知道，这种变更触及了最重要数据模型的核心。它非常复杂，你必须通过多个阶段来执行，让所有东西都向后兼容。”

“真正强大的是让代理在各个阶段中工作。在它部署一个阶段之后，它会去监控日志。它会去监控数据库，确认它设定的约束条件，确保没有出现太多意外错误。”
代理可以在异常时自动回滚，替代过去需要人工持续盯守的运维任务：Quinn Slack 分享了自己在 12 小时航班上让代理执行迁移的经历：代理会先运行几个安全的阶段并监控日志，一切正常才进入下一阶段，否则就回滚到之前的状态。他由此指出，这类任务过去需要开发者或运维团队全程监控，现在可以由代理完成。

“我让它执行了几个完全安全的阶段并监控日志，如果一切正常，它就进入下一个阶段。如果不是，它就回滚到之前的状态。”

“这就是那种过去会占用一个开发者，或者可能是一群人和运维团队来全程监控的任务。”

7. 传统 CI/CD 的形态正在被可重复的沙箱环境取代，但 CI 的底层需求反而在增长

对模型能力的不信任不会持续，传统 CI/CD 的形态正在进入倒计时：Quinn Slack 认为，每当人们说“我不信任模型去做某件事”时，这种判断往往很快就会被推翻。这意味着当前围绕传统 CI/CD 流程建立的工作方式，其存在基础正在被模型能力快速削弱。

“我认为，每当有人说“我不信任模型去做某件事”时，这种想法都不会持续太久。所以，我们所熟知的持续集成看起来日子已经屈指可数了。”
CI 的本质是可重复环境，而可重复沙箱的需求正在爆发式增长：Quinn Slack 指出，CI 的核心其实是提供一个可重复运行项目的环境。虽然传统 CI 形态在衰退，但 E2B、Daytona 等沙箱环境公司以及每天运行数百个 Orbs 的用户，说明这类可重复环境的需求反而在快速增长。

“但与此同时，有趣的是，持续集成不就是一个可重复运行你项目的环境吗？我的意思是，有人每天运行数百个 Orbs，而像 E2B、Daytona 以及所有这些沙箱环境公司都在经历巨大增长。”

“所以，一个非常像持续集成的东西正在强劲增长，但我们所熟知的持续集成看起来日子已经屈指可数了。”

8. Sourcegraph 与 AMP 的拆分是“做对投资者和员工的事”的范式，而非唯一成功路径

AMP 从 Sourcegraph 拆分时，以“所有投资者和员工同时持有两家公司股份”来对齐利益：Quinn Slack 说明，拆分过程中约 20 人转向 AMP，其余人留在 SourceCraft，而关键设计是让每一位投资者和每一位员工都拥有两家公司的股份。这使拆分不是简单的资产切割，而是一种让原有利益相关方共同参与新公司成长的结构安排。

“拆分过程简单来说就是 20 个人转去做 AMP，其余人留在 SourceCraft 团队。我们对投资者做了正确的事。所以，每一位投资者和每一位员工都拥有两家公司的股份。”
Sourcegraph 的拆分模式被定位为适合自身的选择，而非唯一正确的公司构建路径：Quinn Slack 承认 Intercom 与 Finn 等其他公司发展路径同样可以成功，并明确表示存在多种成功方式。但他强调，对 Sourcegraph 而言，代码搜索这一基础使其选择了拆分路径。这说明该治理决策是基于自身业务条件的判断，而不是对所有公司的普遍建议。

“我认为你们也看到过其他可能成功的方式，比如 Intercom 和 Finn，我非常祝贺他们。Intercom 是第一家公司，然后 Finn 作为一家专注人工智能的公司出现。我认为有很多方式可以成功，但对我们来说，Sourcegraph 的代码搜索，以及拥有这样的基础，使我们选择了这条路。”

总结

AI 代理正在从底层改写软件开发的规则：旧功能成为负资产，本地开发和强制代码审查被云端代理与端到端责任团队取代，编程本身成为软件的最终设置界面。这些变化不是渐进优化，而是范式切换。对开发者和团队而言，真正的风险不是 AI 能力不够强，而是继续依赖那些已经失去存在基础的旧工作流。主动“烧掉身后的船”，把团队和产品推向技术前沿，才是 AI 时代保持竞争力的核心策略。

信息源

视频来源

Inside the Team That Killed Mandatory Code Review — Quinn Slack, AMP：

外部资料

The End of Code Review:Coding Agents Supersede ...：
Why AMP Quietly Stopped Using GitHub — Quinn Slack, AMP：

导读

核心结论

主动删除旧功能是保持技术前沿的必要策略，而非产品失误：Quinn Slack 认为在 AI 快速迭代周期中，保留旧功能的价值已变成负数，AMP 通过取消编辑器、推出 Orbs 云端运行等方式逼迫用户和团队留在技术前沿。这种“烧船”策略同时筛选员工和客户，确保产品不被旧工作流拖累。
取消强制代码审查的前提是用 AI 构建端到端负责的团队：AMP 已正式结束合并前的强制代码审查，目的是释放并行交付能力而非放弃质量。Quinn Slack 用“平均恢复时间”取代“平均故障时间”来管理快速演进的软件，强调快速修复比追求永不失败更符合 AI 时代的质量逻辑。
云端代理在安全性和效率上同时取代本地开发模式：云端代理通过 OIDC 获得有限且有意的生产访问权限，而本地 CLI 代理天然拥有几乎无限制的开发者权限，更容易逃逸并触及生产环境。Orbs 的远程并行执行能力让开发者可以关闭笔记本、同时运行大量任务，使本地开发在效率和安全两个维度上都失去优势。
智能代理正在取代传统软件界面，编程成为最终设置界面：Quinn Slack 提出“代理是任何软件的理想设置界面，编程是任何软件的最终设置界面”，认为与其构建复杂的设置面板或 MCP 集成，不如让代理直接通过代码修改软件。这一判断重新定义了软件的构建、运行和分发方式，具有前瞻性的传播价值。
GitHub 的替代不会以戏剧性方式终结，而是被托管临时仓库逐步取代：AMP 团队几乎不再使用 GitHub 的 Issues、Pull Requests 和 Actions，Quinn Slack 本人也将个人仓库全部迁移到 AMP 托管仓库。代码托管本身正在商品化，真正的竞争焦点转向 CI/CD 与可复现环境，这意味着 GitHub 的传统优势正在被解构。

观点拆解

1. AMP 的战略核心是主动删除旧功能，以“烧船”方式逼迫用户和团队留在技术前沿

在 AI 快速迭代周期中，保留旧功能的价值已经变成负数：Quinn Slack 认为，过去技术周期长达 5 到 10 年，留住用户十年是可行的；但在 AI 时代，如果产品不把用户推向技术前沿，三个月后用户就会认为产品过时并降低对公司的评价。这构成了 AMP 主动删除旧功能的底层逻辑。

“随着 AI 的快速发展，让用户停留在旧方式上的价值实际上已经变成负数。”

“如果你不推动并吸引他们和你一起站在技术前沿，三个月后他们会说：“等等，这些傻瓜和他们的产品是什么？太旧了。”他们对你的评价也会因此下降。”
AMP 通过主动取消编辑器等功能，迫使产品只保留面向智能代理的最佳路径：Quinn Slack 明确表示 AMP 的承诺是删除没有意义的旧功能，并率先取消了编辑器插件。这种主动做减法的策略，让用户只能按照 AMP 认可的方式使用智能代理，而不是退回旧工作流。

“我们如何取消旧功能，让 AMP 成为使用智能代理的最佳方式？如果你使用 AMP，你就是按照我们认可的方式在使用。你走在正确的道路上。这是我们对你的承诺。我们会删除一些没有意义的功能。”

“我们率先取消了编辑器插件。我们取消了很多功能。过去几个月里，一些人开玩笑说，我们因取消功能而闻名。”
Orbs 远程运行方式让用户无法退回本地开发，从而锁定新的工作范式：AMP 用 Orbs 把代理运行、开发服务器和桌面访问都搬到云端，并支持大规模并行执行。Quinn Slack 认为这种体验足以让用户不再想回到本地开发，并直接宣告本地开发已经结束。

“现在有了 Orbs，这是一种使用 AMP 的方式，可以远程运行。你可以合上笔记本电脑，可以并行做 100 件事。这种工作方式改变了我们团队所有人的工作方式。”

“这足以让你不再想使用本地开发。所以，在我们看来，本地开发已经结束了。”
“烧船”策略同时筛选员工和客户，只留下愿意站在技术前沿的人：Quinn Slack 将 AMP 的公司建设方式描述为“烧掉身后的船”，即不被旧系统束缚，完全致力于站在技术前沿。这种策略会自然筛选出认同这一理念的员工和客户，并排除那些要求产品十年不变的用户。

“我认为你做的关键事情是，你以烧掉身后船只的方式建立了公司。我们不会被旧系统束缚。我们完全致力于站在技术前沿，跟上一切新事物。因此，相信这一点的人，无论是员工还是客户，都是你想要的那种人。”

“还有另一种客户会说：“我已经用了 10 年，什么都别给我改，好吗？我在这工具上受过培训、有认证，别碰它，因为我喜欢它现在的样子。”这是完全不同的客户类型。”

2. AMP 团队已经彻底取消强制代码审查，前提是用 AI 构建一个高度负责、端到端负责的团队

强制代码审查在 AMP 已经正式结束，前提是团队具备真正的信任与端到端责任感：Quinn Slack 明确确认，合并到主分支前的强制代码审查已经取消。他认为最关键的不是流程本身，而是拥有一个真正可信、对工作从始至终负责的团队；AI 的作用正在于帮助构建这样一支更可靠、更有责任感的团队。

“合并到主分支前的强制代码审查，是的，已经结束了。”

“最重要的系统是拥有一个真正可信的团队，AI 让你能够建立一支更可靠、更有责任感、从始至终掌握主导权的团队。”
取消强制审查是为了释放并行交付能力，而不是放弃质量：Quinn Slack 指出，当公司强制要求代码审查时，开发者无法从更高的并行度中获益，任务会堆积在等待审查的环节。AMP 团队因为不需要等待审查，能够更充分地利用远程并行工作模式，这也是他们敢于取消强制审查的直接原因。

“如果公司强制代码审查，那堆积 20 个等待审查的任务有什么意义？我无法从更高的并行度中获益。”

“在 AMP 团队，我们 20 个人都是联合创始人，大家共享同样的愿景，我们能够从远程并行工作中获益，因为我们不必等待审查。”
AMP 用“平均恢复时间”取代“平均故障时间”来管理快速演进的终端用户软件：Quinn Slack 认为，对于快速演进的终端用户软件，正确的质量思维不是追求永不失败，而是追求快速恢复。他举例说，团队可以在发现问题后 15 分钟内发送修复，这种模式反而比等待数天才能发布带来更高的质量。

“你可以在发现日志问题或收到客户报告后 15 分钟内发送修复。这当然不是适合所有软件的方法。这是“平均恢复时间”与“平均故障时间”的对比。”

“对于快速演进的终端用户软件，这对我们来说是正确的做法。而且我认为它的质量比我们不得不等待数天才能发布任何东西要高。”

3. 本地开发已经过时，云端代理运行是更安全、更高效的软件构建方式

云端代理让开发从“本地阻塞”转向“远程并行”，本地开发模式已经过时：Quinn Slack 以 Orbs 为例说明，云端代理运行让开发者可以关闭笔记本、并行执行大量任务，这种工作方式已经改变了团队协作模式，并迅速被客户采用。这直接支撑了“本地开发已经结束”的判断：当远程执行足够简单可靠时，继续依赖本地开发就不再是效率最优解。

“现在有了 Orbs，这是一种使用 AMP 的方式，它在远程运行。你可以合上笔记本电脑，可以并行做 100 件事。”

“所以在我们看来，本地开发已经结束了，这是一个巨大的变化。”
云端代理可以通过 OIDC 获得有限且有意的生产访问权限，比本地 CLI 代理更安全：Quinn Slack 指出，云端代理可以通过 OIDC 获得限时、只读的生产资源访问权限，例如 30 分钟只读 G-Cloud 日志或生产数据库只读访问。这种“有限且有意”的授权模型，与本地 CLI 代理天然拥有开发者设备上几乎所有权限形成鲜明对比，是云端代理在安全范式上的核心优势。

“如果你能给你在云端运行的代理授予有限且有意的资源访问权限，让它通过类似 OIDC 的方式获得一个令牌，从而获得 30 分钟只读 G-Cloud 日志或生产数据库只读访问权限。”
本地 CLI 代理拥有几乎无限制的开发者权限，更容易逃逸并触及生产环境：Quinn Slack 对比了当前普遍做法：开发者笔记本上的代理拥有开发者已授权的几乎所有权限，而代理又擅长突破限制。他引用 Hugging Face 事件和客户案例说明，本地代理可能意外找到通往生产控制台的路径。这使本地 CLI 代理在安全上显得不可接受，从而强化了向云端迁移的必要性。

“但如果你把它和今天大家普遍的做法相比——给一个运行在开发者笔记本上的代理授予开发者设备上已授权的几乎任何东西的无限制访问权限。我们已经看到代理非常擅长突破限制，就像 Hugging Face 发生的事情那样。”

“现在有了一个比在开发者笔记本上运行一切更好的替代方案，而笔记本本质上几乎可以做任何事，并且可以突破障碍到达生产环境。既然有了替代方案，我认为 CLI 编程代理看起来真的不安全，你会想迁移到云端。”

4. 智能代理正在取代传统软件界面：编程成为最终设置界面，代理成为理想设置界面

智能代理正在同时改变软件的构建、运行和使用方式：Quinn Slack 认为，智能代理的影响不止于编写代码，而是延伸到软件如何被运行和消费。他展示的“应用”概念让用户可以在隔离环境中按需运行定制软件，并由代理直接对程序进行即时修复，这意味着软件生命周期正在被代理重新定义。

“我认为我们看到智能代理不仅改变了软件的构建方式，也改变了它的运行和使用方式。”

“那里有一个智能代理，你可以指示它对程序进行即时修复。”
代理是任何软件的理想设置界面，编程是最终设置界面：Quinn Slack 质疑了为智能代理专门构建 MCP 集成或复杂设置面板的必要性。他认为，当用户可以通过代码直接修改软件时，传统的设置界面和集成层就变得多余，代理本身成为最灵活、最理想的配置入口，而编程则是所有软件配置能力的最终形态。

“你不需要设置界面。你不需要复杂的集成、MCP 协议，或者购买现成控制面板软件包带来的所有负担。实际上，智能代理是任何软件的理想设置界面，而编程是任何软件的最终设置界面。”
可修改的软件比完整的开源更重要，稳定的接口契约让用户自由定制：对话进一步指出，用户真正需要的是能够有效“分叉”和修改软件的能力，而不一定要求软件完全开源。只要前后端接口契约稳定，并尊重安全与隐私，用户就可以把界面当作可自由改动的表层，这为代理驱动的软件定制提供了现实基础。

“我认为对人们来说，重要的是获得能够有效分叉的软件，即使它并非完全开源。只要前后端接口契约稳定，并尊重安全、隐私和所有那些事项，你就可以做任何你想做的事；它只是用户界面，他们并不在意。”

5. GitHub 正在从团队工作流中消失，但不会以戏剧性方式终结，而是被 AMP 托管的临时仓库逐步替代

AMP 团队几乎不再访问 GitHub，Issues、Pull Requests 和 Actions 正在从日常工作流中退出：Quinn Slack 明确表示，团队唯一访问 GitHub 的场景是处理 GitHub Actions 的故障，而 Issues 和 Pull Requests 已不再使用，Actions 也几乎弃用。这说明 GitHub 在 AMP 团队中的角色已经从协作平台退化为一个被动使用的代码托管端点。

“我们实际上几乎从不去 GitHub。我们唯一去 GitHub 的时候，是我们的 GitHub Actions 出了问题。”

“我们不再使用 Issues，不使用 Pull Requests，几乎不用 GitHub Actions，并且期待彻底停止使用。”
GitHub 的替代不是戏剧性终结，而是被 AMP 托管的临时仓库以“呜咽”方式逐步取代：Quinn Slack 将 AMP 定位为“下一个 GitHub”，并强调这类平台更替不会以巨响结束，而是以呜咽结束。团队越来越多地使用 AMP 托管的临时仓库，甚至他本人已将个人仓库全部迁移到 AMP，且完全不怀念 GitHub。

“我们发现，我们越来越多地使用由 AMP 托管的临时仓库。并不是说 AMP 是 GitHub 的杀手，它就是下一个 GitHub。这些事情不会以一声巨响结束，而是以一声呜咽结束。”

“我已经把我所有的个人仓库都迁移到了 AMP 托管的仓库，它们只运行在 Pierre 代码上，我一点都不怀念 GitHub。”
代码托管本身正在商品化，真正的难点转向 CI/CD 与可复现环境：Quinn Slack 认为存储代码是容易的部分，真正困难的是 Actions 和 CI/CD。他指出，自托管解决单人问题的工具很容易构建，但多租户系统会成倍增加复杂度。这意味着 GitHub 的传统托管优势正在被解构，而竞争焦点正在向执行环境迁移。

“他们提供存储，但不提供 Actions。他们不提供 CI/CD，而这正是我真正感到困难的部分。存储东西很容易，存储东西有什么难的？”

“构建一个只解决你自己问题的自托管工具要容易得多，而且可以做得非常强大。但如果你试图构建一个多租户系统，复杂度就会成倍增加。”

6. 代理正在从编程扩展到运维：复杂数据迁移可以由代理分阶段执行并自动监控回滚

代理的能力边界正在从写代码扩展到运维部署：Quinn Slack 指出，除了编程之外，代理还可以帮助完成另一大类工作：确保已发布内容能够顺利上线。这意味着代理的应用场景正在从开发环节延伸到运维环节，成为软件交付过程中的执行者。

“另一件事是看到这些代理如何帮助你在编程之外的事情上，也在运维方面帮助你。还有一整类工作是关于如何确保你能把已经发布的东西部署出去。”
复杂数据迁移可以由代理分阶段执行并自动监控：Quinn Slack 以 AMP 的 1B2 多工作区迁移为例，说明这类触及核心数据模型的复杂变更需要分多个阶段推进。代理在部署每个阶段后，会主动检查日志和数据库，确认约束条件未被破坏、没有出现大量意外错误，从而替代人工盯守。

“这基本上是把 AMP 从用户只能在一个工作区中的状态，转变为可以在多个工作区中的状态。任何以前构建过软件的人都知道，这种变更触及了最重要数据模型的核心。它非常复杂，你必须通过多个阶段来执行，让所有东西都向后兼容。”

“真正强大的是让代理在各个阶段中工作。在它部署一个阶段之后，它会去监控日志。它会去监控数据库，确认它设定的约束条件，确保没有出现太多意外错误。”
代理可以在异常时自动回滚，替代过去需要人工持续盯守的运维任务：Quinn Slack 分享了自己在 12 小时航班上让代理执行迁移的经历：代理会先运行几个安全的阶段并监控日志，一切正常才进入下一阶段，否则就回滚到之前的状态。他由此指出，这类任务过去需要开发者或运维团队全程监控，现在可以由代理完成。

“我让它执行了几个完全安全的阶段并监控日志，如果一切正常，它就进入下一个阶段。如果不是，它就回滚到之前的状态。”

“这就是那种过去会占用一个开发者，或者可能是一群人和运维团队来全程监控的任务。”

7. 传统 CI/CD 的形态正在被可重复的沙箱环境取代，但 CI 的底层需求反而在增长

对模型能力的不信任不会持续，传统 CI/CD 的形态正在进入倒计时：Quinn Slack 认为，每当人们说“我不信任模型去做某件事”时，这种判断往往很快就会被推翻。这意味着当前围绕传统 CI/CD 流程建立的工作方式，其存在基础正在被模型能力快速削弱。

“我认为，每当有人说“我不信任模型去做某件事”时，这种想法都不会持续太久。所以，我们所熟知的持续集成看起来日子已经屈指可数了。”
CI 的本质是可重复环境，而可重复沙箱的需求正在爆发式增长：Quinn Slack 指出，CI 的核心其实是提供一个可重复运行项目的环境。虽然传统 CI 形态在衰退，但 E2B、Daytona 等沙箱环境公司以及每天运行数百个 Orbs 的用户，说明这类可重复环境的需求反而在快速增长。

“但与此同时，有趣的是，持续集成不就是一个可重复运行你项目的环境吗？我的意思是，有人每天运行数百个 Orbs，而像 E2B、Daytona 以及所有这些沙箱环境公司都在经历巨大增长。”

“所以，一个非常像持续集成的东西正在强劲增长，但我们所熟知的持续集成看起来日子已经屈指可数了。”

8. Sourcegraph 与 AMP 的拆分是“做对投资者和员工的事”的范式，而非唯一成功路径

AMP 从 Sourcegraph 拆分时，以“所有投资者和员工同时持有两家公司股份”来对齐利益：Quinn Slack 说明，拆分过程中约 20 人转向 AMP，其余人留在 SourceCraft，而关键设计是让每一位投资者和每一位员工都拥有两家公司的股份。这使拆分不是简单的资产切割，而是一种让原有利益相关方共同参与新公司成长的结构安排。

“拆分过程简单来说就是 20 个人转去做 AMP，其余人留在 SourceCraft 团队。我们对投资者做了正确的事。所以，每一位投资者和每一位员工都拥有两家公司的股份。”
Sourcegraph 的拆分模式被定位为适合自身的选择，而非唯一正确的公司构建路径：Quinn Slack 承认 Intercom 与 Finn 等其他公司发展路径同样可以成功，并明确表示存在多种成功方式。但他强调，对 Sourcegraph 而言，代码搜索这一基础使其选择了拆分路径。这说明该治理决策是基于自身业务条件的判断，而不是对所有公司的普遍建议。

“我认为你们也看到过其他可能成功的方式，比如 Intercom 和 Finn，我非常祝贺他们。Intercom 是第一家公司，然后 Finn 作为一家专注人工智能的公司出现。我认为有很多方式可以成功，但对我们来说，Sourcegraph 的代码搜索，以及拥有这样的基础，使我们选择了这条路。”

总结

信息源

视频来源

Inside the Team That Killed Mandatory Code Review — Quinn Slack, AMP：

外部资料

The End of Code Review:Coding Agents Supersede ...：
Why AMP Quietly Stopped Using GitHub — Quinn Slack, AMP：

AMP 为何悄然弃用 GitHub？AI 代理重塑开发流程

导读

核心结论

观点拆解

1. AMP 的战略核心是主动删除旧功能，以“烧船”方式逼迫用户和团队留在技术前沿 01:14

2. AMP 团队已经彻底取消强制代码审查，前提是用 AI 构建一个高度负责、端到端负责的团队 05:31

3. 本地开发已经过时，云端代理运行是更安全、更高效的软件构建方式 01:47

4. 智能代理正在取代传统软件界面：编程成为最终设置界面，代理成为理想设置界面 08:43

5. GitHub 正在从团队工作流中消失，但不会以戏剧性方式终结，而是被 AMP 托管的临时仓库逐步替代 20:24

6. 代理正在从编程扩展到运维：复杂数据迁移可以由代理分阶段执行并自动监控回滚 14:44

7. 传统 CI/CD 的形态正在被可重复的沙箱环境取代，但 CI 的底层需求反而在增长 25:48

8. Sourcegraph 与 AMP 的拆分是“做对投资者和员工的事”的范式，而非唯一成功路径 29:20

总结

信息源

AMP 为何悄然弃用 GitHub？AI 代理重塑开发流程

导读

核心结论

观点拆解

1. AMP 的战略核心是主动删除旧功能，以“烧船”方式逼迫用户和团队留在技术前沿 01:14

2. AMP 团队已经彻底取消强制代码审查，前提是用 AI 构建一个高度负责、端到端负责的团队 05:31

3. 本地开发已经过时，云端代理运行是更安全、更高效的软件构建方式 01:47

4. 智能代理正在取代传统软件界面：编程成为最终设置界面，代理成为理想设置界面 08:43

5. GitHub 正在从团队工作流中消失，但不会以戏剧性方式终结，而是被 AMP 托管的临时仓库逐步替代 20:24

6. 代理正在从编程扩展到运维：复杂数据迁移可以由代理分阶段执行并自动监控回滚 14:44

7. 传统 CI/CD 的形态正在被可重复的沙箱环境取代，但 CI 的底层需求反而在增长 25:48

8. Sourcegraph 与 AMP 的拆分是“做对投资者和员工的事”的范式，而非唯一成功路径 29:20

总结

信息源

1. AMP 的战略核心是主动删除旧功能，以“烧船”方式逼迫用户和团队留在技术前沿

2. AMP 团队已经彻底取消强制代码审查，前提是用 AI 构建一个高度负责、端到端负责的团队

3. 本地开发已经过时，云端代理运行是更安全、更高效的软件构建方式

4. 智能代理正在取代传统软件界面：编程成为最终设置界面，代理成为理想设置界面

5. GitHub 正在从团队工作流中消失，但不会以戏剧性方式终结，而是被 AMP 托管的临时仓库逐步替代

6. 代理正在从编程扩展到运维：复杂数据迁移可以由代理分阶段执行并自动监控回滚

7. 传统 CI/CD 的形态正在被可重复的沙箱环境取代，但 CI 的底层需求反而在增长

8. Sourcegraph 与 AMP 的拆分是“做对投资者和员工的事”的范式，而非唯一成功路径

1. AMP 的战略核心是主动删除旧功能，以“烧船”方式逼迫用户和团队留在技术前沿

2. AMP 团队已经彻底取消强制代码审查，前提是用 AI 构建一个高度负责、端到端负责的团队

3. 本地开发已经过时，云端代理运行是更安全、更高效的软件构建方式

4. 智能代理正在取代传统软件界面：编程成为最终设置界面，代理成为理想设置界面

5. GitHub 正在从团队工作流中消失，但不会以戏剧性方式终结，而是被 AMP 托管的临时仓库逐步替代

6. 代理正在从编程扩展到运维：复杂数据迁移可以由代理分阶段执行并自动监控回滚

7. 传统 CI/CD 的形态正在被可重复的沙箱环境取代，但 CI 的底层需求反而在增长

8. Sourcegraph 与 AMP 的拆分是“做对投资者和员工的事”的范式，而非唯一成功路径