生成代码变便宜，谁来决定不做什么？
When Anyone Can Build Software, Who Decides What Not to Build?
生成式模型让写代码变得极其廉价，但这并不意味着企业架构已死。真正的挑战在于，当构建不再昂贵，决定什么值得成为持久承诺的‘判断力’反而成了稀缺资源。代码可以轻易重写，但数据状态、集成依赖和组织习惯一旦形成，就难以消除。如果每个团队都利用 AI 快速构建局部最优解，企业将面临严重的‘不协调’困境。作者指出，瓶颈已从‘构建能力’转移到了‘连贯决策能力’。我们需要在投入之前，先问‘这是否是正确的问题’，而不仅仅是‘如何更好地解决它’。
随着软件构建成本越来越低，不协调带来的代价却越来越高昂。
HN 评论区
34- deminature
用 LLM 构建高质量软件依然非常耗时。绝大多数人根本不会去折腾，无论门槛降得多低，因为时间不是免费的。再加上对大多数人来说，写软件并不有趣，就像组装电子元件对大多数人没兴趣一样。这是一种小众爱好，缺乏大众吸引力。正因这两点，软件行业在 AI 时代依然能存活。
- OakNinja
这个问题并不新鲜。新的是，任何人现在都能通过快速构思和快速原型开发，在不依赖开发团队的情况下理解他们试图解决的核心问题。
和往常一样，接下来还是由公司来决定优先关注什么——这一直都是如此。
* 别仅仅因为花时间在某个点子或提示词输出上，就死守着不放。
* 写代码很容易，维护代码很难。
* 如果不能节省时间或产生收入，那就只是成本。
* 产出并不等于价值。
- CurleighBraces
我觉得事情比这更微妙，至少目前是这样。
说任何人都能构建软件固然没错，但这并不意味着软件质量就好，而且也不能说这完全取决于品味。
举个例子，我现在正在和一位创业者合作，他没有任何编程经验，却成功做出了产品，并且已经卖给了一个中型公司。
然而，如果没有我的参与，以及我懂得如何正确调整 AI 的杠杆，尽管使用了最新的尖端模型并尽力去实现他的需求，软件的表现依然达不到要求。
至少就目前而言，我们仍然需要经验丰富的开发者。
- anonzzzies
我们（我的公司）拥有一个企业级业务线（LoB）‘底座’，在过去四十多年里收集了你能想象到的所有流程。利用这个底座，我们只需观察大企业的流程，然后提出自动化方案，在部门层面实施，这样他们就不需要董事会或 IT 部门的审批就能付费使用。有了我们的底座，SOTA AI 只需一两天就能几乎自动完成这一切，而我们的收费略低于部门的预算。
我们不得不派些刻薄的讽刺型‘项目经理/销售人员’去参加各种会议，因为这些中层管理者总想显得自己有用，所以这些会议对我们来说客观上是毫无意义的，但又是必须忍受的痛苦。这些（现实中的）会议现在当然比（单纯的）技术部分贵得多，即使你把框架的许可费和 SLA 成本算进去。
这些企业，主要是跨国公司，大多由美国、印度或中国的资本拥有，而且它们所有的 IT 部门简直烂透了；还停留在二十年前的 Java 或 C# 上，完全没有动力去改进或学习任何东西；他们听说过 AI，但什么都不用它。
这是一列印钞火车，如果你能在合适的层级切入，无论在哪个地区都价值数十亿。我不确定这能持续多久，因为据我的经验，这些部门里的大多数人今天就可以被运行在 iPhone 上的 LLM 取代；如果你有一个拥有几十年经验的资深顾问，LoB 应用其实挺无聊的；他们肯定在训练 LLM 来做这些事吧？
- ma2kx
我有点困惑。这是个有趣的帖子，但我不确定我是否完全理解他关于‘策略即代码（policy as code）’的意图。他得出结论说‘策略即代码能在没有中央架构职能的情况下实现企业一致性’，我同意这一点，但认为他忽略了今天缺乏基础设施/公司即代码（company as code）。至少如果你想让智能体能够解决，或者至少意识到他最初提出的问题，这是必须的。就像策略定义了我们的工作环境的边界，但并不定义工作本身。这种‘诀窍（know how）’对人类来说大多是隐性的，但对 LLM 却是不可见的，这限制了智能体运行的上下文框架，使其局限于给定的提示词（如果策略在上下文中，可能还会受到策略的约束）。
比如拿他的例子来说：
‘一线员工可能会跳过必填字段，因为该流程给每次客户交互增加了十五分钟的摩擦。’
首先，对于既是必填又可以跳过的字段，策略到底是什么并不清楚。其次，如果跳过它们似乎只会降低摩擦且没有其他后果，那为什么还要设为必填？模型该如何决定是强制这些字段的策略、编写自动化脚本，还是干脆把它们变成选填？