我花了大量时间做的一件事就是面试软件工程师。这显然是一项艰巨的任务，我并不声称拥有神奇的解决方案；但这给了我一些时间来反思高效的软件工程师实际做了什么。
软件工程循环
当你观察一位熟练的工程师时，你会看到他们循环执行以下步骤：
- 建立需求的心智模型
- 编写（希望？！）能实现这些需求的代码
- 建立代码实际功能的心智模型
- 识别差异，并更新代码（或需求）
有许多不同的方法可以完成这些事情，但高效工程师的 отличительный 特征是他们建立和维护清晰心智模型的能力。
那么大型语言模型呢？
公平地说，大型语言模型在编写代码方面相当出色。当你指出需要修复的问题时，它们在更新代码方面也相当不错。它们还可以做真正的软件工程师所做的一切：阅读代码、编写和运行测试、添加日志记录，以及（大概）使用调试器。
但它们无法维护清晰的心智模型。
大型语言模型会不断地感到困惑：它们假设自己编写的代码实际上是有效的；当测试失败时，它们会猜测是修复代码还是测试；当感到沮丧时，它们会直接删除所有内容并重新开始。
这与我所寻找的完全相反。
软件工程师在工作中会不断测试。当测试失败时，他们可以根据自己的心智模型来决定是修复代码还是测试，或者在做决定前收集更多数据。当他们感到沮丧时，可以通过讨论来寻求帮助。虽然有时他们确实会删除所有内容并重新开始，但这样做时他们对问题有了更清晰的理解。
但很快就会实现，对吗？
随着模型能力增强，这种情况会改变吗？也许吧？？但我认为这需要改变模型的构建和优化方式。软件工程需要模型不仅仅能生成代码。
当一个人遇到问题时，他们能够暂时储存完整的上下文，专注于解决问题，然后弹出他们的思维堆栈以回到手头的问题。他们还能够放大并关注大局，让细节暂时消失，必要时深入研究小部分。我们不会只是不断地向我们的上下文窗口添加更多的词语，因为那会让我们发疯。
即使处理的上下文不是太多，我们也知道当前的生成模型存在一些直接影响其维护清晰心智模型能力的严重问题
- 上下文遗漏：模型不擅长发现被遗漏的上下文。
- 近因偏差：它们在上下文窗口中存在很强的近因偏差。
- 幻觉：它们经常幻觉不应该存在的细节。
这些问题希望并非不可克服，目前正在进行记忆的添加工作，以使它们能够执行类似于我们的心智技巧。不幸的是，目前它们还不能（超出一定复杂性）真正理解正在发生的事情。
它们无法构建软件，因为它们无法维护两个相似的“心智模型”，识别差异，并判断是否更新代码或需求。
那么，现在怎么办？
显然，大型语言模型对软件工程师很有用。它们可以快速生成代码，并且在综合需求和文档方面表现出色。对于某些任务来说这已经足够了：需求足够清晰，问题足够简单，它们可以一键完成整个事情。
话虽如此，对于任何非琐碎的任务，它们都无法足够准确地维持足够的上下文来迭代到一个可行的解决方案。作为软件工程师的你，需要负责确保需求清晰，并且代码确实实现了其声称的功能。
在 Zed，我们相信一个人们和代理可以协作构建软件的世界。但是，我们坚信（至少目前）你才是驾驶员，而大型语言模型只是另一个可以使用的工具。