通过这篇文章，我将结束对第二届软件开发未来研讨会的笔记整理。不过在此之前，需要说明的是，Thoughtworks关于该研讨会的完整报告现已发布。报告提出了五项核心发现：
- 代码生成不再是瓶颈——验证才是。
- “驾驭工程”正成为一门独特且可自主掌控的学科。
- 组织正面临一场真实的学徒制危机。
- 高管与工程师之间的期望差距，其风险远超任何技术限制。
- 遗留系统现代化是最清晰、最可防御的短期价值池。
❄ ❄
一场会议围绕工程师与高管层及董事会之间对LLM使用的认知错位展开。令人担忧的是，董事会只关注承诺的生产力提升，而对风险——尤其是安全风险——重视不足。
一个案例生动说明了这一点：某公司使用机器学习训练的软件来优化现场设备空气滤清器的更换频率。他们欣喜地发现，滤清器更换次数减少，节省了5000万美元。但问题在于，机器学习模型是基于沙漠环境中的设备训练的，而他们的设备实际用于北极地区。沙漠中的空气滤清器处理的是灰尘，但在北极，需要清除的是蚊子。这里有一个重要区别：蚊子会腐烂，而大量腐烂的蚊子会构成严重的火灾风险。因滤清器更换频率降低，堆积的腐烂蚊子引发的火灾，最终让该公司损失了1000亿美元。
当然，即便没有人工智能介入，类似的故事也屡见不鲜。当解决方案被应用于新环境时，人类自身也常犯错误（这也是“上下文”成为模式作者们关键词的原因）。但这个故事提醒我们，要警惕人工智能的建议，并始终思考如何构建传感器以提供快速反馈。
工程师们尤其担心，当公民开发者开始氛围编程时，风险会随之而来。从很多方面看，这并非新鲜事。IT从业者常常担忧，许多重要的商业决策竟建立在缺乏管控、测试和数据质量评估的电子表格之上。氛围编程放大了这些担忧，因此企业需要一系列控制措施来防范安全漏洞。一些人已着手在董事会层面提出问题，通过为董事会成员举办威胁建模会议，向他们介绍相关风险。氛围编程开发的应用程序需要部署在独立的基础设施中，并通过对数据访问的确定性控制来遏制致命三重奏。一家公司曾鼓励公民开发者广泛开展氛围编程，但随后因涌现出大量影子IT问题而退缩——他们现在正寻求构建一个平台，在控制这类工作的同时，不扼杀已产生的实用工具。
这里的问题部分可能源于对LLM的简单经验。许多管理层发现，LLM在编写管理报告方面做得不错，或者总结其他LLM编写的管理报告。因此，他们自然认为LLM在编程方面也一定表现良好。我这种反管理倾向的人不得不提到凯尔西·海托华的观点：
你的琐碎工作越少，这些AI工具的吸引力就越低
一个可能的解药是：让法务部门介入。他们看到LLM表现不佳，并意识到其中的风险。
❄ ❄
我交谈过的大多数人，无论是在静修会上还是场外，都承认我们处于某种泡沫中。像这样的技术进步几乎总是伴随着经济泡沫，未来我们回顾这一切时，会摇头感叹自己知道泡沫有多严重。但虽然很容易看出存在泡沫，却很难判断它会持续多久，或者泡沫破裂后会出现什么。毕竟，互联网泡沫在1995年就被明确识别出来了。我们可以愉快地指出那些失败的公司（Webvan、pets.com），但随后也必须承认那些幸存下来的公司（亚马逊）。
静修会上的大多数人年龄都够大，经历过互联网泡沫和崩盘，但其中一位白发人指出了一个有趣的差异。那时，我们对未来充满期待，看到许多新事物被构建出来。而这次，这种情况少得多。大多数人持谨慎态度，对AI泡沫正在创造的东西感到担忧。部分原因可能源于互联网泡沫希望破灭后的现实。社交媒体可能无处不在，但我们真的认为它显著改善了我们的生活吗，即使（尤其是？）我们大量使用它？
我们听到很多关于通过代理编程可以做的令人难以置信的高效事情，但有人注意到用它构建的大量精彩应用吗？或者，我们注意到来自谷歌或微软等AI大推动者的常见应用有显著改进吗？
这可能是董事会与工程师之间分歧的另一个因素。目前推动AI采用的主要动力是削减成本，而董事会往往对削减成本感到兴奋。也许对token成本日益增长的担忧会抑制这种热情。
❄ ❄
人们发现LLM在运维中很有帮助：通过可观测性工具提供良好的事件流，代理能更快地发现异常。公民开发者应用的一个问题是，它们通常不提供良好的可观测性，因为公民开发者不会想到要求这一点。代理查看事件流的能力确实带来了治理问题，因为这类事件流通常包含大量敏感信息。
在犹他州听到的观点得到了进一步印证：更多人认同大语言模型对运维人员理解代码逻辑很有价值。通过交叉比对代码与事件追踪信息，他们能帮助人类在系统故障时定位问题根源。智能体在处理重复性事件时尤其高效，能整合不同案例的大量信息并呈现给人类团队。
让智能体实现自动修复将把我们带入能力与风险并存的新阶段。关键是要确保智能体在执行修复时详细记录所有操作，同时建立向开发团队反馈的机制以促进学习。智能体本身无法学习，最多只能更新上下文。
许多人似乎高估了智能体处理事故的能力。他们误以为事故处理是简单的线性流程，但现实往往充满意外和变数，需要灵活应变。人类擅长应对这种复杂性，而大语言模型则不然。
智能体编写代码的一大隐患是它们会擅自添加未经要求的功能。有个团队花了三天时间排查某个多余功能，试图弄清是谁提出的需求，以及是否有人需要保留它。
❄ ❄ ❄ ❄ ❄
一群法学教授开展了一项有趣的实验，旨在评估大语言模型回答学生简短问题的能力。他们设计了四十道合同法问题，邀请教授和多个大语言模型分别作答。评估时，教授们会看到成对的答案（一份来自人类，一份来自大语言模型），并选择更愿意向学生提供的那个。
教授们对大语言模型的评分远高于同行（平均胜率75.33%），其表现与最优秀的讲师相当。大语言模型的回答被标记为有害的比例也极低（3.53%，而教授为12.06%）。
这让我想起近期一篇随笔中提到的互动型专长与贡献型专长的区别。
❄ ❄ ❄ ❄ ❄
几天前，Unmesh Joshi在此发表文章，分享了他利用领域特定语言提升大语言模型可靠性的经验。有读者在回复中引用了Spender Nelson的文章，其中表达了类似观点。
这类领域特定语言完美契合大语言模型的诸多优势：既能极致节省词元，又能强制执行安全边界；可将大语言模型的高层意图转化为大量确定性代码，在（自定义）编译器层面确保良好行为与防护措施。
大语言模型非常擅长学习和使用领域特定语言。这或许不足为奇——毕竟它们本质上是语言模型。只需少量文档就能让它们快速上手，合理的错误提示甚至能让它们在出错时自行修正。
他举了两个使用场景的例子：一种考虑安全与授权问题的数据湖查询语言，以及一种用于简化安全SQL子句创建的小型表达式语言。
使用领域特定语言（DSL）的最大障碍之一，尤其是外部DSL，在于构建解析器和配套工具。大语言模型让这一过程变得容易得多。不过，我的直觉是，真正重要的是支撑DSL的语义模型，而DSL只是该模型的一种投影。大语言模型或许能帮助我们以有趣的方式探索该模型的其他投影方式。
❄ ❄ ❄ ❄ ❄
最近几周，我越来越频繁地嗅到大语言模型腔的恶臭。这不仅仅是那些常见的标志性特征，更是一种弥漫在字里行间的大语言模型迷雾。我注意到它正愈发激起我的生理反感——读上几段后，我就只想把整篇文章直接扔掉。对于其中一些内容，我不得不捏着鼻子硬着头皮读完，但那种精神上的恶心感遮蔽了内容本身，甚至让我更想沉溺于刷社交媒体这种糟糕的分心之事。
我想知道——是不是只有我对大语言模型腔反应如此强烈？还是说其他人也会因此产生反感，以至于一触发“大语言模型警报”就把文章丢到一边？
证明并非只有我如此的一个迹象，是杰森·科布勒几个月前发的一篇帖子，他在其中描述了AI如何摧毁他的大脑：
人们把假的当成真的，把真的当成假的。关于“AI精神病”——这个非特定、非科学的诊断，用来形容那些迷失在AI中的人——已经有很多论述。但关于他人使用AI给我们其他人带来的认知负担，以及不得不面对一个被懒惰的AI渗透到每个角落的互联网和世界的阴险本质，却鲜有提及。我们的大脑现在每天要进行无数次计算：这是AI写的吗？我在乎它是不是AI吗？为什么这个声音、画面或文字读起来这么奇怪？这个人本来就这么写作吗？这到底是不是一个人？
不久前我还在想，对于不像我这样执着于写作的人来说，用AI润色文字倒也合情合理。但现在我却转而鼓励写作者们拒绝它。那种泛滥的LLM腔调如今实在太普遍了，我的感觉是，它甚至让读者还没来得及理解内容，就先对文字失去了信任。我不认为让LLM写初稿再稍作修改是个好主意。我甚至不确定，一旦LLM的痕迹渗入文字，写作者能否将其彻底剔除。我甚至担心向LLM寻求修改建议——因为太容易接受它的提议了，而这个过程会触发读者对LLM的抗体。
当然，像大多数问题一样，这同样是个机遇。那些能展现独特人类声音的人，将获得更多关注和可信度。但问题依然存在：我们该如何引导人们将真实的个性注入文字？学术写作和商业写作本就容易扼杀生动的表达，而LLM是绝佳的放大器，只会加剧这种扼杀。对于那些英语是第二语言（甚至对许多同事来说是第三或第四语言）的人而言，这更是巨大的挑战。我太容易忽略自己从未面对过的困境了。
我能给出的最直接建议，源于多年前学到并去年分享的——大声朗读你的文字。
当你写出像样的初稿后，大声朗读出来。这样做会发现那些听起来不对劲、需要修改的地方。
我过去常建议人们用这个方法摆脱呆板的文字，尤其是那些长期浸淫在学术或商业写作中的人。但现在我认为，为了对抗AI潜移默化的影响，大声朗读文字变得更为重要。对大多数人来说，说话的方式更接近真实的自我，所以将文字念出声来，正是对抗那些试图磨平写作者个性的力量的最佳方式。