Newshot 我不信奉 glue work1。只能靠工程师无偿牺牲来维持的流程，本就该消亡。
既然 LLM 现在写掉了我们的大部分代码，这是否就解放了人类工程师，让他们去做更多 glue work？不，并没有。我认为，如今 glue work 对公司的重要性其实低于 2010 年代。下面给出四个原因。
第一，AI 减少了交付所需的协调量。AI 智能体的放大效应意味着，任何单个工程师现在都能承接过去需要一个小团队才能做的项目。大量 glue work 原本是在协助协调：预订启动会和状态会、传递内部更新等等。单个工程师不需要做这些。
第二，2020 年代的工程师需要更少的“小心对待”。在我的经验里，基于协调的 glue work 中最重要的子类，是管理难搞的人。许多公司都有秘密守门人：那些影响力过大、自尊心极强的工程师，如果你让他们觉得自己没被充分咨询，他们就会否决你的项目。我以前写过，有些团队在结构上就被设置成守门人，以及一些工程师在 2010 年代如何基本靠对一切说“不”就能混得过去。ZIRP 的终结改变了这一切。许多最难缠的守门人已被迫离开这个行业，或被迫改变态度，这减少了交付所需的必要 glue work 数量。
第三，人们招聘的初级员工更少了。这对行业来说大概是件坏事，但它也确实消除了一大类 glue work。有经验的雇员需要更少手把手指导，所以公司不需要有人悄悄自愿地去带新员工入职。
第四，只写不读的报告可以用 LLM 自动化。大量 glue work 是我所说的“工作证明”：写一份报告来证明你清楚你的团队在做什么，或者填一个模板来满足某些法律要求。这往往是谁都不想去做的工作，所以它依赖某个人自愿去“当胶水”。现在这类报告可以用 LLM 快速产出。没人想读 LLM 生成的文本，其实并不重要，因为这些报告的重点本来就不是被读。
LLM 能直接自动化所有 glue work 吗？绝对不能。许多工程师正出于一种狂热的乐观去尝试这么做，但这是个非常糟糕的主意。只写不读的报告是一回事，但与其他工程师沟通不能委托给 LLM。当你需要查看项目状态、回复别人的 ping，或做任何类似的事情时，你应该自己构思并写出消息。没有什么比让别人去跟你的 Claude Opus 实例说话，更快地毁掉你与其他工程师的关系了。
那么这把我们带到哪里？我想，大致还是 2024 年的位置。不惜一切代价避免成为“做 glue work 的人”，让糟糕的流程失败，这样它们才能被改变，但要愿意做少量战术性的 glue work，在它能切实促进项目成功的地方。你的大部分时间和精力仍应花在代码上：花在驱动 AI 智能体，并让它们与公司的价值观保持一致上。
- glue work 指的是构建软件过程中所有软性的“非技术”工作：确保团队彼此沟通、写报告、更新文档、帮助工程师入职等等。具体来说，它是这类工作中未被纳入正式流程的部分，而且只有在有人自愿去做时才会真正完成。关于我为什么不喜欢它，更多内容见我 2024 年的文章 Glue work considered harmful。 ↩
如果你喜欢这篇文章，可以考虑订阅我的新文章邮件更新，或者在 Hacker News 上分享它。
下面是另一篇与本篇共享标签的相关文章的预览。
软件业的半人马时代可能持续数十年我们目前正生活在半人马时代（2022-20??）。眼下，与 AI 编码系统配对的人类工程师，比二者各自单独工作时更高效。对于未来几代软件工程师——无论是人类还是其他形态——这将是关于当前时期最重要的事实。正如国际象棋自身的半人马时代一样，人们总是乐于宣称半人马时代已经结束，AI 至上时代已经开始。但国际象棋的半人马时代持续了大约二十年，而此前的半人马时代持续得久得多。继续阅读...
软件业的半人马时代可能持续数十年
我们目前正生活在半人马时代（2022-20??）。眼下，与 AI 编码系统配对的人类工程师，比二者各自单独工作时更高效。对于未来几代软件工程师——无论是人类还是其他形态——这将是关于当前时期最重要的事实。
正如国际象棋自身的半人马时代一样，人们总是乐于宣称半人马时代已经结束，AI 至上时代已经开始。但国际象棋的半人马时代持续了大约二十年，而此前的半人马时代持续得久得多。继续阅读...