软件开发面临“996”问题

来自：https://www.infoworld.com/article/4094801/software-development-has-a-996-problem.html

让 AI 源源不断地生成劣质代码，然后由人类进行调试和维护，这并不会推动任何企业的业务发展。

图片来源：yucelyilmaz / Shutterstock

软件开发中存在一个根深蒂固且危险的谬误，即认为产出等同于成果。这种观念认为，只要我们投入更多时间或编写更多代码，问题就必然迎刃而解。

以“实用工程师”著称的格尔盖利·奥罗斯最近以手术刀般的精准拆解了这一迷思。针对中国科技巨头们推广的“996”工作文化——即每周六天、从早九点工作到晚九点的作息，奥罗斯提出了严厉的批评：“我很难举出一家实行 996 的公司，其产品值得关注，且并非是对其他地方推出的更优秀产品的复制或翻新。”这种工作安排和节奏不仅不人道，更是counterproductive.

蛮力能带来数量，但很少能带来差异化，或许永远无法带来创新。

在我们开始对中国这种 996 做法嗤之以鼻之前，最好先审视一下自身。创始人们将其包装为“硬核”、“全力以赴”或“奋斗文化”，但本质相同：通过长时间工作压榨员工，期望能从中诞生出卓越成果。如今，我们正试图将这一理念编码化，或者说，通过 GPU 来实现。有些人认为，只要能让大型语言模型（LLMs）以相当于每周千小时的工作强度运行，以超人速度生成代码，我们就能神奇地获得更好的软件。

我们不会。我们只会得到更多已经存在的东西：衍生、臃肿且越来越难以管理的代码。

代码变更的高昂代价

我一直在发出这样的警告。最近我写了一篇文章，讲述了互联网如何被低价值、高产量的内容所淹没，因为我们让内容生产变得毫无阻力。我们的软件也正在经历同样的情况。

我们有数据支持这一观点。正如我在报道 GitClear 对 1.53 亿行代码的 2024 年分析时所指出的，“代码流失率”，即在两周内被更改或丢弃的代码行数，正在激增。研究显示，复制粘贴的代码更多，而重构的代码显著减少。

换句话说，人工智能正在帮助我们更快地编写代码（根据 GitHub 的分析，速度提升高达 55%），但它并未帮助我们构建更好的软件。我们正在生成更多的代码，却对其理解得更少，修复的频率也更高。人工智能的真正风险不在于它编写代码，而在于它鼓励我们编写过多的代码。臃肿的代码库更难保障安全，更难以推理，对人类而言也更为难以掌控。代码越少越好。

这是 996 思维转移到机器上的陷阱。996 思维认为创新的限制在于工作小时数。“AI 原生”思维则认为限制在于输入的字符数。两者都是错误的。限制始终是，也将永远是思维的清晰度。

代码是负债，而非资产

让我们回归基本原则。正如任何资深工程师所知，软件开发并非打字比赛，而是一个决策过程。这份工作与其说是编写代码，不如说是决定哪些代码不该写。正如 Honeycomb 创始人兼首席技术官 Charity Majors 所言，成为资深软件工程师“更多关乎你长期理解、维护、解释和管理生产环境中大量软件的能力，以及将业务需求转化为技术实现的能力。”

你交付的每一行代码都是一项责任。每一行代码都需要被保护、调试、维护，并最终重构。当我们使用人工智能粗暴地完成软件的“构建”阶段时，我们实际上是在最大化这种责任。我们创造了巨大的复杂性表面，这或许能解决眼前的 Jira 任务，但却以牺牲平台未来的稳定性为代价。

Orosz 关于 996 公司生产复制品的观点颇具启发性。创新需要“余裕”来思考，而不被频繁的会议打断。在安静的时刻，你可能会意识到你即将构建的功能其实并不必要。如果你的开发者们整天都在审查如雪崩般涌来的 AI 生成的拉取请求，他们就没有余裕。他们不是建筑师；他们是在一个永不休息的机器人身后打扫卫生的清洁工。

这并不意味着 AI 对软件开发有害。恰恰相反，正如哈佛大学教授（也是长期的开源领域杰出人物）Karim Lakhani 所强调的，“AI 不会取代人类”，但我们越来越会看到“拥有 AI 的人类将取代没有 AI 的人类”。AI 是一个有效的工具，但前提是我们将其作为工具使用，而不是作为复制 996 文化虚假承诺的棍棒。

技术栈中的人性因素

那么，我们如何避免在硅基上构建“996”文化呢？我们需要停止将 AI 视为“开发者替代品”，而应将其作为一种工具，用以赎回“996”文化所摧毁的东西：时间。

如果人工智能能够处理那些繁琐的工作——单元测试、样板代码、文档更新——这不应成为在冲刺阶段塞入更多功能的借口。相反，这应当是一个放慢节奏、专注于技术栈中“人性化”部分的机会，例如：

• 问题的界定。“我们究竟要做什么？”听起来简单，但正是大多数软件项目失败的地方。选择正确的问题是一项高语境、高同理心的任务。LLM 可以给你五种构建小部件的方法；但它无法告诉你这个小部件是否不适合客户的工作流程。
• 无情地删减。如果 AI 让编写代码几乎零成本，那么最有价值的技能就变成了删除代码。人类必须掌握“说不”的权力。我们需要奖励开发者，不是因为他们提交代码的速度，而是因为他们设计的简洁性。我们需要赞扬那些“负代码”提交：那些减少复杂性而非增加复杂性的提交。
• 掌控影响范围。当系统出现故障时（这种情况不可避免！），事故报告上署名的将是你，而非 LLM。在系统中断期间，深入理解系统以进行调试的能力，若你从未亲自编写代码，这一技能将会退化。我们必须确保“AI 辅助”不会演变为“人类脱离”。我强调了确保初级开发者不盲目依赖 LLM 输出结果的重要性。我们需要提供充分的培训，以确保各技能水平的工程师都能有效利用 AI。

反抗机器人式废话并非反对技术进步，而是关乎质量。

Orosz 对 996 的批评在于，它造就了疲惫不堪的人和容易被遗忘的产品。如果我们不够谨慎，我们对人工智能的采用将产生完全相同的结果：疲惫的人类维护着一大堆由机器生成的、易被遗忘且脆弱的代码。

我们不需要更多的代码，我们需要更好的代码。而更好的代码源自那些拥有宁静、无干扰空间以进行创新的人类思维。让 AI 处理繁重的任务，从而解放人类去创新。