自动驾驶的公司

我们开始看到一家公司学会自我运作时会发生什么。

过去六个月里，Replit 的工程师代码产出量几乎翻了三倍。评审时间保持稳定。回滚和产品事故数量持平。质量指标提升，发布速度加快。你可能预想的所有典型取舍都没有出现。

虽然代码是看得见的部分，但表面之下发生的事情更有趣。

如今，智能体们负责调查生产事故、审查拉取请求、回答问题、分析业务数据、分类支持工单、研究销售账户、并改进为 Replit Agent 自身提供动力的系统。

感觉就像一个单一的 master 智能体贯穿于每个员工之中，尽管并非如此。它是一个在公司内运作的不断扩展的智能体系统：从人那里获取目标，收集上下文，执行工作，检查结果，并在需要人类判断时升级处理。

我们认为这代表了一种新型组织的开端：自动驾驶的公司。

一个自动驾驶的公司并非没有人的公司。人们仍然选择目的地。他们决定哪些问题重要，做出艰难的权衡，发挥品味，并对结果负责。

但是，他们越来越多地不再执行到达那里所需的每一个步骤。

这种转变始于去年年底。像许多从事 AI 工作的人一样，我们在圣诞假期回来后感觉发生了一些根本性的变化。模型能够维持更长周期的工作。

那些反复失败的任务，比如告警分类和根因调查，开始成功了。AI 开始解决我们一些最顽固的 bug。所以我们不再把智能体当作停留在编辑器或聊天窗口中的工具。我们小心地将它们编织进公司本身的结构之中。

一旦工程团队证明了价值，采用就自然发生了。一个接一个的团队开始将最繁琐的工作外包出去，从而为真正推动业务的战略性和创造性思考腾出时间。人们并不觉得自己被自动化了。他们觉得自己被提升了。

这就是 AI 如何彻底改变我们在 Replit 工作方式的故事。

工程部门最先看到了影响

在一月底，我们加强了基础设施，以快速实验内部智能体用例。我们利用我们的智能体框架、微型虚拟机和远程文件系统基础设施，使得任何工程师都可以并行编排智能体群。然后我们将整个系统锁定在访问策略、令牌代理、审计日志和我们的零信任网络之后。那时，我们觉得可以放心地让智能体访问我们用于完成工作的所有东西：GitHub、GCP、Azure、Linear、Notion、Slack、ZenDesk 等等。

有了跨系统的上下文，我们看到了生产力的飞跃。以前失败的实验变得容易了。最直接的影响体现在编码统计数据上。

我们正处于三月份 Agent 4 发布前的冲刺周，通常这里会有一个大峰值。会议消失，范围确定，工程团队进入纯执行模式（通常每天长达 16 小时）。但这次不同。我们的生产力曲线以我们从未见过的方式向上弯曲，这可以追溯到我们新的内部智能体系统的采用。从一月初到六月底，贡献的代码行数增长了 5.8 倍。

每周更改的代码行数，现有工作流 vs 新智能体工作流

每周更改的代码行数，现有工作流 vs 新智能体工作流

这种增长的其中一部分可以归因于良好的招聘。我们的新智能体加速了生产力提升，这很好，但我们可以移除招聘效应以获得更清晰的数据。保持一致的作者群体，我们看到代码量是以前的 2.9 倍。传统上，如果你在扩展团队时保持每个工程师的产出不变，这被认为是极好的。我们在使团队规模翻倍的同时，每个工程师的产出率提高了三倍。

你可能会想谁在审查所有这些新代码，以及我们是否在审查过程中创造了新的瓶颈。我们的代码审查延迟是平稳的，很大程度上是因为我们让智能体参与代码审查。它现在能够评估风险等级，并且只在必要时才引入第二个人类审查者。这意味着 30%（并且还在增长）的人类拉取请求评审时间被节省了。

随着我们的智能体编写和审查更多代码，我们应该担心质量问题。如果我们看看拉取请求回滚率（左图）和发生的事故，趋势是平稳的。这意味着我们实际上在相对基础上有所改进。

一个原因是这些过程也得到了智能体的辅助。人类代码审查得益于一个智能体共同审查者，因此更多的 bug 被捕获。事故调查（有意义的 bug 或实际事故）由尝试寻找根因的智能体辅助，因此平均缓解时间正在下降。

最后的考验是额外的代码输入是否代表了真正的价值输出。归根结底，工程部门是为用户提供功能的。我们在 Linear 中跟踪项目，以便销售和营销团队知道何时与用户沟通新功能。你可以看到项目完成率与我们的编码量一起急剧上升。

一个自动驾驶的工程团队可以交付更多，同时提高质量。

我们的智能体之智能体正在实现大规模的循环工程

放大来看，可以了解其具体表现。当工程师找到生成循环的方法，派出一队智能体去完成一个可验证的任务时，我们看到了最戏剧性的变化。每个员工都可以访问一个管理器智能体，它可以生成多个智能体，从而实现代表你工作的智能体循环编排。循环产生了一些非常独特的拉取请求图，如下所示：

一位工程师完成了一项长期停滞的 CSS 系统迁移并分享了他的经验。另一位工程师自动化了一项迁移，使我们能够实现产品本地化。还有一位工程师自动化了脆弱的测试维护。我们的 CTO 终于用一群智能体破解了我们最棘手的与 PSC 和文件描述符关闭相关的网络 bug。我们关于可能性的一切假设都改变了。

最令人兴奋的自动驾驶例子来自我们的 AI 团队。他们构建了一个持续学习系统，该系统分析用户反馈，提出改进方案，并使用基准测试和 A/B 测试的组合来验证成果。Replit Agent 正在自我改进！

构建与购买的对话已经改变

我们新的内部智能体也改变了关于我们构建还是购买软件的讨论。我们定期尝试新的 AI 工具。购买解决方案可以帮助我们更快行动，并且我们也在不断评估市场。但我们构建得越多，需要做的这些购买就越少。我们的内部智能体现在已经超越了我们在市场上测试的被视为领先的产品。我们刚刚取消了一个七位数的 SaaS 解决方案，因为完全在 Replit 中构建的内部应用程序更加优越，并且员工已经迁移过去了。

突然间，工具感觉像是为我们量身定制的。与我们的知识库的深度集成以及我们完成的定制化，使得其他解决方案显得逊色。

更令我们惊讶的是，我们的内部智能体也击败了我们评估的垂直特定产品。一个帮助工程师分类告警和根因事故的工具，其质量相似，但成本是在我们智能体上运行的 10 倍。一个运行自动渗透测试的工具发现的漏洞比我们的内部版本少，成本却高出 10 倍。我们的两个版本都轻松投入生产，减少了事故的平均缓解时间，并强化了关键系统以抵御攻击。

考虑到我们仍在学习多少，以及模型在如何改进，很明显这仅仅是开始。

超越工程，进入整个业务

一个自动驾驶的公司不止步于工程。Replit 的每个职能都在发生变化。

使用很快从工程部门传播开来，主要是因为一个 Slack 界面。公司其他部门注意到工程师用任务标记我们的智能体，并自己尝试了。最初，最常见的用例是提问。通过将我们的知识库与代码库状态结合，任何人无需等待工程输入就能明确产品预期。然后这些员工可以跟进修正文案或文档。这立即提升了更快响应用户的能力。

但这仅仅是个开始。从那时起，来自公司各个部分的技能和集成的新贡献开始出现。

第一个重大突破来自我们的数据团队。他们给了智能体一个数据仓库上的语义层，这样它就知道了哪些表是事实来源以及它们之间如何关联。

现在，Replit 的任何人都可以询问商业智能问题并获得可靠的答案。他们可以基于实时数据（包括这篇文章中的每个图表）构建图表和演示文稿。数据团队将时间花在深入研究最困难的问题上，而不是处理请求。最近，一位产品经理能够自助完成复杂的发布分析，因为我们的智能体理解代码库中的事件、它们如何出现在我们的客户数据平台中，以及如何将这些与复杂的订阅状态连接起来。

销售团队也发现了同样的杠杆作用。销售开发团队利用智能体寻找和丰富产品合格的潜在客户，利用更通用的工具无法看到的内部知识，使得外联活动具有更多上下文。客户经理用它来准备客户对话，以了解谁获得了最大价值、哪些项目最活跃、以及信用使用情况如何与合同对比。然后所有这些都打包成针对该账户定制的品牌幻灯片。一个自动驾驶的销售团队与客户有更多、更高质量的接触点。

我们的营销团队可以使用智能体，基于产品和工程中的对话和文档，通过一个提示从头开始起草产品规格。这使他们能够更早开始行动并保持更新，而无需参加每一个会议。他们有更多时间进行规划和创造，这将确保我们的发布在推向市场时产生更大的影响。

我们的支持团队赋予了智能体调查问题和遵循标准剧本的技能。它可以选择以我们标准的客服语气提供回复，或者将工单和调查摘要一并升级到工程部门。一个自动驾驶的支持团队处理最棘手的工单（那些升级给人类的）快了 60%。用户能更快地回到构建中。

在每个例子中，人类并没有被自动化掉。他们被提升了。自动驾驶将执行者变成了主管，而茁壮成长的人是那些以结果为导向并设定方向的人。这是现在最有价值的工作。

—

下一步去哪里？

让自己变得更高效是令人兴奋的，但真正激励 Replit 员工的是民主化技术。

我们想把这种新的工作方式带给所有用户。我们正在努力确保我们能够用大规模部署所需策略、权限、安全和成本控制来做到这一点。Replit 最活跃的用户是在构建真实业务的企业家和商业用户。自动驾驶需要能够扩展以满足这些用户的安全措施。

我们现在正在努力构建它。

鉴于上面的所有图表，你不需要等太久。