我花了大量时间做的一件事就是面试软件工程师。这显然是项艰巨的任务，我并非声称有什么神奇解决方案；但这让我有时间去思考高效软件工程师实际在做些什么。 软件工程循环当你观察一个知道自己在做什么的人时，会发现他们在循环执行以下步骤：
实现这些目标有多种方式，但优秀工程师的关键区别在于他们构建和维护清晰思维模型的能力。 LLMs 怎么样？公平地说，LLMs 非常擅长编写代码。当你指出需要修复的问题时，它们也能较好地更新代码。它们还能完成真正软件工程师所做的所有工作：阅读代码、编写和运行测试、添加日志记录、（理论上）使用调试器。 但它们无法做到的是保持清晰的心智模型。 LLMs 会陷入无尽的困惑：它们假设自己编写的代码确实能运行；当测试失败时，它们只能猜测是修复代码还是修改测试；当遇到挫折时，它们干脆删除所有内容重新开始。 这完全与我的期望背道而驰。 软件工程师会边开发边测试。当测试失败时，他们能参照心智模型决定是修改代码还是调整测试用例，或是收集更多数据再做决断。遇到瓶颈时，他们可以通过讨论寻求帮助。虽然有时也会推倒重来，但此时他们对问题已有更清晰的认识。 但很快就能实现了吧？随着模型能力提升，这种情况会改变吗？或许吧？但我认为这需要从根本上改变模型的构建和优化方式。软件工程需要的不仅是代码生成能力。 当人们遇到问题时，能够暂时存储完整上下文，专注于解决问题，然后恢复思维栈回到手头任务。他们还能跳出细节关注全局，让次要信息暂时隐去，只在必要时深入局部。我们不会无限制扩展认知窗口，那样只会让人崩溃。 即便不考虑信息过载问题，现有生成模型仍存在多个直接影响其维持清晰思维模型的缺陷： - 上下文缺失****：模型不擅长发现被省略的上下文。
- 近因偏差****：它们在上下文窗口中表现出强烈的近因偏好。
- 幻觉生成****：它们经常虚构出本不该存在的细节。
这些问题应该并非无法克服，目前正在通过添加记忆功能让它们能像人类一样进行思维运作。但遗憾的是，现阶段它们还无法（超出一定复杂度后）真正理解正在发生的事情。 它们无法构建软件，因为它们无法同时维持两个相似的"心智模型"，识别差异，并判断应该更新代码还是修改需求。 那么，现在该怎么办？显然，LLMs 对软件工程师很有帮助。它们能快速生成代码，并且非常擅长综合需求与文档。对于某些任务来说这就足够了：需求足够明确，问题足够简单，它们可以一次性完成整个工作。 话虽如此，对于任何非琐碎的任务，它们都无法准确维持足够的上下文来迭代出一个可行的解决方案。作为软件工程师，你需要负责确保需求清晰，并且代码真正实现了它声称的功能。 在 Zed，我们相信一个人与智能体可以协作构建软件的世界。但我们坚信（至少目前）你才是掌控方向的人，而 LLM 只是工具箱中的另一个工具。 | 
