
Aleix Morgadas 谈 Agentic Development 与工程策略
来源标题:Agentic Development and Engineering Strategy
Aleix Morgadas 在博文中指出,把公司战略称为「AI Strategy」反而暴露对现状缺乏判断,这与当年「Cloud Strategy」「DevOps Strategy」如出一辙。他认为 LLM 与 Agent 在企业中的采用极为分散,并聚焦讨论如何用 Agentic Development 构建产品,及其对 buy vs. build 决策的影响。
以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
Aleix Morgadas 2026年10月10日 6 2 2 分享 如今很难不把AI与战略联系在一起,但在公司里把它称为“AI战略”可能反而说明你缺乏对局势的认知。过去“云战略”“DevOps战略”“移动战略”之类的说法也是同样的道理。 这些术语含义丰富,同时又可能毫无意义。 所谓“战略表演”,就是用流行词和看似高深的概念营造出一种高层思维的假象。Richard Rumelt 把这种现象叫作“空话”。 事实是,LLM 和 Agent 建立在这些之上,并且在我所见过的公司中,它们的采用方式最为“正交”——彼此独立、互不干扰,涉及领域包括但不限于: 我们如何用 Agentic Development 构建产品。👈 本文主题。 以及这如何影响“自建还是购买”的决策,等等。 产品在具备新的 agentic/AI 能力后会呈现怎样的行为,即 AI 产品。 我们如何支持客户,从人工流程转向 AI 工作流。 上述每个领域都需要各自理解 AI 对其的投资影响,以及如何衡量这种影响。一家公司可能全部投入,也可能一项都不投。 今天我聚焦第一点。如果你希望我探讨另外两点,请在评论区告诉我。 工程战略,是我们从技术角度应对 高利害业务挑战的方式。 高利害业务挑战才是这里的关键。我们知道它是什么吗?还是我们在盲目照搬市场趋势? 我想目前还没人会因为从 Anthopic 采购而被解雇。🤷 上述每一点都值得单独写一篇文章;眼下我只想分享一份草稿清单,列出我在每个部分正在探索的想法,外加一些个人化、有偏见的观点。 新实践 LLM 和 Agent 确实影响了我们的工作方式。影响是好是坏并不重要,因为我们仍在学习新的工作方式。 它们要稳定下来还需要时间。 目前,LLM 的商品化正在催生新的高阶系统,而方法论也在与之协同演化。 Agentic Development 改变了整个软件开发生命周期(SDLC)。如果添加代码的时间成本大幅下降,瓶颈就会转移到别处。最明显的是 PR 评审时间;其次是产品定义、影响衡量,某些情况下还有 QA。 不过,瓶颈一直都是决策。现在这一点更明显了。代码是瓶颈……我们可以说它从来都不是。 如果构建成本下降,购买就显得昂贵。购买会带来一些影响: 无法完全实现业务认为对用户至关重要的那个“小东西”(剧透:它通常确实至关重要……)。 但还有一项新成本:维护/运行。构建很有趣,维护……就没那么有趣了。 我们正在制造超出自身承受能力的遗留系统。 一个我们现在就需要维护的遗留系统。 对于没有 DevOps 文化的公司,这影响更大。因为构建它的人并不负责运行它。我们把大量工作推给了 SRE 团队。向所有 SRE 送上拥抱。🫂 所以,在没有 DevOps 文化的情况下用 AI 构建,会在维护成本上形成断裂的反馈回路。 我的建议是,去问问 SRE 团队如何应对 AI 带来的吞吐量增长。和他们坦诚交流,了解他们的痛点和抱怨。这有助于你理解社会技术系统的动态。 AI 有一种倾向:它只处理已知的东西,因为训练数据就是这些。若未意识到这一点,我们可能会快速造出已有的产品/方案——那些因为人人都有而卖不出去的东西。 用领域驱动设计的术语来说,可以这样看: 支撑子域:适合使用 AI,因为我们希望在一些预期之内但并不独特的事情上快速推进。借助 AI,我们能比以前更快地拿到基线。 核心子域:这是你的产品差异化所在,是你力求独特的地方。使用 AI 可能把我们引向错误的方案——一个现有的方案,而非创新的方案。 我在 这里 更详细地探讨了这个话题。 AI 与软件架构 Aleix Morgadas · 10月2日 阅读全文 如何衡量影响? 要理解影响,有大量工作要做:从 DORA 指标到新指标,从识别瓶颈的系统到(试图)衡量 ROI 的新方法。 今天,我并不确定如何真正衡量影响。我们确实看到了: 不稳定系统增多。系统需要承受变化率的巨大增长。 每一次新的改进都会把瓶颈转移到新的位置,这既创造了改进机会,也创造了可销售的新产品。 尽管如此,把产出的增长与成果联系起来仍然很有挑战。我看到了一些改善,但我们不应低估: 更高的变化率并不等于收入。用户采纳新产品/功能需要时间。采纳不是线性的。 DX 团队可能是最投入于用科学方法理解生产力的一方。要了解如何衡量影响,我一定会去看看他们的做法。 不同的人和部门之间,采纳率总是不同。帮助人们采纳新工具和新工作方式,没有最佳方法。 我发现最好的做法是根据公司所处阶段调整方法: 所有人以不同方式学习同一件事:目标是快速实验和学习,即使人们学的是同样的东西,可能重复了努力。 集中化政策/建议:在完成学习之后,帮助人们利用适合公司情境的良好实践。 今天我不会押注于只选一个供应商,比如只从 Anthropic 采购。每家公司都在根据自身激励设计一套产品组合。锁定单一供应商或许能简化事情,但也让你受限于一家公司的思路。
(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。