业内探讨：单纯引入AI工具难带来生产力提升

AI所承诺的生产力提升很难被忽视。业界充斥着这样的说法：不拥抱AI的人注定会淡出人们的视野。公司高管们正忙着为开发者配备最新最强的AI工具，往往不惜重金，期望能借此实现这些收益，更多、更快地产出。

但这场在AI工具上的豪掷真的带来了改变吗？工程师们完成的工作更多了吗？还是说，这不过是前沿实验室为了多卖token、支撑其高估值而搞的一场营销？

一方面，AI让一些人觉得自己成了神话般的10倍工程师，原本需要数周完成的工作，如今几天就能压缩完成。另一方面，也有人持怀疑态度，认为引导AI所花的时间，可能和自己动手做差不多。

这场争论并不令我意外。过去几年，我在AI乐观光谱两端的团队都工作过。

一端是那些试图把AI硬塞进现有“以人为本”工作流的团队。他们或许能更快地生成代码，但仍受制于围绕人类开发者构建的系统和流程。

另一端则是那些充分释放了AI潜力、并已成为其最坚定拥护者的团队。他们不把AI仅仅当作又一件工具，而是将其视为一种从根本上不同的软件生产、部署和运维方式。相应地，他们围绕这一新现实重建了工作流和组织架构：软件将越来越多地由机器而非人类来编写和维护。

这种在渐进式采用新技术与围绕新技术彻底重组之间的分野，并非AI独有。在过去的历次技术革命中，这一现象反复出现。

研究电力革命的Paul David将此称为“生产力悖论”：尽管在新技术的初期投入巨大，生产力收益却迟迟未能兑现。早期的采用者只是把电动机“搬过来、装上去”，替换掉蒸汽机，却保留了围绕蒸汽机建立的复杂结构，从中央传动轴到精巧的滑轮系统。直到工厂主们意识到，电动机并非只是更好的蒸汽机，而是一种从根本上不同的驱动机器的方式，他们才开始围绕电动机重新设计工厂。通过让每台机器拥有自己的电动机，他们得以舍弃集中式传动轴，围绕更高效的线性流水线重组生产，最终兑现了电动机所承诺的潜力。

AI的到来也上演着相似的故事。许多人只是把AI搬来装到现有工作流上，很少有人重新思考“AI原生”究竟意味着什么。

随着机器越来越多地编写和运维软件，我们必须设计出机器能够自主理解、从中学习并在其中行动的系统和工作流。实现这一点有三个核心属性：上下文、反馈和自主性。

AI效能的一个关键因素，是它能多容易地获取执行任务所需的上下文。因此，我们的系统应当经过优化，让这些上下文尽可能易于获取。

由此带来的一个影响是，monorepo相比polyrepo具有优势。传统上，polyrepo确实有一些优势，比如在大型组织中更好地隔离团队，以及更容易扩展CI/CD等仓库操作。

然而在AI时代，上下文几乎就是你所需要的一切：在大型团队中，一个中大型组织可能有数百个仓库。要确定实现某个功能需要改动哪些仓库，需要对更大范围的系统有深入理解，而agent很容易遗漏依赖关系或忽略需要更新的仓库。结果是变更不完整的风险更高、失败更多、对人工监督的需求更大。

相比之下，在monorepo中运行的agent获益巨大：它们可以在整个代码库中grep，轻松理解服务之间的依赖关系，并在单一工作区内跨服务进行修改。它们能更容易地运行端到端验证自身工作的测试，并按照全局风格约定生成代码。

在$WORK，拥有monorepo带来的好处数不胜数。agent可以在长时间运行的会话中自主创建大规模变更，范围从UI一直到数据库层，甚至下探到基础设施层（通过Terraform）。这些变更可以一起验证，然后拆分成更小的PR以便于审查。

我们最近甚至决定把原本放在单独仓库中的文档并入主代码库。虽然我认为文档应当保持手写（好的文档需要思考、清晰和理解：没有什么比读一篇冗长、用蹩脚的Claudish写成、却没什么实质内容的文档更糟糕的了），但它们为agent提供了更丰富的上下文来源，使agent不仅能推理系统是如何实现的，还能推理它本应如何工作。这也意味着文档可以受益于与代码本身相同的工具和自动化。例如，我们可以运行由LLM驱动的检查，将文档与底层实现进行比对，在代码演进过程中识别出过时或不准确的章节。让代码和文档并排放置，能大大更容易地确保两者保持同步。

因此，在AI时代，monorepo成为一项显著优势。

让上下文易于获取这一原则，同样延伸到运维和可观测性领域。在AI之前，日志、指标和追踪分散在各自不同的系统中，对工程师来说只是轻微的不便。这让关联事件变得更困难，但在成本节约足以证明其合理性时，人们还是能容忍的。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）