深度|当人人都能写代码:软件工程的大分裂正在发生-夜雨聆风

深度|当人人都能写代码:软件工程的大分裂正在发生

上周，几篇极其有趣的博客和文章先后出现在我们的视野中。它们出自完全不同的语境，作者之间并没有协调，有些人甚至可能会在评论区互相反驳。但当我们依次读完，一幅远比单篇文章更清晰的大图景浮现了出来。

我们迫不及待地想把这幅图景分享给大家。

AI 能写代码了——这已经不是新闻。真正有意思的是这个职业本身正在发生的变异。我们观察到的趋势是：软件工程正在同时分裂为（至少）两个学科。

第一个叫 Harness Engineering（驾驭工程）：构建让 Agent 可靠运行的约束、工具、反馈回路和文档——这本身就是一个全新的行业。

第二个叫 Judgment Manufacturing（判断力制造）：培养能够指导、验证和维护 Agent 产出的人类，尤其是早期职业工程师。

这里有一个容易被忽视但至关重要的细节：借助 Agent，几乎任何人都能做某种形式的 Harness Engineering。但这不意味着软件工程师这个职业会消亡——恰恰相反。普通人会通过”驾驭”Agent 构建大量有价值的软件，但当赌注升高的时候——安全、可靠性、性能、合规、混乱的系统集成，以及任何出错后代价高昂的场景——深层工程仍然不可或缺。

换句话说：你可以通过 Harness Engineering 造出一个能用的系统。但你没法通过 Harness Engineering 绕开物理定律、对抗攻击者、应对生产环境的熵增，以及那些我们尚未完全理解的 Agent 本身。（推荐一篇值得细读的论文——”Agents of Chaos”。）

接下来，让我们逐一拆解这些文章，把拼图还原。

工程师的角色在变：从”写代码”到”造环境”

Charlie Guo 的 “Harness Engineering” Playbook 很好地描述了头部团队正在趋同的方向。OpenAI 正围绕 Agent 重组工程团队，Stripe 的内部 AI 系统”Minions”每周合并超过 1000 个 PR，独立开发者同时运行 5 到 10 个 Agent 并行 shipping——他们甚至不逐行阅读自己发布的代码。

模型能写代码，这已经是 given。瓶颈变成了：你的环境是不是让 Agent “难以犯错、容易做对”？

这就是 Harness Engineering 的一句话概括。

结合 Guo 的文章和 OpenAI 联合创始人 Greg Brockman 的公开分享，我们总结出一套可复制的工程模式：

Agent-first by default——别再把打开编辑器当第一步。如果你能用 5-10 条 bullet 写清需求，先交给 Agent。它负责起草方案和 PR，你负责审批计划和 review diff。

Architecture as guardrails——用严格的边界和允许的依赖路径来约束方案空间，自动化执行结构检查。

Tools as foundation + feedback——通过 CLI/MCP 暴露内部工具，让 CI、lint、测试的报错信息精准到 Agent 可以自行修复。

Memory that compounds——把 AGENTS.md 当成仓库的”疤痕组织”。每次 Agent 失败，记录问题和避免方法，作为可复用的模板、脚本和工具配置跨团队共享。

Plan-first discipline——不让 Agent 上来就写代码。先出方案，review，批准，然后执行。

No slop policy——合并标准不降。每个 PR 都有人类负责人，reviewer 需要理解自己签字认可的东西。

Agent ops layer——像管理生产系统一样管理 Agent。追踪它们的运行记录，集中管理工具权限，把反复出现的失败转化为 harness 改进。

这既是工作流卫生，也是可执行的基础设施。Agent 是工人，Harness 是工厂。你的工作是工厂仍然做不了的事情：判断力、品味、问责。

Bespoke Software 爆发：App Store 模型正在过时

Andrej Karpathy 分享了一个小故事，背后却是一个巨大的隐喻。

他想要一个超级个性化的有氧运动实验仪表盘——八周 zone-2 + HIIT 跑步机追踪。App Store 里不存在这个品类。于是他用 Agent 花了大约一小时 vibe coded 了出来，包括逆向工程跑步机 API、调试单位转换和日历对齐这些典型的”毛边”问题。

他的结论才是重点：当 Agent 能即兴为你生成一个小应用，”从一组离散 App 中挑选”的 App Store 模型本身就在变得越来越过时。未来是 services、sensors 和 actuators 的 AI-native 组合，拼接成按需而生的瞬时软件（ephemeral software）。

Andrew Ng 从经济学角度佐证了同一个趋势：即便每个开发者的效率提升 10 倍，我们也不需要只 1/10 的开发者——因为定制化软件的需求天花板实际上不存在。他已经观察到了早期的”X Engineer”角色——比如 Marketing Engineer、Recruiting Engineer——嵌入业务职能部门、专门为该部门构建软件的人。

两个观点合在一起，指向一条宏观趋势：软件正从一组打包的产品，变成一条不间断的定制化工具流。

我们甚至不确定这还是不是 Software 3.0。以目前的变化速度，或许已经是 Software 4.0 了——”软件行业”这个词的定义本身正在被重写。

重写变得便宜：软件供应链的形状正在改变

Thomas Wolf（Hugging Face 联合创始人）把视角再往外拉了一层：如果重写和理解外部代码库变得便宜，依赖树就不再是超级武器，而开始变成负债。为什么要维护一棵深层依赖树？Agent 可以抽取你需要的部分，或者干净利落地重写。更少的依赖意味着更小的攻击面、更小的包体积，以及通常更快的软件。

Wolf 进而指出”林迪效应”（Lindy Effect）正在减弱。但我们想更精确地表述这一点：Lindy 不是”它存在是有道理的”。Lindy 是一条持久性启发式——如果一个非消耗性事物已经存活了这么久，它倾向于继续存活。但在软件领域，这种存活优势很大程度上被另一股力量撑起来了：替换之痛（replacement pain）。老系统之所以屹立不倒，是因为动它有风险、成本高昂、而且到处是没人愿意重新发现的 edge case。

如果 Agent 改变了这一点，替换之痛就会下降。传统系统会失去它最大的护城河——不管你管它叫 Lindy 还是叫”切换成本 + 恐惧”。

Karpathy 从编程语言的角度呼应了这个判断：翻译（translation）恰恰是 LLM 特别擅长的领域，因为旧代码天然充当了详细的 prompt 和 test oracle。大规模重写现有软件变得可行——而且可能不止重写一次。

这引出了下一个趋势：重写变容易了，但证明你没有搞崩现实世界——这件事没有变容易。

验证：你逃不掉的税

Wolf 的结论也是全文最关键的一条：unknown unknowns 依然 unknown。

如果你能重写一切，你同时也获得了”重新发现旧系统通过纯粹的历史疤痕组织才躲过去的每一个诡异 edge case”的机会。问题就变成了：我们能不能实现测试、边缘情况和形式化验证（formal verification）的完全覆盖？Wolf 认为，在 AI 主导的世界，formal verification 将从”可选”变成”必选”。

Guo 的文章从运营侧切入了同一个漏洞：功能上正确但维护性差的代码正在悄然渗入代码库；Agent 在没有真正 end-to-end validation 的情况下就标记工作完成；把这些新工作流改装到已经运行了十年的 brownfield 系统上更是难上加难。

这就是新的 ground truth：Agent 放大产出的速度，远远快于它放大信心的速度。Harness 有帮助，但验证仍然是那顿饭吃完后必须买的单。

隐藏的危机：入门级人才管道正在坍塌

现在，把上面所有线索连回 Russinovich 和 Hanselman 在 CACM 上发表的那篇论文——这是整个讨论中最直白的”成年人发言”。

他们的点很简单：Agentic 编码助手会放大资深工程师，因为资深工程师已经拥有驾驭、验证和整合 Agent 产出的判断力。Early-in-Career（EiC）开发者没有。同样的工具反而可能拖慢他们，甚至误导他们。这一逻辑引出的经济激励几乎是自动的：雇资深、让 Agent 吃掉初级工作。

来源: Redefining the Software Engineering Profession for AI by Russinovich and Hanselman）

而如果这成为常态，职业的人才管道就会坍塌。下一代资深工程师不是你花钱招来的——是你花时间培养出来的。

来自外部的数据正在印证这个趋势。从 2022 到 2026 年，入门级开发者岗位发布量下降了 67%，实际招聘量更是暴跌 73%。22-25 岁软件开发者的就业人数较 2022 年底峰值下降近 20%。与此同时，35 岁以上工程师的就业反而在增长。54% 的工程负责人表示计划因 AI copilot 的效率提升而减少初级招聘。

一个令人啼笑皆非的数字：美国计算机工程专业应届生失业率达到 7.5%，计算机科学 6.1%——比艺术专业毕业生还高。业界已经有了一个专门的名字：”Junior Death Spiral”——2023 到 2025 年间入门级招聘暴跌近 50%，而”入门级”岗位本身如今往往要求三年以上经验。

Russinovich 和 Hanselman 提出的解是组织设计层面的：Preceptorship at scale（大规模导师制）。让 EiC 与经过培训的资深导师按 3:1 到 5:1 配对，持续一年以上，把人才成长作为显性的组织目标。他们甚至建议 AI 编码助手应当内置一个”EiC 模式”——默认采用苏格拉底式引导教学（Socratic coaching），而不是直接生成答案。