AI 能否代替软件工程师？

出品：CSDN（ID：CSDNnews）

作者：Harry Tormey

译者：弯月

责编：夏萌

软件工程师的工作不仅仅是写代码。AI 面临着一系列的挑战，比如深入洞察人类以及开展协作。人类在面对复杂的非线性问题时能够深入思考，而 AI 这方面的能力很欠缺。AI 难以理解人类设计师考虑的情感共鸣和语境是否合适等问题。此外，准确地预测用户需求需要一定程度的直觉和适应能力，在没有人类协助的情况下，AI 尚未能掌握这些能力。

原文链接：https://www.htormey.org/can-you-replace-your-software-engineers-with-ai/

未经允许，禁止转载！

答案是否定的。在可预见的未来，人工智能并不能取代软件工程团队。原因在于，当前用于评估大型语言模型和自主代理的基准并未完全捕捉到软件工程师每天处理的任务的复杂性。即使根据这些简化后的基准，大型语言模型和自主代理所表现出的性能也不尽如人意。

软件工程师的工作不仅仅是写代码。AI 面临着一系列的挑战，比如深入洞察人类以及开展协作。人类在面对复杂的非线性问题时能够深入思考，而 AI 这方面的能力很欠缺。AI 难以理解人类设计师考虑的情感共鸣和语境是否合适等问题。此外，准确地预测用户需求需要一定程度的直觉和适应能力，在没有人类协助的情况下，AI 尚未能掌握这些能力。

话虽如此，大型语言模型和自主代理的发展正在迅速推进，AI 承担的任务越来越多，越来越高效，而且能力越来越强。本文旨在深入探讨评估AI工程师发展的基准。

AI 的发展前景：工程师Devin

最近，Cognition 实验室的在一篇博客文章中介绍了一名自主 AI 软件工程师 Devin，文章中有一则视频，介绍了 Devin 掌握的一些技能，例如开发和部署应用程序、修复错误、处理开源项目问题、为已建立的软件项目做贡献，以及完成Upwork上的真实任务。

这些视频展示了Devin在一个沙盒式计算环境中使用一系列的开发者工具（如shell、代码编辑器和浏览器）来完成这些任务。该实验室的网站还包含了一个链接，里面记载了希望“雇用”Devin的等候者名单。

在视频中，似乎 Devin 完成的任务都很厉害，但实际上，这些任务都非常简单，类似于初级开发者教程或编程面试题。举个例子，其中一段视频展示了Devin修复了一个编程竞赛算法代码库中的一个常见错误，但其实这是大型语言模型训练数据集和评估基准中的一个很常见的问题。

Devin的任务与初级开发者责任的比较

尽管Devin完成的任务看起来很高端，但实际水平还不如软件团队中初级开发者面临的真实挑战。例如：

• 开发面向用户的功能：与Devin的演示不同，初级开发者通常需要在应用程序中构建复杂的功能。这些任务需要与团队合作，遵循设计系统，并确保应用程序满足实际用户的需求。

• 解决复杂的后端问题：初级开发者还要解决生产环境中的复杂问题，例如修复拥有多个数据库和服务器的系统中的错误。这些工作远比Devin展示的任务要复杂得多，需要更深入的分析和解决问题的能力。

有关Devin，让我印象深刻的是以下声明：

“我们在SWE-bench上对Devin进行了评估，这是一个具有挑战性的基准，要求 AI 代理解决GitHub开源项目中（如Django和scikit-learn）发现的真实问题。

Devin正确地解决了 13.86% 端到端的问题，远超之前1.96%的水平。以前即便指出具体需要修改哪个文件，成绩最好的模型也只能解决4.80%的问题。”

为了正确理解这一成就，关键是看看人们如何测试大型语言模型在编程挑战中的表现。有一个很有名的例子，OpenAI 的 HumanEval，他们通过164个Python问题测试了该模型的基本编程水平，每个问题都要编写一个函数，而且还要通过测试，比如统计字符串中的大写字符。虽然看着很厉害的样子，但实际上这些任务远不及日常软件工程师的工作水平，更像是面试题，不是真实世界会遇到的问题。

SWE-bench：为什么说这是更好的软件工程AI测试基准

相比之下，SWE-bench提供的测试大型语言模型能力的基准更现实。其中包括来自实际的GitHub议题以及拉取请求的2,294个任务，要求大型语言模型浏览和修改代码库，以解决真实问题。这个基准要求对代码有更深层次的理解和交互，更准确地反映了软件工程的复杂性，而不像HumanEval等测试基准那么简单。

我们来深入看看SWE-bench论文，更仔细地观察其中提到的Python代码库、他们的数据来源以及测量性能的方法。该论文中给出了如下饼图，显示了问题的分布及其来源：

熟悉Python开发的人可能对其中一些库并不陌生。下面，我们来看看他们选择和抓取这些问题时使用的标准：

在SWE-bench测试中，AI 需要解决提供的代码库中所描述的问题。AI 需要以补丁文件的形式提交修改后的代码，并在其中指定必要的代码改动。如果在应用补丁后，相关的代码通过测试，则认为 AI 的解决方案是成功的。该基准的有效性取决于AI成功解决的问题数量。

尽管这比HumanEval略好一些，但作为基准仍然不够理想。现实生活中的软件工程涉及复杂的系统和技术，例如Kubernetes、Docker和像AWS等这类的云服务，这些在简单的基准测试中很难复制。这说明了常见的大型语言模型测试场景与工程师实际面临的细致、多方面的任务之间的差距。

SWE-bench：检查测试数据

我们可以通过Huggingface访问SWE-Bench的训练数据，这些数据存储在一个“.parquet”文件格式中，这种格式不像HumanEval数据那样容易查看。我使用pandas库创建了一个Python脚本来加载和显示这些数据。通过脚本，我看到了其中包含的问题，与Django相关的问题一共有850个，下面是一个例子：

标题：在django-admin中添加一个选项，表示始终输出颜色。

描述：使用Django管理命令，当前可以使用--no-colors标志禁用颜色。

我想要的是一个相反的标志：一个--force-colors标志，指示Django在默认禁用颜色的情况下（通常是当输出通过管道传递到另一个命令时）输出ANSI颜色序列。

下面是一个真实的用例：我有一个自定义的Django命令来导入数据。我自己运行这个命令，而且我希望向数据管理员发送一个颜色的日志（使用HTML应该很合适）。我可以使用https://github.com/theZiz/aha 实用程序，但由于Django会在通过管道传递输出时禁用颜色，所以无法使用这个实用程序。

针对这个特定的用例，*nix命令有一个特殊的标志，例如 $ ls --color=always

创建时间：2018-07-22 17:15:08

补丁大小：71行

尽管这是一个六年前的问题，但它反映出了我会实际遇到的真实软件工程任务。

面对大型语言模型无法一次性处理的大型代码库的挑战，SWE-Bench通过使用两种关键技术来解决：

• 稀疏检索：选择一组有限的相关文件供AI浏览，这有助于处理复杂的代码。

• Oracle检索：这种方法使用已知可解决问题的文件，尽管这不太现实，因为一般情况下工程师不知道哪些文件需要编辑。

使用稀疏检索比较实际，Oracle检索有点不太公平，因为这等于是暗示大型语言模型修改哪些文件。就性能而言，Claude 2这类的模型在Oracle检索的提示下解决了约4.8％的问题，而没有提示时只解决了1.96％。

这就是为什么相比之下，Devin 在没有具体指导的情况下，成功率为 13.8％，在我看来已经很了不起了。

总结：AI与人类工程师是合作者的关系，而非竞争对手

由于工程人员数量不足，许多产品功能、更新和重要的错误修复都无法及时发布。大公司的季度规划中经常遇到这种情况。此外，我们对未来技术需求的预测能力经常被高估。由于例行任务都可以通过 AI 自动化，工程师的工作重点将转向更复杂和更富创造力的任务，从而为创新带来新的机会。

2024年，技术岗位市场陷入低谷，就业难的问题很普遍。然而，我认为这些问题的根源并不是AI造成的。相反，如果没有当前AI的增长，情况可能会更糟。AI的繁荣正在推动初创公司的投资和岗位增加，防止了可能更严重的就业市场衰退。

然而，这种发展前景提供了良好的机会。我们可以通过开发更好的基准和训练数据，训练 AI 自动完成例行任务，而我们则可以集中精力处理更具创造性和价值的工作。

未来智能实验室的主要工作包括：建立AI智能系统智商评测体系，开展世界人工智能智商评测；开展互联网（城市）大脑研究计划，构建互联网（城市）大脑技术和企业图谱，为提升企业，行业与城市的智能水平服务。每日推荐范围未来科技发展趋势的学习型文章。目前线上平台已收藏上千篇精华前沿科技文章和报告。