小软件团队已成历史：AI 代理重塑开发
There's no such thing as a small software team anymore
过去，5 到 10 人的小团队无需担心复杂的部署流程，一天几十次提交就能轻松应对。但现在，随着 AI 代理的普及，一个小团队可能同时运行 20 到 100 个代理，产生数百次提交和合并请求。Uber 曾被视为微服务架构的极端案例，但这种高度模块化的模式正成为应对并行开发的常态。代码的模块化程度直接决定了能同时运行的代理数量。曾经昂贵的拆分成本，如今因 AI 能自动处理样板代码和配置而大幅降低。为了适应 AI 代理的上下文限制，从一开始就设计高度模块化的代码库已成为提升生产力的关键。
Uber 对模块化的处理方式在当时看来可能过于极端，但这或许将成为新的常态。
HN 评论区
175- kstenerud
表面上看，成百上千个机器人修改成千上万个微服务似乎是个好主意，但这些微服务共同构成了一个架构和一个产品。
代理（Agents）并不擅长在上下文里承载整个模型，所以当它们针对一小段代码进行推理时，往往会提出一些损害代码其他部分的方案（尤其是随着 KLOCs 不断累积）。复杂性并没有被消除，只是被转移了。猜猜看，当所有这些微服务变得比现在更加难以捉摸时会发生什么？
AI 确实能提升生产力，但这种做法听起来更像是一场正在酝酿的噩梦。
- davepeck
一位睿智的喷子曾说过：
> 对抗复杂性精神恶魔的最佳武器是这句咒语：“不”
反过来说，我相信小团队可以保持小规模。小团队可以以高速度、高提交量和高品质交付简单的单体应用。服务化并没有因为代理的出现而突然变得低成本；多个独立版本和部署的服务之间的边界依然是难以驯服的野兽。而且也不清楚为什么“运行更多代理”本身就值得追求或能产生重大影响；我的小团队（ admittedly 是轶事证据）的经验是，其价值会迅速饱和。
- ulrikrasmussen
我之前已经评论过，这可能是我很久以来听到的最糟糕的建议，我绝对不允许这家伙靠近任何我需要维护的代码库。
但这本质上就是博客垃圾广告。作者故意放了两张截图，这两张图对他的观点毫无帮助，而且小得根本看不清。当你点击第二张图时，并不会跳转到大图版本，而是被带到他公司网站的主页，上面还是那张同样的截图。
- whatever1
再等两年，等团队里的资深人才流失得差不多了。到时候所有服务每天都会出现中断。
如今只有那些了解系统的资深人员，通过阻止无意义的提交，才勉强维持着系统运行。
一旦他们 burnout 并离职，就没人会知道 LLM 到底干了什么，也不知道服务为什么会挂。
- zkmon
希望人们不要把自动化称为“团队”。如果你仅仅因为它“干活”就叫它团队，那 CPU 核心和线程也是团队，只不过它们没那么概率化（智能）。它们确实能完成工作。
- _345
我真的很怀疑，除非这些 PR 是某个功能的极小碎片，或者全是只需 3 行代码修复的微小 bug（可以瞬间 review 的那种），否则一个人一天怎么可能提交 ~10 个 PR？否则你怎么确认 AI 做的修复或功能是正确的？甚至你怎么确认你想要的功能就是按这种方式实现的？
- pranavmalvawala
有趣的观点。单体应用实际上比微服务更好，因为它们携带了上下文。归根结底，开发者是要运行一个产品，而不是仅仅因为能运行代理就盲目地不停运行它们。
- franciscop
看到 `require('gulp')` 时，记忆瞬间涌上心头。这确实是我们大约 10 年前写代码的方式。我依然不太喜欢每个项目都搞多线程，我更喜欢有两个项目，然后切换上下文窗口；我觉得目前的工具（至少是我知道的那些）在多线程方面有点让人失望。不过我也在努力升级自己的知识。
我发现的一个好方法是，因为我做很多开源项目并且有自己的库，当我在这些库中发现 bug 时，我可以在主窗口继续处理同一个项目，同时在另一个窗口修复库。通常我需要告诉主窗口“这个先跳过，我在修库”之类的。