InfoWorld 资深撰稿人 Matt Asay 近日发布了一篇名为“Software development has a ‘996’ problem”的文章,深入探讨了 AI 盛行下软件开发领域存在的一种误区,即认为产出等于结果。这种观点认为,只要投入更多的时间或更多的代码行数,就一定能解决问题 —— 肖似 996 核心理念。
《The Pragmatic Engineer 》杂志的创始人 Gergely Orosz 最近就对这一迷思进行了驳斥。他对“996”工作文化提出尖锐的批评称:“我很难举出一个真正值得关注的‘996’公司,它们的产品要么是抄袭,要么是炒冷饭,都是对其他地方已经推出的更优秀产品的简单复制。”
但一些创始人试图将其包装成“硬核”、“全力以赴”或“苦读文化”,本质上却是一样的:用大量时间压榨员工,然后期待最终能产出惊世之作。有些人认为,只要能让大语言模型(LLM)每周工作相当于上千小时,以超人的速度生成代码,就能神奇地获得更优秀的软件。
Matt 指出,这种不人道的工作时间和节奏只会适得其反。蛮力鲜少带来差异化,而且(或许)永远无法带来创新。“我们不会。我们只会得到更多我们已经拥有的东西:衍生代码、臃肿的代码,以及越来越难以管理的代码。”
在互联网被低价值、高数量的内容所淹没的同时,同样的情况也正在软件行业发生。研究表明,“code churn”(即两周内被修改或丢弃的代码行)正在激增。复制粘贴的代码越来越多,而重构的代码则显著减少。
换句话说,人工智能(AI)确实能帮助我们更快地编写代码(速度提升高达 55% ),但它并没有帮助我们构建更好的代码。我们生成的代码更多了,对代码的理解却更少了,而且需要更频繁地修复。AI 真正的风险不在于它能编写代码,而在于它促使我们编写过多代码。臃肿的代码库更难保障安全性,更难进行逻辑推演,也更难让人类真正掌握。代码越精简越好。
Matt 称,这就是将“996 陷阱”在机器时代的变体。“996思维”认为创新的制约因素是工作时长。“AI-native”思维则认为制约因素是输入的字符数。两者都是错误的。真正的制约因素始终是思维的清晰度,过去如此,未来亦然。
正如 Honeycomb 的创始人兼首席技术官 Charity Majors 所说,资深软件工程师“更看重的是你理解、维护、解释和管理大量生产环境中运行的软件的能力,以及将业务需求转化为技术实现的能力。”
你发布的每一行代码都是一种隐患。每一行代码都必须经过安全检查、调试、维护,最终还要进行重构。当我们使用 AI 来蛮力推进软件的“构建”阶段时,这种隐患被无限放大。我们制造了大量的复杂性,这些复杂性或许能解决眼前的 Jira 问题,但却会损害平台的未来稳定性。
创新需要“闲暇时间”,才能在不受会议不断干扰的情况下进行思考。如果能抽出一点时间安静下来,你可能会意识到你原本打算开发的功能其实是不必要的。如果开发人员每天都在审查 AI 生成的海量拉取请求,就丧失了这种闲暇时间。从此也不再是架构师,而是在为一台永不眠的机器人打扫卫生的清洁工。
当然,Matt 并非暗示 AI 对软件开发有害。恰恰相反,他引用了哈佛大学教授(也是开源领域的长期领军人物)Karim Lakhani 所说的话,“AI 不会取代人类”,但我们将越来越看到“拥有 AI 的人类将取代没有 AI 的人类”。AI 是一种有效的工具,但前提是将其作为工具而非棍棒使用 —— 切勿借此复制 996 工作文化的虚假承诺。
为了避免这一趋势,Matt 认为应停止将 AI 视为“开发人员的替代品”,而应该将其视为一种工具,用来弥补 996 文化所摧毁的那样东西:时间。
当 AI 能承担重复性工作时,这不应成为在迭代周期内塞入更多功能的借口。相反,这恰恰是放慢脚步、聚焦技术栈中“human”环节的契机,例如:
Orosz 对 996 的批评在于,它造就了精疲力竭的人与平庸无奇的产品。如果我们不谨慎,我们对 AI 的应用也会产生同样的结果:疲惫不堪的人类维护着机器生成的大量容易被遗忘且脆弱的代码。
我们不需要更多的代码,我们需要更优质的代码。而优质代码源于人类的头脑 —— 需要宁静无扰的空间才能孕育创新。让 AI 来处理繁琐的工作,从而释放人类进行创新。
(文/开源中国)