我依然关心代码

Birgitta 是 Thoughtworks 的杰出工程师 (Distinguished Engineer) 和 AI 辅助交付专家。她拥有超过 20 年的软件开发人员、架构师和技术负责人经验。

本文属于”探索生成式 AI (Exploring Gen AI)“系列。该系列记录了 Thoughtworks 技术专家探索将生成式 AI (gen ai) 技术用于软件开发的过程。

2025 年 7 月 9 日

自从 AI 编码辅助开始流行以来，我就听到有人说：“哦，所以到了某个时候，我们甚至可能不再需要关心代码了，它就像汇编语言 (Assembly) 一样，我们肯定不会再去看那些东西了。“最近，随着代理能力 (agentic capabilities) 的增强和”氛围编程 (vibe coding)“这一概念的提出，这种观点又出现了新的高峰。

我个人认为，我们非常应该仍然关心代码。也许方式与以前不同，但我们仍然需要关心。

想象你在待命 (on call)！

开发和运维 (Dev and Ops) 合二为一的主要好处之一是，当你待命时，你会成为一个更有责任感的开发者。你会更加关心弹性 (resilience) 和无缺陷代码，因为你不想在深夜或周末被叫醒。

所以在炒作中让自己脚踏实地的一个好问题是：如果你正在为自己开发的应用程序待命，在什么程度上你会愿意部署一个 1,000 或 5,000 行代码 (LOC) 的变更集？(请记住，如今大多数团队甚至对依赖升级机器人 (dependency upgrade bots) 的自动合并拉取请求 (auto-merging PRs) 感到担忧。)

对我个人而言，我仍然想要关心并掌握的最基本要求是测试代码。

大语言模型 (LLMs) 不是编译器 (compilers)

我差不多两年前就写过这个观点，我仍然没有改变想法，反而更加坚定。

大语言模型 (LLMs) 不是自然语言的编译器 (compilers)、解释器 (interpreters)、转译器 (transpilers) 或汇编器 (assemblers)，它们是推理器 (inferrers)。编译器接收结构化输入并产生可重复、可预测的输出。大语言模型不会这样做。也许可以将它们束缚到这样的程度：它们以非常高的概率为某个输入产生相同的输出，但我想象到那时，输入可能甚至不再是非结构化的自然语言了。一旦我们用足够的脚手架 (scaffolding) 将它们包裹起来使它们变得可预测，我们就有可能剥夺使它们最初变得有价值的那个东西。

持续的风险评估 (risk assessment)

由于这些推理器 (inferrers) 的非确定性本质，在软件环境中使用生成式 AI (Generative AI) 就是持续的风险评估。我此刻对此感受尤深，因为我正在从事一个 AI 加速的提升和转移 (lift and shift) 遗留系统迁移项目，需要实现功能对等 (feature parity)。

风险评估，一如既往，是以下 3 个因素的组合：

• 影响 (Impact)：出问题会怎样：我会在半夜被叫醒吗？我正在处理的是一个容错率低的使用场景吗？我所在的领域对业务至关重要，还是内部的、辅助性的？
• 概率 (Probability)：出问题的可能性有多大：我拥有的 AI 设置有多复杂？我正在处理的问题是简单还是复杂 (comples)？我是否有适当的上下文 (context) 可供 AI 做正确的事情？
• 可检测性 (Detectability)：我发现问题可能性有多大：为此我考虑了所应用的审查级别和类型，以及我对整体安全网 (safety net) 的信心。

幻觉 (Hallucinations) 是大语言模型 (LLMs) 的核心特性。当它们做我们不想要的事情时，我们称之为”幻觉”，而在对我们有用的情况下，我们称之为”智能 (intelligence)“。无论我针对一个问题投入多少上下文、工具 (tooling) 和模型能力，总是存在不可忽视的出错概率。因此，特别是在高影响和低可检测性的情况下，我绝对仍然关心代码。

最新文章 (3 月 4 日)：

Humans and Agents in Software Engineering Loops

上一篇文章：

Autonomous coding agents: A Codex example

下一篇文章：

Partner with the AI, throw away the code