为什么用人工智能取代程序员不会那么容易。构建软件最难的部分不是编码，而是需求
随着所有关于人工智能发展多么惊人的文章，有很多关于我们作为软件开发人员可能很快就会失业，被人工智能取代的可能性。他们想象所有的业务主管和产品研究人员都会绕过他们的大部分或全部软件开发人员，直接要求人工智能构建他们认为他们想要或需要的东西。作为一个花了 15 年时间根据这些人创建的规范创建软件的人，我发现很难认真对待所有的担忧。
编码可能是一个挑战，但我从来没有花超过两周的时间试图找出代码的问题所在。一旦你掌握了语法、逻辑和技术的窍门，这是一个非常简单的过程——大多数时候。真正的问题通常集中在软件应该做什么上。创建软件最困难的部分不是编写代码，而是创建需求，而这些软件需求仍然由人类定义。
本文将讨论需求和软件之间的关系，以及人工智能需要什么才能产生良好的结果。
这不是一个错误，而是功能...不等了，这是一个错误
在我软件生涯的早期，我被安排在一个项目中游，以帮助提高团队的速度。该软件的主要目的是在电子商务网站上配置自定义产品。
我的任务是生成动态条款和条件。有条件的措辞取决于所购买的产品类型，以及由于法律要求，客户位于哪个美国州。
在某些时候，我以为我发现了一个潜在的缺陷。用户将选择一种产品类型，这将生成适当的条款和条件，但进一步的工作流程将允许用户选择不同的产品类型和预定义的条款和条件。这将违反具有客户签名的业务要求中明确商定的功能之一。
我天真地问客户，“我应该删除允许用户覆盖正确条款和条件的输入吗？从那以后，我得到的回应一直在我的大脑中灼烧。他的原话是完全自信地说的;
“这永远不会发生”
这是一位在公司工作多年的高级管理人员，了解公司的业务流程，并且出于某种原因被选中监督软件。覆盖默认条款和条件的功能是由同一个人明确要求的。我到底是谁来质疑任何人，更不用说一家付钱给我们制造这个产品的公司的高管了？我耸了耸肩，很快就忘记了这件事。
几个月后，就在软件上线前几周，客户端的测试人员发现了一个缺陷，并将其分配给了我。当我看到缺陷的细节时，我笑出声来。
我对推翻默认条款和条件的担忧，我被告知的事情永远不会发生？猜猜发生了什么？猜猜谁被指责，谁被要求修复它？
修复相对容易，并且错误的后果很低，但这种经历一直是我职业生涯构建软件中反复出现的主题。我已经和足够多的软件工程师同行交谈过，知道我并不孤单。问题变得更大，更难解决，成本更高，但问题的根源通常是相同的：需求不明确、不一致或错误。
现在的人工智能：国际象棋与自动驾驶汽车
人工智能的概念已经存在了相当长的一段时间，尽管高调的进步引起了媒体和国会的关注。人工智能在某些领域已经非常成功。首先想到的是国际象棋。
人工智能早在 1980 年代就已应用于国际象棋。人们普遍认为，人工智能已经超过了人类在国际象棋中获胜的能力。这也不足为奇，因为国际象棋的参数是有限的（[但游戏尚未解决]
国际象棋总是从32个方块上的64个棋子开始，有充分的官方同意规则，最重要的是有一个明确的目标。在每个回合中，都有有限数量的可能移动。下棋只是遵循规则引擎。人工智能系统可以计算每一步的影响，以选择最有可能的动作结果来捕获对手的棋子或获得位置，并最终获胜。
人工智能在另一个方面一直非常活跃——自动驾驶汽车。制造商已经承诺自动驾驶汽车很长一段时间了。有些有能力自驾，但有一些警告。在许多情况下，汽车需要主动监督;驾驶员可能需要将手放在方向盘上，自动驾驶功能不是自主的。
与下棋的人工智能程序一样，自动驾驶汽车主要使用基于规则的引擎来做出决策。与国际象棋程序不同，关于如何驾驭每种可能情况的规则没有明确定义。在给定的行程中，驾驶员会做出成千上万的小判断，避开行人，绕过双停放的汽车，并在繁忙的十字路口转弯。做出正确的判断意味着安全到达商场还是到达医院之间的区别。
在技术上，可用性的标准是五个甚至六个 9 ——一个网站或服务在 99.999%（或 99.9999%）的时间内可用。实现前 99% 的成本并不高。这意味着您的网站或服务每年可能会停机三天（87.6 小时）以上。但是，对于最后添加的每 9 个，到达那里的成本呈指数级增长。当您达到 99.9999% 时，您每年只能允许 31.5 秒的停机时间。它需要更多的计划和努力，当然也更昂贵。获得前 99% 可能并不容易，但从比例上讲，它比最后一小部分更容易、更便宜。
365 X 24 X 60 分钟 = 每年 525，600 分钟
99% 可用性 -> 下降 5256 分钟，87.6 小时 99.9% 可用性 -> 下降 526 分钟，8.76 小时 99.99% -> 52 分钟，少于 1 小时
99.999% -> 5.2 分钟 99.9999% -> 0.52 分钟
，大约 31.5 秒
无论人工智能有多接近足够好，总是存在事故和死亡的风险。这些风险和后果每天都在人类驾驶的情况下发生。我不知道政府可以接受多大的事故和死亡率，但你必须认为它至少需要和人类一样好。
之所以很难达到可接受的安全水平，是因为驾驶汽车需要比国际象棋更多的变量，而且这些变量不是有限的。前 95% 或 99% 可能是可预测且易于解释的。然而，在前 99% 之后有很多边缘情况，每个情况可能都有一些特征，但每个特征都是独一无二的;其他人驾驶的道路上的其他车辆，道路封闭，施工，事故，天气事件，您在铺设道路但尚未涂上道路分界线的油漆后驾驶了多少次。要让你的人工智能模型能够解释和识别这些异常和边缘情况，更重要的是，如何在不发生事故的情况下做出适当的反应，要困难得多。每个边缘情况可能共享一些特征，但它们很少是相同的，这使得人工智能更难确定适当的响应方式。
AI不能创建软件，只能创建代码
创建和维护软件与驾驶比下棋有更多的共同点。涉及的变量要多得多，规则是基于判断调用的。当你在构建软件时，你可能会有一个想要的结果，但它不太可能像国际象棋那样单一。软件很少完成;添加功能并修复错误;这是一项持续不断的练习。与软件不同，一旦国际象棋比赛赢了或输了，它就结束了。
在软件开发中，我们确实有一个工具可以让我们的软件设计更接近国际象棋严格控制的规则引擎：技术规范。在最佳情况下，规范会遍历预期的用户行为和程序流。以下是用户购买电子三明治的方式：单击此按钮，创建此数据结构，运行此服务。然而，这很少是我们得到的。很多时候，我们会收到愿望清单，包括功能规格、餐巾纸后面的线框图和不清楚的需求文档，并被告知要做出最佳判断。
更糟糕的是，需求发生变化或被忽略。最近，我被要求帮助一个团队建立一些东西，以帮助人们获得与COVID 19相关的健康问题的信息。该应用程序将适用于全球没有可靠WIFI的地区。该团队希望我帮助构建一个可以通过短信（电话短信）进行调查的应用程序。最初，我很高兴能参与其中。
一旦我开始听到团队描述他们认为他们想要什么，我意识到这将是一个问题。对于零售公司来说，以 1-10 的等级询问您再次在他们的商店购物的可能性是一回事。用多项选择题进行多步骤调查，了解您可能感染 COVID 的症状，这是非常不同的。我从来没有说不，但我确实提出了这个过程中所有可能的失败点，并希望团队清楚地定义我们将如何处理所有问题的答案。它会是映射到每个答案的逗号分隔的数字吗？如果提交的答案未映射到任何给定的选项，会发生什么情况？
在所有这些问题之后，团队得出了相同的结论。我们决定最好不要这样做。信不信由你，我会说这实际上是一个成功的结果。在提交无效用户数据时，如果没有明确解决所有潜在错误的明确解决方案，那将更加浪费。
使用人工智能创建软件背后的想法是否只是让这些利益相关者直接与计算机交谈以创建基于短信的调查？人工智能是否会提出关于如何处理通过短信收集调查数据的所有可能问题的探索性问题？它是否会解释我们作为人类在此过程中可能做错的所有事情以及如何处理这些失误？
为了从AI生成功能性软件，您需要知道自己想要什么，并能够清晰准确地定义它。有时候，当我为自己编写软件时，直到我真正开始编写代码，我才意识到一些困难和挑战。
在过去的十年中，软件行业已经从瀑布式方法过渡到敏捷。瀑布在编写任何代码之前准确定义您想要的内容，而敏捷提供了足够的灵活性，因此您可以在此过程中进行调整。
许多使用瀑布的软件项目都失败了，因为利益相关者认为他们知道自己想要什么，并认为他们可以准确地描述它并记录它，只是在交付最终产品时非常失望。敏捷软件开发应该是这个过程的解毒剂。
人工智能可能最适合重写我们已经拥有的软件，但需要重写它以使用更新的硬件或更现代的编程语言。仍然有很多机构使用COBOL编写的软件，但是学习如何使用它的程序员却很少。如果你确切地知道自己想要什么，也许你可以让人工智能比人类程序员团队更快、更便宜地生产软件。我相信人工智能可以比人类程序员更快地创建软件，但那是因为有人想出了该软件应该做什么。
人工智能实际上可能很好地使用瀑布过程构建软件，这也被称为死亡行军。你知道谁在瀑布上很糟糕吗？我们是人类。这并不是因为将签名的文档交给程序员团队以便他们可以编写代码的部分。这是在那之前的一切。人工智能可以做一些非凡的事情，但它不能读懂你的思想或告诉你应该想要什么。
