在我二十多岁时，笑容常挂在我的脸上。最初我并未察觉，但和我熟悉的人都会注意到这一点，大多数情况下，这被视为一种正面的特质。
然而，有次一位软件工程师用困惑和担忧的眼神问我:“你为什么总是这么快乐?”
这个问题让我有些意外。据我所知，我拥有一切应当让人感到快乐的条件:我刚加入了一家我非常喜欢的公司，担任的职位与我的专长高度匹配，同事们都是才华横溢且工作热情高涨的人。更重要的是，我们正在享受公司赞助的部门晚宴，这是一周紧张工作和会议后的轻松时光。在这样的环境下，谁会不快乐呢?
答案出人意料:软件工程师。
当我环顾整个房间，忽略那些热情洋溢的高级管理人员、愉悦的项目经理和乐观的用户体验设计师后，我看到了另一幅画面，一幅令人担忧的画面。
我们团队里最资深的工程师独自坐在吧台前，下巴放在手掌上，由于头部压力，肘部已泛红。他另一只手的食指在吧台上随意地划来划去，显然心情并不好。
在房间的另一个角落，四名工程师围成一个小圈子。其中一人正用手势激动地解释着某个问题，而其他人显然是在不耐烦地等待他结束，以便他们能发表自己的观点。他们的面部表情都很严肃。
后来我了解到，他们当时正在讨论一个表面上看似微不足道，但实际上非常有争议的问题:数据库中第一条记录的 ID 应该是0还是1?
这让我明白了，那名先前觉得我总是快乐的软件工程师为何会有这样的疑惑。作为一名编程专家，我为何总是笑容满面呢?
如今，我38岁，肩负着一对婴儿双胞胎和一个三岁孩子的父亲角色。同时，我还是一家拥有30名员工的初创公司的创始人和 CEO。这家公司为数百家企业提供关键的身份验证服务。面对这么多身份和责任，额头上的皱纹加深、体型微胖、头发渐白，以及眼下的黑眼圈都似乎成了理所当然的事。
然而，这些身体和精神的消耗主要源于一个因素:我依然在编程。
请不要误解，我对编程依然充满热情，只是现在人们不再因为我的乐观而称赞我。
我并非孤例。Cobalt 最近发布的研究报告调查了超过600名网络安全和软件开发专业人士，揭示了一些令人震惊的现象:
58% 的受访者正面临职业倦怠。
53% 的受访者考虑辞职。
63% 的受访者认为工作对他们的心理健康有负面影响。
64% 的受访者认为工作对他们的身体健康有负面影响。
回头看看我以前的工程师同事，几乎所有人都已经不再进行日常的代码编写工作。事实上，许多人已经完全退出了科技行业。
“哦，这有什么大不了的?”你可能会这样想，“坐在700美元的椅子上，穿着睡衣，在3000美元的 MacBook Pro 前工作8小时，一周几天，有什么难受的呢?”
现在，让我来告诉你。
为什么软件工程如此困难?
根据我的经验，如果你选择软件工程仅仅是为了赚钱，你在这个领域里可能走不远。事实上，对于大多数开发者来说，有数百个其他职业路径可以提供同样或者更高的薪资、声誉和职业满足感。
我们可以从另一个角度来深入了解编程如何影响个体情感。面对各种挑战，为什么人们还是坚持下去?这些坚持的原因通常是高度个人化和深刻的，但当你与足够多的人进行交流后，你会发现一些反复出现的主题。
编程不仅是一种技术活动，更是一种高度创造性的过程，它常常触及到思想和情感的深层。有时候，人们会以一种程序员完全没法预见或者想象到的方式，来利用这些创新成果。也许，没有什么比创造出别人能够欣赏和使用的产品更能体现人类创造力的纯粹性。
在这方面，1975年软件工程经典著作《人月神话》的作者弗雷德里克·布鲁克斯是最有发言权的人。这些论文不仅历久弥新，而且具有近乎神秘的相关性。以下是我最喜欢的一段文字，摘自名为 “工艺的乐趣” 的章节。
布鲁克斯还描述了编程的另一面，这一点体现在名为 “工艺的困扰” 的章节中。
这篇文章写于1975年。
延续布鲁克斯的思想，我发现编程中的乐趣与困扰往往是交织在一起的。我最自豪的编程成就往往来自那些几乎让我精疲力尽的项目。解决了长期困扰我和我的团队的 bug 会带来巨大的成就感。然而，这种成就感与陷入绝望时的沮丧是密不可分的。比如，花数小时去调试程序中一些令人困惑的行为，最后却发现问题仅仅是因为我写了 “initializer” 而非 “initialize”。这样的经历对于我们中的大多数人来说，是一种无休止的循环。难怪在社交场合中，很少有人笑得出来。
数十年来，我们经历了计算能力的指数级增长、先进开发工具的出现，以及编程语言变得更加人性化。那么，为什么布鲁克斯的观点在今天仍然有强烈的共鸣呢?
概念压缩与走向 AI 的路径
在我11岁时，我梦想着能制作一款属于自己的游戏。
那一年，我在公共图书馆找到了一本名为《游戏编程大师的技巧》的书。书的封面设计得非常酷，仿佛是一款类似于 DOOM 的第一人称射击游戏的包装。我心想，“这就是我要的。”我随手翻开了书的某一页，记得非常清晰，我看到了这样一个图表:
我仔细翻阅了整本书，试图找到任何我能理解的、或者看起来稍微“像是游戏”的内容。结果一无所获。于是，我失望地合上了书，从此以后，我再也没有告诉任何人我曾经想成为一名游戏工程师。
然而，因为“概念压缩”的存在，下一代有志于游戏开发的年轻人会有全新的体验。
以2015年为例，一个名叫 Toby Fox 的23岁年轻人发布了一款名为 “传说之下（Undertale）” 的游戏。这款游戏完全是在他个人的家用电脑上开发完成的。尽管这款游戏是自主发布的，但它成功卖出了数百万份，并获得了业界的一致好评。许多媒体甚至将其评为“年度最佳游戏”，击败了许多拥有巨额预算的 AAA 级游戏。
“传说之下” 是在一个名为 Game Maker Studio 的可视化工具中开发的，这正是概念压缩的体现。
概念压缩 是由 David Heinemeier Hansson（DHH）首次提出的，他是 Ruby on Rails 的创始人。这个 Web 开发框架不仅对我的整个科技职业生涯有着不可或缺的影响，也对我所在的 Kolide 公司非常重要。简单来说，概念压缩描述了编程从底层的二进制语言，到更接近自然语言的 Ruby，再到如今的低代码或无代码工具，以及 LLM(Language-agnostic Low-code Model)的发展过程。
Hansson 创造这个词组的博客文章 摘录:
“概念压缩”不仅让 Toby Fox 能够开发出“传说之下”，还极大地推动了软件工程领域新人的增长。然而，这些新入行者同样需要面对这个行业带来的各种挑战和困扰。简而言之，在降低编程的心理和情感负担方面，让编程“更易接近”并不意味着它也“更易操作”。
在开发“传说之下”的续作过程中，Toby Fox 在多个进度报告中分享了他的经验。他谈到了更换游戏引擎所导致的时间损失、与其他工程师合作的挑战、由长时间编程引发的手腕疼痛，以及因项目周期过长（已达8年并仍在进行）而导致的睡眠问题。
那么，为什么即使“概念压缩”增加了进入这个领域的人数，编程本身却并没有变得更简单呢?尤其是对于那些在新型“概念压缩”技术出现之前就已经在这个行业工作的人来说。
事实上，这里的情况相当复杂。虽然这些技术进步让编程变得更容易，但并没有从根本上降低编程所需的劳动强度。要理解这一点，我们需要讨论一个在软件开发领域长期缺失的概念——那就是“银弹”解决方案。
ChatGPT 对开发者来说是银弹吗?
Fred Brooks 在1986年的具有里程碑意义的论文《没有银弹——软件工程的本质与偶然》中开篇便提出了一个与本文讨论密切相关的观点:
尽管我建议你完整地阅读这篇文章，但其中一个核心观点是他对两种不同类型复杂性的讨论:偶然复杂性和本质复杂性。Brooks 强调，这些复杂性是编程工作中不可或缺的因素，因此没有所谓的银弹能完全解决这些问题。
偶然复杂性:工具导致的问题
在软件工程领域，偶然复杂性是指由我们用于完成任务的工具和抽象层带来的复杂性。这种复杂性也常被称为附加复杂性，因为它与工程师试图解决的核心问题几乎无关，主要是因为我们使用的工具局限性导致的不必要复杂性。例如，编程语言、库、框架、测试方法、Web 服务器，以及用于数据库查询的语言都是偶然复杂性的来源。
需要明确的是，“偶然”并不等于“不重要”。实际上，许多开发者经常遇到的问题往往与这种偶然复杂性有关。
编程中对人完美执行的高要求就是一个偶然复杂性的例子。与大多数偶然复杂性一样，这种复杂性可以通过改进工具和流程来减轻，甚至有可能在未来完全消除。Brooks 也没有否认这一可能性。
本质复杂性:问题固有的挑战
在软件工程领域，本质复杂性是与你所要解决的具体问题紧密相关的复杂性。以主题公园（如迪士尼乐园的 FastPass）的游乐设施预约系统为例，无论你选择何种编程语言来实现这个系统，都需要解决一系列固有的复杂问题，以确保软件的实用性。我们将在后文进一步深入探讨这个案例。
本质复杂性也是导致开发难度增加的主要因素之一。你是否曾经想过，为什么程序员需要掌握如此多看似无关紧要、但实则极其复杂的细节呢?这些都是他们在多年的职业生涯中不得不面对的本质复杂性。
以斯坦威钢琴工厂的员工为例，他们可能并不需要知道如何演奏钢琴。然而，对于那些需要为数字音频软件开发一个模拟斯坦威钢琴音效的插件的程序员来说，情况就不同了。为了精确地完成这项任务，他们不仅需要了解钢琴的基本工作原理，还需要对和声学和共振有深入的认识。甚至还需要掌握一些难以用语言描述的知识。这些知识更多地依赖于感觉和经验。
那么，斯坦威钢琴的音色为何如此引人入胜?它与其他如 Bösendorfer 或 Bechstein 钢琴有何不同?想要在数字音乐领域做出有意义的贡献，程序员必须全面了解这些因素。这也是他们常感到压力巨大的原因。在面对这些本质复杂性时，为了在这由“纯粹思想”构成的领域中脱颖而出，我们不仅需要对完美执行有高要求，还需要精细地管理和掌控这些复杂性。
几乎所有软件工程的进步都更多地减少了偶然复杂性而非本质复杂性。这甚至包括像 ChatGPT 这样的大型语言模型（LLMs）。
大型语言模型（LLMs）可以视为一种数字化的信息中心，能即时访问各种重要数据。在最理想的情况下，这些模型能够理解人类在书籍、互联网以及其他计算机相关文档中的所有有价值的信息。
经过训练后，LLMs 能根据输入的提示进行概率性的回应。对于每一个可能的回应词或“token”（可能是一个完整的词或词的一部分），模型会计算该词作为下一个词出现的概率，基于其在训练数据中观察到的模式。这个过程就像是一个基于训练数据来猜测“下一个 token 会是什么”的游戏。
令人惊讶的是，这种看似简单的方法已经是我们目前能够实现的最接近人类智能的技术。ChatGPT 的最新版本甚至能完成大多数高中、大学和研究生级别的任务。它们也能通过律师资格考试，尽管这更多地反映了我们的考试方式，而不是模型本身是否能成为优秀的律师。尽管我不希望看到一个全由 LLMs 编写的书籍世界，但我必须承认，不能忽视它们的能力和潜力。特别是，它们在减少软件工程中偶然复杂性方面表现出色。
正因为 LLMs 的高度灵活性，它们可能是迄今最有效的工具，用于减少偶然复杂性对工程师时间的影响。LLMs 不仅能将你不熟悉的编程语言翻译成你能理解的语言。它们还能教你如何高效地使用之前未接触过的工程工具，并甚至能帮助你发现编译器和 linting 工具难以识别的代码错误。
更重要的是，与以往任何工具不同，LLMs 是我第一次遇到的能够减轻本质复杂性负担的工具以我们之前提到的迪士尼乐园“快速通行证”为例，如果我们想实施一个类似系统在自己的主题公园，应从何开始?以下是我与 ChatGPT-4在这个主题上的一次互动。
ChatGPT 提供了一个极其详细的答案。然而，很难判断它是否仅仅是用更多的冗余词汇复述了我的问题。它解决了任何本质复杂性吗?让我们来问问!
对于对主题公园预约系统一无所知的人来说，ChatGPT 的答案无疑是极具参考价值的。它甚至涉及到了我未曾考虑过的紧急处理方面。当然，专业的公园设计工程师可能会在这个答案中找出一些不足，但即便如此，这个答案为我提供了一个很好的出发点。
然而，这个答案更多地是对问题的描述，而并没有给出具体的解决方案。那么，如果我们进一步利用 ChatGPT 的能力，甚至让它开始生成代码，结果会如何呢?
在代码中，我们进一步看到了在特定紧急情况下将预约重新分配给其他景点的考虑因素。如果没有可用的游乐设施，它会向客户道歉并提供赔偿。这会是最终用于生产环境的代码吗?当然不是。我将要花费很多时间来处理紧急系统的编写复杂性。这种复杂性有没有得到实质性的减少?答案是肯定的。
ChatGPT 的一个明显短板是有输入和输出长度限制。以 ChatGPT-4为例，其最大响应长度限制为8000个 token，大致等同于单词数。这个数字听起来似乎很大了，但在实际生成代码的过程中，这一限制很快就会显现，尤其是当你需要 ChatGPT 构建一个完整系统时。即使尝试通过多次交互来突破这一限制，你也会发现 ChatGPT 开始忽略你最初提出的需求细节。因此，人类工程师仍需手动管理 ChatGPT 的“状态”，以生成一个完整且连贯的工作成果。然而，这个限制可能不会永久存在。
ChatGPT 还存在一个可能无法解决的问题，即它有时会产生被称为“幻觉”的错误。在这种情况下，ChatGPT 会编造信息，甚至可能扭曲基础事实，以便更方便地回应你的问题。值得注意的是，当你指出这些错误时，ChatGPT 通常会承认并纠正它们。
人类在作为 Large Language Models （LLMs） 输出的“质量控制”方面发挥着关键作用。尤其对于经验较少的工程师而言，LLMs 可能具有潜在危险。这些工程师可能过去曾依赖于基于社交信号(如 StackOverflow 上的投票、GitHub 上的星标、Reddit 上的赞同)或仅凭同事的信任来验证在线找到的不透明代码。然而，当涉及到 LLM 时，这种方法并不可行。LLM 可能会用和给出好建议时相同的自信，提供不好的建议。
的确，和长度限制问题不一样，这个限制可能是无法克服的。对于那些多年来一直使用 LLM 的人来说，它几乎已经融入了技术的基本原理。对 LLM 进行专业级的人工监督是必要的 —在评估 ChatGPT 针对现今软件需求的性能时，多数人关心以下几个问题。作为一名资深软件工程师、产品设计师、创业公司 CEO，以及 ChatGPT 的常规用户，我将尽力给出这些问题的真实回答。
Q:ChatGPT 能否减少构建和维护产品所需的软件工程师人数?
A:确实如此，尤其适用于小型团队。ChatGPT 有效地降低了开发过程中的随机复杂性，同时也在一定程度上减少了固有的复杂性，这样你就可以在不需要大量专业人才的前提下，也能构建完整的系统。
Q:ChatGPT 能否增加可供招聘的工程师数量?
A:是的，ChatGPT 使得编写现代应用程序对于初学者变得更为简单。
Q:ChatGPT 能否减轻软件工程的工作负担?
A:是的，减轻程度显著。
综上所述，尽管 ChatGPT 存在局限性，但它实际上是现代软件工程的一颗“银弹”，这也是第一次证明布鲁克斯的悲观预测是错误的。
这里有一个值得思考的问题:我说 ChatGPT 使现今软件编写更简单，但是，谁能保证未来不需要新的软件呢?
45分钟的困扰:一个个人经验
在 COVID-19疫情期间，许多人开始了远程工作模式。对于像我这样初次体验远程工作的人，通勤时间从曾经的漫长车程或地铁行驶瞬间缩短为从床到电脑的几秒钟。我的通勤时间从45分钟瞬间缩短到了3秒。
那么，我用这些额外的时间做了什么呢?多休息?或是在床上放松?并非如此，我反而找了各种琐事和无聊任务来填补我的早晨。比如，我开始步行45分钟来回，只为了买一个我认为每天早晨必须吃的早餐三明治。当我们搬家后，我和我的妻子不得不驾车穿越两个城市，以便让孩子继续在原来的日托服务中心。猜猜我们每天的通勤时间是多少?没错，还是45分钟。
Bruce Tognazzini 是一位领先的可用性设计专家和 Apple 人机界面指南（HIG）的创始人。他在1998年的一篇文章中曾探讨了软件工程与 UI 设计的复杂性问题。该文章题为“复杂性悖论”，其中提出了 Tog 的“通勤定律”:
不论我对早餐三明治或远程日托服务的个人偏好如何，这种观点同样适用于我作为软件用户的经验。
我第一次使用 Photoshop 是在17岁时。当时我父亲拥有一台早期的 Sony Mavica 数码相机，该相机能将图片直接烧录到内置的迷你可写 CD 上。由于我几乎总是待在电脑旁，因此自然而然地成了负责“整理”这些照片的人。
我还记得第一张用于测试相机的照片，当时是我编辑的。照片是我站在全身镜前的特写，无论是镜子还是我自己，都显得不太整洁。我的衬衫上沾满了面包屑，脸上有不明物质，甚至牙齿里还有黑色的罂粟籽。我立即开始使用 Photoshop 中最新推出的修复画笔工具，以改善我的形象。经过一两个小时的努力，虽然结果看起来有些不自然，但总体上比原来要好得多。接着，我开始编辑下一张照片，那是我妹妹坐在沙发上，两侧各有一只不太高兴的暹罗猫。这张照片的问题更多:相机捕捉到了沙发和我妹妹黑色裤子上的所有浅灰色猫毛，背景的白墙因为过度曝光而变得过于明亮，以至于我妹妹的面部特征都模糊了。最终，我放弃了编辑，告诉家人不如保留原样更好。“这样看起来更自然，”我解释说。我想他们接受了我的观点。
如今，我大多会在手机上直接编辑为家人拍摄的照片。但说到“编辑”，其实我几乎没有做什么，因为现代 iPhone 的照片质量已经相当出色。虽然少花时间处理照片能多陪伴家人，听起来不错，但实际情况并非如此。
出于某种原因，我总是想进一步优化这些照片。我会将它们导入到最新版本的 Photoshop 中，进行一些两年前我还觉得不可思议的操作。例如，我会选择一张照片，然后使用 Photoshop 的“Generative Outpainting（生成性图像扩展）”功能，让 AI 根据周围的像素预测并扩展图像。在另一张拍摄于城市中心、人群繁多的照片中，我会花费时间逐一删除其他人，让我妻子看起来仿佛是地球上唯一的人。
然而，与近20年前使用修复画笔的经历相似，我逐渐对这些高级工具和随之而来的复杂性感到厌倦。这些工具运行缓慢，容易出错，通常需要多次尝试才能达到满意的效果。处理几张照片后，我通常会觉得耐心已尽。然后，我就转去做其他事情。
这正是 Tog 的“通勤定律”所揭示的一个简单但令人沮丧的人性真相:我们生活中的许多复杂性和挫折不仅是自我造成的，还受到一种隐形但持久的平衡机制的影响。
在未来，程序的基础复杂性可能会达到一个令人难以置信的程度。只有当我们将人类的创造性与 LLM（大型语言模型）的生产力相结合，这种复杂性才可能变得可管理。与此同时，由于大多数竞争市场的零和性质，我们仍然面临着自计算机科学诞生以来一直存在的劳动问题。即使我们解决了所有已知的问题，新的挑战和问题也会不断出现，重新制造出相同的困境。总之，生活就像一场舞蹈，两步向前，两步向后。
在结束之前，我想说，尽管 ChatGPT 不能永久解决软件工程的各种问题，但这并不意味着软件开发的体验不能得到改善。这就是为什么我们所有人都需要从现在开始关注这些模型。特别是那些对大型语言模型（LLM）持负面态度的人，因为这些模型仍处于发展初期并具有可塑性。
大型语言模型（LLMs）势不可挡，但我们可以影响它们
尽管像 ChatGPT 这样的 LLMs 存在多种问题，从短期和长期角度来看，工程师接纳这些模型仍符合我们的最佳利益。它们不仅简化了当前的软件开发流程，而且可能是我们接近“无劳作”状态的最佳途径。更为重要的是，随着用户需求的不断演变和 LLMs 带来的生产力提升，这些模型将成为未来软件开发的关键工具。
这并不意味着我们应无条件接受 LLMs 所带来的所有副作用。实际上，工程师而非高层管理人员将最终决定这些工具如何整合到我们的工作流程中，以及在哪些具体项目中应用它们。此外，我们还需要明确哪些任务应由人类完成，以保留人的独特价值。
如果你是一名软件工程师，现在正是时候与你的管理层合作，让他们理解并接纳 LLMs 在其擅长的领域（比如，辅助软件开发）的应用，同时也要引导他们规避潜在的风险(例如，完全替代人类完成关键任务)。
现在也是制定与 LLMs 交互的最佳实践的好时机，比如坚持使用明确的提示和智能代码补全，以及探索如何缓解它们的主要缺点（例如，通过添加社会信号来评估建议的质量）。此外，我们还需要为新入行的工程师做好准备，因为他们从职业生涯的第一天起可能就已经会使用这些工具了。
对于工程管理层，现在是时候与工程师合作，制定详实和务实的政策，这些政策不仅接受 LLMs 的不可避免性，还着重于教育员工关于它们可能带来的知识产权风险、安全隐患以及对程序员长期能力的潜在影响。这一点尤为重要，因为我们的一项调查显示，虽然89% 的员工定期使用 AI 工具，但只有少数人明确了这些工具的安全使用政策。
一旦你掌握了这些最佳实践，与他人和公众分享这些信息是至关重要的，这样我们都能更好地适应这个由 AI 辅助的工程工具主导的新时代。我们目前正在 Kolide 上制定 AI 的可接受使用政策，并计划在有成果后尽快与大家分享。
LLMs 虽然不完美，可能永远也无法达到完美，但我们可以通过持续努力来改善这种情况。最终，LLMs 将成为每位软件工程师工具箱中不可或缺的一部分。尽管如此，这个工具箱仍然会牢牢地依附于一个真实的人类，即使他的薪资很高，也可能并不总是面带微笑。
参考链接
Cobalt 最近发布的研究报告:https://www.cobalt.io/hubfs/State_of_Pentesting_2022.pdf
一名程序员因职业倦怠而崩溃:https://github.com/docker/cli/issues/267#issuecomment-695149477
博客文章:https://m.signalvnoise.com/conceptual-compression-means-beginners-dont-need-to-know-sql-hallelujah/
进度报告:https://undertale.com/deltarune-update-092020/
没有银弹——软件工程的本质与偶然:https://www.math.unipd.it/~tullio/IS-1/2004/Approfondimenti/BrooksNoSilverBullet.html
LLMs 能根据输入的提示进行概率性的回应:https://writings.stephenwolfram.com/2023/02/what-is-chatgpt-doing-and-why-does-it-work/
我们的一项调查:https://www.kolide.com/blog/unmanaged-devices-run-rampant-in-47-of-companies
（举报）
