AI 能否代替软件工程师？|ai|oracle|应用程序|编程|软件工程师

出品：CSDN（ID：CSDNnews）

作者：Harry Tormey

译者：弯月

责编：夏萌

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

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

未经允许，禁止转载！

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

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

AI 的发展前景：工程师Devin

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

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

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

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

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

开发面向用户的功能：与Devin的演示不同，初级开发者通常需要在应用程序中构建复杂的功能。这些任务需要与团队合作，遵循设计系统，并确保应用程序满足实际用户的需求。
解决复杂的后端问题：初级开发者还要解决生产环境中的复杂问题，例如修复拥有多个数据库和服务器的系统中的错误。这些工作远比Devin展示的任务要复杂得多，需要更深入的分析和解决问题的能力。

基准和现实：评估AI的软件工程技术水平

有关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通过使用两种关键技术来解决：