一位工程师：AI写代码后，胶水工作不是更多而是更少

我并不信奉胶水工作[1]。那些只能靠工程师无偿牺牲来维持的流程，理应消亡。

如今LLM正在编写我们的大部分代码，这是否能让人类工程师腾出手来做更多胶水工作？不，不能。我认为胶水工作对公司来说实际上比2010年代更不重要了。让我们逐一看看四个原因。

第一，AI减少了交付所需的协调量。AI代理的放大效应意味着，现在任何一名工程师都能承担以往需要一个小组才能完成的项目。很多胶水工作都是协助协调：预订启动会和状态会、传递内部更新等等。而一名工程师完全不需要做这些。

第二，2020年代的工程师已经不太需要“小心伺候”了。以我的经验，基于协调的胶水工作中最重要的一类就是管理难搞的人。许多公司都有秘密守门人：影响力巨大、自尊心极强的工程师，如果觉得没有被充分征求意见，就会否决你的项目。我以前写过，一些团队在结构上就是守门人，也写过一些工程师在2010年代如何靠着对一切说“不”就能混日子。ZIRP的终结改变了这一切。许多最难搞的守门人被赶出了行业，或者被迫改变了态度，这也就减少了交付所需的必要胶水工作。

第三，企业雇用初级工程师的人数减少了。这对行业来说可能是坏事，但确实也消除了一大类胶水工作。有经验的员工不需要太多手把手的指导，所以公司也不再需要有人默默自愿地引导新人入职。

第四，只写不读的报告可以用LLM自动化。很多胶水工作就是我所说的“工作量证明”：写一份报告来表明你了解团队在做什么，或者填写模板以满足某些法律要求。这类工作通常没人愿意做，所以靠的是有人自愿“充当胶水”。现在这类报告可以借助LLM快速产出。没有读者愿意读LLM文本这一点其实无所谓，因为这些报告的意义从来就不是被人阅读。

LLM能直接把所有胶水工作都自动化吗？绝对不行。许多工程师正出于一种躁狂的乐观主义试图这么做，但这真是个糟糕的主意。只写不读的报告是一回事，但与工程师同行交流这件事不能委托给LLM。当你需要询问项目状态，或者回复别人的ping，或者诸如此类的事，你应该亲自起草并写下这条消息。没有什么比让其他工程师去和你的Claude Opus实例对话，更快地烧毁你与他们关系的方式了。

那么这一切让我们处于什么位置？我想，基本还是2024年的位置。要不惜一切代价避免成为“胶水工作者”，让糟糕的流程失败以便它们能被改变，但要愿意去做少量战术性的胶水工作——只要它们能切实促进你项目的成功。你大部分时间和精力仍应花在代码上：驱动AI代理，并使它们与公司的价值观保持一致。

[1] 胶水工作是指构建软件过程中所有软性的“非技术”工作：确保团队之间互相沟通、撰写报告、更新文档、引导新人工程师入职等等。具体而言，就是那些不属于正式流程、只有有人自愿去做才能真正完成的工作。关于我为什么不喜欢它，详见我2024年的文章《胶水工作是有害的》。