人工智能时代，将是软件开发者的末日吗？

源| builttoadapt译| 孔明明

还记得曾经那些世界被软件吞噬的时光吗？近期的趋势来看，现在是人工智能吞噬软件的时代了。即便是谷歌的 CEO Sundar Pichai 都已经在讨论自编程软件了。如果你认同软件开发只不过是反复创建代码段的观点，那么现如今 AI 的快速发展确实可以让软件工程师消停会儿了。

开发人员编写软件时，通常需要遵循一系列硬编码规则，比如，如果条件 X 满足，则执行 Y。机智的人类就是这样一行一行地指挥冰冷的机器工作滴。当然，这可能都是些软件 1.0 时代的陈芝麻烂谷子事儿了。然而到了软件 2.0 时代，随着深度学习的发展，人们认识到可以建立这样一个神经 络，它可以通过学习必要的指令或规则来实现期望的结果。

软件 2.0 时代的支持者之一，Tesla 的 AI 总监 Andrej Karpathy 提出的论点是，2.0 时代，咱们不需要再实打实的敲代码啦，咱只需要找到数据，并把它们“喂”给机器学习系统就完事啦。这样一来，软件工程师已然幻化成了“数据管理员”或着叫“数据使能者”。总之，不管我们自称是谁，都将不再是写代码的程序员了。

Karpathy 在最近发表的一篇题为软件 2.0 时代的文章中写道：“未来绝大部分程序员都不会再去干诸如维护复杂的软件库，编写错综复杂的程序或分析程序运行时间的活儿了。他们的工作是收集，清洗，处理，标记，分析和可视化那些需要提供给神经 络的数据。”

在个人看来，我不认为软件工程会立刻消失。即便有如软件 2.0 工程、数据科学 2.0 工程或者其他任何一种新的角色介入，但处于新技术转移过程中的软件 1.0 时代的软件工程从业者们总能获得些新招儿。

实际上，我并不确定在不久的将来，彼时的软件工程业态是否会完全区别于现在的状况。是的，深度学习神经 络会给予我们帮助，但它们只是要帮助我们更好地完成当前的工作，而不是完全取代我们。

当然，这是一个新的世界，但我们并没有不是在《黑镜》的剧情里。现实中，常用的办公室助手已经帮你安排好了一天的行程，并着手安排你的电话会议。 上甚至还出现了这样的 AI 系统，它可以为你的企业量身定制徽标，并根据你的反馈进行改进。

这里还有一个很好的例子：这个新例子展示了深度学习 络是如何将设计好的样图转换成 HTML 代码的。这个 络通过查看现有 页以及屏幕像素与 HTML 标记（如<h1>，<div>）的关联方式来进行训练，进而学习了解到浏览器是如何将HTML语言渲染成你看到的图像的。然后你可以反过来“喂”一个新的图像给这个 络，它就会将图像转化成有效的 HTML 语言。一个类似的应用就可以大大缩短建模周期，设计者只要设计一个接口，机器就可以用它创建一个可用的 页。

多年来，我们一直使用自动助手进行代码重构，并利用它们节省编写样板代码的时间。

我的观点是传统的软件工程行业将会被机器学习重塑，但不会消失。然而它会被如何重塑呢？

今天，手机可以自动检查你的拼写语法，并给出下一个建议单词。在做程序开发过程中，也有类似的工具会高亮显示代码中潜在的错误。作为一个为 Pivotal 做结对编程的程序员，我很自然会思考软件 2.0 时代会对自己工作方式的带来哪些影响。考虑到机器学习和会话接口技术的进步，有一天机器或许真的可以成为我的另一半。

多年来，我们一直使用自动助手进行代码重构，并利用它们来节省编写样板代码的时间。我们现在也很乐意在更复杂的软件开发过程中引入 AI 助手。最近，在一些 IDE 中，此类 AI 助手也以增强特性的形式出现在产品序列中，目的就是为了更好的促进程序的编写。

现在想象一下高级 AI 助手在未来挑大梁的场景吧。在编程时，这个小伙伴儿可能会根据你的编程风格，使用高级预测分析功能来确定正在编写的函数的类型，并根据它自己的编程风格填充完剩下的代码。大致上就是这个小伙伴儿为你编写其余代码，然后由你来审批这部分代码是否合格。

另一个 AI 助手可以发挥作用的领域是测试程序开发。人类可以开发测试程序，而这个小伙伴儿则可以通过数百万次反复尝试，最终找到合适的代码段来解决测试问题。这样一来，人类就不需要同时承担两项任务了——编写测试代码和解决测试问题，后者交给机器就行啦。于是你将在程序的实现上投入更少的时间，省出来的时间便可以用来思考和解决业务问题，这太有用啦。

顺便提一下，软件 2.0 时代甚至可能有助于指导测试程序的开发，并为后续哪个测试程序该被运行提出建议，给出理由。想象一个这样的场景：营销人员跑到开发团队跟前儿，咋咋呼呼的说他们想要产品实现这样和那样的功能。可是你想想，如果他们能够以机器可以理解的方式来表达自己想要的东西（这种方式向来都更方便些），那么机器便可以帮忙选择所需的测试程序，并提出后续的建议。

以上设想的场景也引起了极大的担忧：机器会完全取代软件工程师吗？事实情况是可能我们最多只能让机器达到软件工程师们 90% 的能力，即便如此也意味着失败（时间上 1% 的失败），这种失败源于不可预知性。这种不可预知性的存在也意味着你需要一个监控系统来确保编写的代码起到实际作用。也许负责监控会是软件工程师的一个新角色，就像 Andrej 在他的文章中提到的：监控代码并帮助机器学习系统达到接近 100％ 的准确率。

现在我们已经勾勒出了软件 2.0 时代带来的可想象的益处，另一个接踵而至的问题是：软件编程的哪些部分可以转移到深度学习 2.0 框架以及传统的 1.0 框架中应该保留些什么？今天，深度学习神经 络在监督学习环境中表现得相当不错，只要给他们提供些包含正反样例的训练数据，它们就可以学习到如何正确的输出。举个例子，谷歌已经将深度学习应用到整个产品系列中了。

但是这些神经 络系统的好坏仅仅等同于训练数据的好坏。正如我的一位同事提到的那样，提高神经 络模型性能往往涉及到改进底层代码和部署环境，另外还需要提高训练数据的质量。一些机器学习系统能变得越来越好，是因为它们实际上是在克服训练数据中人为造成的缺陷。

实际上，神经 络并不是什么杀手锏。我们要做的是，设计能与其他解决方案合作的神经 络。软件开发的某些部分确实会因为利用深度学习技术工作得很好，某些部分则不会。

对于结对编程，我个人的经验是通过和人合作后，针对同一问题会得到很多不同的解决方法，软件开发就是这样一个与其他同事不断合作的过程。每当组队成功，合作伙伴就会带来不同的经验和方法。组队数量越多，你能得到的解决方案也就越多。

到了软件 2.0 时代，我们有了一个新小伙伴儿来帮助开发人员更好地完成工作，一个更加有力的协作环境也正在形成，这会带来越来越多，更有效的解决方案，并且人人都会因此获益。

唯一不变的就是变，所以个人，机构和企业必须学会适应。在 Pivotal，我们相信这种改变应该被期待，被接受，并通过开发和创新被不断得融入，因为我们追求优质软件的脚步永不停歇。

-END-

译者 | 孔明明

南开大学毕业，特殊培训行业末端从业人员，热衷数据分析，热爱英文翻译，热心公益事业，简称散热板。

后台回复 “志愿者”

了解如何加入我们