DOP 291: The Future of Software Development in an AI-Driven World
51:42 Share

#291: 随着我们接近2024年底，科技行业一个反复出现的主题是人工智能对软件工作的影响。虽然一些人担心大规模的工作流失，但另一些人则看到前所未有的创新机会。在某些方面，似乎就业市场正在经历类似于工业革命的变化。然而，与科幻叙事《终结者》中对机器人接管的恐惧不同，目前的担忧根植于人工智能自动化传统上由人类担任的角色。在这一集中，我们与Fitch Group的首席软件官Derek Ferguson讨论了新技术如何历史性地创造对新技能和角色的需求，暗示人工智能可能会打开大门，而不是关闭它们。Derek的联系信息：LinkedIn: https://www.linkedin.com/in/derekmferguson/ YouTube频道: https://youtube.com/devopsparadox 在Apple Podcasts上评论播客: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ 与我们联系: https://www.devopsparadox.com/contact/</context> <raw_text>0 我听过一句话，你的工作不会被人工智能取代，但你的工作可能会被一个比你更懂得如何使用人工智能的人取代。这才是关键。这是DevOps Paradox，第291集，人工智能驱动世界中的软件开发未来。欢迎来到DevOps Paradox。这是一个关于随机事物的播客，我们，Darren和Victor，假装我们知道我们在说什么。

大多数时候，我们通过到处使用DevOps这个词来掩盖我们的无知，并将其与Kubernetes、无服务器、CICD、团队生产力、幸福岛等随机流行词混合在一起，这让我们听起来像是知道自己在做什么。偶尔，我们会邀请一些确实知道一些事情的嘉宾，但我们并不常这样做，因为他们可能会让我们看起来无能。

真相就在那儿，但我们绝对找不到它。是的，是Darren在读这段文字，并感到尴尬，因为Victor让我这么做。这里是你的主持人，Darren Pope和Victor Farsen。Victor，我们快到2024年末了。我简直不敢相信2024年已经结束了。我们俩仍然有工作，但有些人开始失去工作。而有些人开始找到了工作。

如果你在100年前或更早的时候做这样的介绍，那也是同样有效的，对吧？这非常真实。但他们的恐惧并不是来自2025年的机器人或《终结者》出现的时间。我已经失去了对Skynet何时接管的追踪。在今天的节目中，我们请来了Derek Ferguson。Derek，你好吗？我很好，谢谢。你呢？很好。那么我们将讨论...

人工智能可能会杀死软件工作。但正如Victor所暗示的，也许人工智能意味着现在是新的招聘热潮，只是并不是针对提示工程师。这是否接近？我回顾了新技术和新做法进入软件工程的历史先例，比如从汇编语言到C，从C到Java，等等。

每一次生产力都在增加，我认为从C到C的生产力提升大约是300%。而且在那之后需求激增，因为当你能够用相同的资源做更多的软件时，人们会发现以前从未想到过的软件用途。如果你想想

当汇编语言和纯二进制是你唯一的编码方式时，软件的状态。那些只是军事应用，对吧？你需要巨大的金属才能运行它们。没有人曾经想到过消费软件，对吧？突然间，这变得可能。我倾向于乐观。我是一个普遍的乐观主义者，但这是其中之一。当我们看到生成式人工智能编码带来的生产力提升时，

这些提升在25%到50%之间。远没有以前跳跃的幅度。我并不是说它不会达到那个水平，因为，正如人们常说的，这是我们将使用的最糟糕的人工智能，但确实如此。

一般来说，我们看到每一代新软件技术的出现，它都能实现以前从未梦想过的用例。然后需求增加，有人需要维护所有这些东西。因此，我对这一切仍然保持乐观。我觉得关于人工智能的悲观预测的主要缺陷

是你之前提到的，它们都假设输出将是相同的。这导致了不可避免的结论，即好吧，我们需要更少的人来产生相同的输出。而我的理解，以及我想你所说的，也是，我们可以改变输出。这才是关键。这是人们在某种程度上忽视的。

我将能够独自完成这项工作。我不再需要我的团队。就好像这一切都保持不变。人们将会做不同的事情。我常常告诉为我工作的大学毕业生，我的毕业设计，我讨厌提及这个，但

在我大学毕业时，实际上是一个网页。那时，这就是常态，我们很高兴能在顶部加上滚动的横幅。甚至在跳舞的婴儿年之前。如果你还记得，那现在甚至不会算作一个完整的作业，对吧？因为人们不再手工制作HTML。我认为十年后，这将是一个

专业程序员的半天编程任务，从头到尾创建一个做X、Y、Z的应用程序。但这并不意味着软件会减少，因为消费者的需求总是在增加。

成比例地，对吧？无论你的公司在做什么，你的竞争对手也会拥有相同的工具。因此，他们会，嗯，很难预测，但也许我们将进入一个为每个客户创建定制应用程序的时代，因为我们在软件开发和维护方面有那么大的能力。

这才是真正的杀手。当我们想到悲观的情景时，我们通常会想到你生产软件，然后它是完美的，永远不需要任何修改。但我们都知道，当然，这不是现实世界。尽管生成式人工智能可以使我们创建大量软件以进行修改，并以智能的方式进行修改，但你仍然需要了解控制背后基础知识的人，对吧？

让我们来演绎一下场景，现实世界的场景。既然你提到了一些短语，现实世界就是其中之一。我会相信在未来的某个时刻，我们将能够描述一个应用程序，并期望在一天结束时它就能投入生产。从零到生产只需一天。我相信这一点。但我不相信，好的，但假设我相信这一点只是为了让你高兴，Victor。好的。

我对它的问题是，当第二天开始出现更改时会发生什么，我不能指望人工智能或其他任何东西来重写该应用程序以匹配客户的要求。或者我可以吗？你可以达到人工智能能够进行一些修改的程度，但我认为你仍然，意思是，这就像飞机上的自动驾驶仪，对吧？

我们在飞机上有自动驾驶仪多久了？然而，我们现在才开始谈论完全无人驾驶飞机的可能性。我认识的大多数人对此仍然不太舒服，对吧？你可能会达到这样的程度，你有一个人工智能可以建议，嘿，我认为你想在这个修改中做什么。

我认为在我们完全舒适地让人工智能在没有真正了解情况的人的监督下进行这些修改之前，还需要很长一段时间。绿地开发本质上比已经有数据在数据库中并将以某种方式修改代码的情况要安全得多。只需一个错误的

drop table命令放错地方，或者某种误解，你知道吗？好吧。当你说要进行修改时，我假设你是说从头开始进行修改，对吧？你不需要任何麻烦的数据，对吧？所以我认为在很长一段时间内，人类将会参与其中。因此，我认为你的担忧是，尽管我可能对软件提出修改建议的能力持有更乐观的态度，但我在许多情况下看到

我认为我们离人工智能能够在没有监督的情况下做这样的事情还远得很。我认为人们在很长一段时间内不会对此感到舒适。我知道我不会。那么你所说的是我将退休。顺便说一下，当你说你的毕业设计是创建一个HTML页面时，我在没有HTML的情况下大学毕业。所以我们就不谈这个了。你用过blink标签吗？如果你用过blink，那么你一定通过了。是的，我用过。

你将退休。我将退休。Victor将退休。当这一切发生时，我们的孩子会退休吗？你是在谈论像10岁的小孩吗？所以在50年后，如果我们继续这样推演，对吧，让我们继续。对我来说，你现在设定的绿地开发，我将其视为Spring Boot或任何其他类似的引导工具的增强版。

我们可以更快地定义它。使用Spring Boot是因为我是一名老Java程序员，但还有很多其他选择。我认为这是真的。在五年内，你的愿景似乎是半实用的，如果不是完全实用的。但接下来是修改的第二天。这在50年后会发生吗？到那时我将死去。所以这将很简单。50年的视野是如此有趣。

我并不是这方面的专家，但大多数关于量子计算的预测在50年的时间范围内都是相当革命性的。一旦你获得那种计算能力，各种不同的场景都会改变，对吧？我的意思是，一旦你能够用蛮力解决大量问题，并处理所需的数据...

以实现某种通用人工智能。这是一个棘手的问题。我认为任何试图弄清楚50年后会是什么样子的人，我对这一点仍然保持乐观。我的意思是，如果你考虑到那种超人类的计算能力，显然有能力解决超人类的问题，对吧？气候变化、疾病，所有这些东西。是的，但他们能否提供动力？

我不是刚听说很多试图生产下一代LLM及其后续版本的公司，开始转向自己的私人核电源、自己的发电机等。是的。所以，你知道，好吧，我们在这里走得太远了。

让我们试着把它拉回到今天。尽管我不同意Victor的看法，我认为引导过程可以比我们今天的许多事情更好。Victor，你同意吗？也许不是完整的应用程序，但引导至少会更进一步。哦，是的。我认为整个软件行业的历史，包括人工智能，都是关于简单任务变得更容易，对吧？

一些任务变得如此简单，以至于你不再需要一个完全合格、经验丰富的开发人员来完成它们。因此，作为这些变化的结果...

我们作为开发人员需要做的事情变得更加复杂，对吧？这没有意义。我永远不会... 我不认为任何公司会雇用纯HTML开发人员，对吧？我们不再需要这些，因为这太简单了。20年前、30年前或更早的时候并不一定简单，但现在是。

以前被认为是开发人员工作的现在在最佳情况下被认为是初级职位，对吧？在最佳情况下。最有可能甚至不是这样。这迫使开发人员思考解决更复杂的问题，因为简单的事情变得容易。我认为这已经持续了很长一段时间。从这个角度来看，我现在在概括，我看到人工智能只是...

又一次推动，嘿，你不需要专注。你可以专注于复杂的事情，因为简单的事情已经处理好了。别担心。需要注意的是，什么是简单的定义正在改变，仅此而已。我有时会想到这个模型。我的妻子是一名护士，她的母亲也是。

当她的母亲开始当护士时，人们在医院里住一周以接受扁桃体切除手术，所有这些事情，对吧？医院是一些人接受小手术并住很长时间的地方，还有一些人有严重的病情。

现在可不是这样，对吧？你知道，所有能走路的人都在24小时内进出医院。因此，护士和医生的工作，实际上，他们看到的病人更多，花更多时间在真正生病的病人身上，而不是给那些不太生病的人提供同样的护理。

整个事情变得更加高效，因为出于各种原因，我们已经找到了在家治疗更多人的方法，所有这些事情。但普通医疗专业人员的日常工作已经从处理一些不太生病的人和一些非常生病的人变成了一个稳定的病人队列。

如果你在医院环境中，病人非常生病，因为这就是定义。我性格中更愤世嫉俗的一面想知道，30年后，软件开发会是怎样的？我们是在处理那些非常棘手、困难的问题，还是更乐观地说，正如你所表达的那样，我们只是在处理所有非常有趣的问题？我喜欢认为我们只会处理有趣的问题。问题是，我认为处理有趣问题的一个问题是

我们的管理者是否在乎它们是否有趣？因为一旦他们看到，也许不是管理者，但在更高层次上，人工智能可以为我们节省这么多钱。所以让我们把人工智能放在所有这些酷炫的事情上，让人类处理那些人工智能仍然无法解决的乏味和单调的事情。我认为这是竞争因素。我总是回到这一点，因为这从来不是孤立进行的，对吧？我们的老板，竞争对手也可以使用相同的工具。因此，无论他们

生产什么，或者他们做什么，或者他们做出的任何削减，都会在我们这边复制。就让我们以悲观的情况为例，他们不是在构建更多，而是用相同数量的人，或者用更少的人来完成相同的工作。历史表明，这总是会恢复，因为在你获得这些效率之后，你会说，好吧，好的。是的，您知道，我们将做任何需要做的事情来获得这些效率。接下来发生的事情是，

客户想要更多。一些竞争对手推出了新的服务产品，然后所有该公司的竞争对手都需要拥有相同的服务产品，这总是会恢复。因此，我认为即使在短期内，行业走向了利用成本节约而不是生产力提升来构建更多东西的方向。这总是会被视为短期行为，因为你

人类，作为我们这样的生物，感谢上帝，始终会有新的想法。人们需要进来构建这些新想法。随着这些想法的出现，你会恢复并最终需要引入更多的人。总会有公司。总会有公司会...

拒绝变革，对吧？拒绝那些生产力提升，并说，我们一直这样做，这对我们有效，等等。总会有这样的公司。只是他们最终会消失，对吧？即使在人工智能之前，这种情况也一直在发生，对吧？所以我不认为所有公司都会采用它并变得更具生产力，对吧？

只是有些会，有些不会，他们将不存在。我听过一句话，你的工作不会被人工智能取代，但你的工作可能会被一个比你更懂得如何使用人工智能的人取代。这才是关键。因此，回到人工智能帮助我们，工具不再，或者实际上工具是竞争优势或不是竞争优势，这取决于你怎么看。听起来在未来，

如果你想真正成为我们所认为的“真正的程序员”，你将为一个供应商工作，因为那些人正在解决大问题。而供应商的消费者只是将标准、简单的业务应用程序引导起来。然后几乎没有其他事情发生，除了仍在后台运行的主机系统，支付所有账单。是的，但看看今天。这不仅仅是供应商，对吧？Netflix正在解决真正的问题。

Netflix不是一个供应商，至少不是一个软件供应商，对吧？他们处理复杂的事情。但这些是特例。但你看，他们是一家技术公司。不，他们不是特例。他们是幸存者，对吧。但对我来说，Netflix不是像Blockbuster试图成为的流媒体公司。Netflix是一家技术公司，恰好伪装成流媒体公司。

不，Netflix是一家流媒体公司，明白他们需要成为一家技术公司。好吧，他们是一家DVD公司，决定他们需要成为一家技术公司。我仍然不同意你的看法。那么Derek，你在这里开始插话。你认为这在什么方面发挥作用？老实说，就Netflix而言，我倾向于将他们视为一家娱乐公司，理解技术。

技术是他们前进和保持竞争力所需的。我认为有很多公司说我们是一家技术公司，但这只是恰好是我们的垂直领域。而且，我确实有点愤世嫉俗。我认为到头来，你看看这些公司的权力结构，谁真正掌控着局面。是销售和商业，还是技术人员？

在大多数公司中，我认为你会看到是销售，或者在Netflix的情况下，也许是创意人员，实际上是创造内容的人在掌控。因此，我倾向于认为，关于是否只有ISV在解决大问题，而其他人只是使用他们的打包软件，我认为不是，具体原因是

因为在大多数组织中，实际上是业务，实际上是为销售创造东西的人在主导。

他们很少满足于使用现成的东西，对吧？每个企业都相信他们的用例只是稍微不同。是的，那对ABC公司有效，你知道，我们的一个竞争对手，但我们做的事情稍微不同。我们需要那个变化。

只要这种权力动态存在，我认为总会需要不同组织中的人进行这些定制和维护这些定制。即使只是监督一个制作和维护这些定制的人工智能，我也不认为一切都会转向集中模式，因为我不认为企业会说，是的，你知道，我们将完全按照打包软件的现成方式来做事情。让我们谈谈权力动态。

再次强调，现在是2024年。这些大型ISV中负责的大多数人和我同龄，五十多岁，六十岁出头。当我们开始老去，下一代接替时，这是否仍然会成立？我想我的女儿。她三十多岁。我们处理业务的方式非常不同。因此，我在想，随着我的一代人逐渐老去，下一代接替，

那些相同的驱动因素是否会继续存在？我的意思是，我可以说这在金融服务、任何直接涉及金钱的领域可能会成立，但其他事情，我认为一切都不再确定。当你这一代人离开时，我们终于能够摆脱主机和DB2。你认为吗？在这里，我现在要下个赌注。主机将在...

我在66岁时将年满一百岁。到2066年，仍然会有主机在运行。IBM仍然会在主机上赚得盆满钵满。仍然在主机上赚得盆满钵满。是的。根据这样的说法，听起来不仅仅是你认为它们会存在，因为移除它们的成本太高。

你认为它们实际上会继续被积极发展并提供价值？这就是它们仍然存在的原因。我对这个观点很感兴趣，因为我以为你会说，看看，这些东西已经存在了这么久，它在这么多事情中都有影响。企业根本不值得花时间和精力去摆脱它。但听起来几乎是——我超越了这一点。我是说，那是基础。

因为在我看来，你不可能在金融服务中摆脱主机。好吧，2066年可能太远了，但这将是困难的。好吧，那可能是真的。你能否摆脱使用它们的金融服务？并不是说他们摆脱主机，而是完全摆脱它们。

金融科技。我没有考虑过摆脱金融服务。那会是... 不，不是金融服务。金融服务存在了这么久，他们仍在使用并无法停止使用主机。所以你基本上是在说零售银行消失，可能商业银行的部分消失并被重新构想。被其他商业银行取代。无论是什么，对吧。是的。我认为这将是你摆脱它们的唯一方式。

大型美国银行，大型欧洲银行，他们都是主机。大型航运公司，主机。我们怎么... 我是说，这变成了让我们杀死主机，但我们真的需要杀死主机吗？我认为我们不需要。它仍然是许多事情的正确工具。只要它的接口继续发展，以便你能够获得继续运行它所需的人才，对吧？这将是真正的挑战。比如，

20年后，真的能找到那些知识渊博、经验丰富并愿意使用COBOL作为编程语言的人吗？或者为了继续保持这些主机的运行和活跃，是否有必要为它们提供所有最新的编程接口，以便人们想要使用？React和Python以及所有这些东西。我认为...

我的意思是，我不再像以前的职业那样接触主机，但我认为他们在主机环境中提供一些现代东西的实现方面做得相当不错，对吧？我认为是的。但这一直都是如此。我们回去看看。这回到再生故事，博士的引用，一旦某样东西进入，

人们看到，哦，让我们在那上面堆积，直到它变得，你知道，因为人们想要越来越多的东西。因此，一旦我们意识到，顺便说一下，Kubernetes不过是一个主机，我不得不把这个放进去，剩下的事情留给人们去做。我的意思是，我认为你的答案是，一旦我们为COBOL程序员支付每小时300到400美元，经过通货膨胀调整，20年后实际上仍然只会是每小时10美元。总会有人做那些其他人不想做的琐事的工作。找到这些人会很困难

但并不是不可能。回到人工智能的话题，我想知道，翻译，无论是人类语言还是软件语言，难道不是人工智能应该具备的核心能力之一吗？我的意思是，这已经是它最强大的优势之一。我倾向于认为，如果你考虑到

人工智能构建绿地软件以及处理人类告诉它想要什么的复杂性，以及随之而来的所有模糊性。你把这一点放在一边，然后在另一边说，嗯，使用人工智能将已经存在的软件从一个环境翻译到另一个环境，这并不难想象。我实际上认为这可能更接近于人工智能可以做到的短期事情

100%并且正确，而不是处理人类并接受模糊的绿地开发需求。因此，我几乎认为，如果你有一个在主机上运行的系统，想象一个LLM拥有足够的主机系统知识和现代技术知识，你可以潜在地进入并说，

在更近的未来，嘿，我有所有这些AS 400的东西。它全是用COBOL写的。你能给我一些干净的Java和React来替换它吗？这就是那种事情，特别是像基于代理的人工智能。我实际上可以真正设想完成的事情。我认为这可能是真的，因为COBOL的历史比Java还要长，信不信由你。有些人可能认为这很疯狂，但，

但如果我们能够得到一个好的模型，应该有足够的COBOL语料库，以至于我们不再需要人类来完成它。但你是在说将其从COBOL翻译成Java加React或你想做的任何东西。这并不重要。但这真的是我们希望人工智能为我们做的事情吗？我的意思是，我认为答案是肯定的，但同时答案是否定的，因为在它写的两行中会有细微差别，可能会导致...

#291: 随着我们接近2024年底，科技行业中一个反复出现的主题是人工智能对软件工作的影响。虽然一些人担心大规模的工作流失，但另一些人则看到前所未有的创新机会。在某些方面，似乎就业市场正在经历类似于工业革命的变化。然而，与科幻叙事《终结者》中对机器人接管的恐惧不同，目前的担忧根植于人工智能自动化传统上由人类担任的角色。在这一集中，我们与Fitch Group的首席软件官Derek Ferguson讨论了新技术如何历史性地创造对新技能和角色的需求，暗示人工智能可能会打开大门，而不是关闭它们。 Derek的联系信息：LinkedIn: https://www.linkedin.com/in/derekmferguson/ YouTube频道: https://youtube.com/devopsparadox 在Apple Podcasts上评论播客: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ 与我们联系: https://www.devopsparadox.com/contact/</context> <raw_text>0 为公司赚取大量资金，或者让其沉没。这是对开发者的乐观预期。至少在理论上，这应该比人类语言更容易，对吧？因为没有歧义。代码就是它所做的，完毕。没有……我的意思是，我们可能会难以理解代码的作用，但代码是精确的。它就是它所做的。那里没有疑问。我们只是无法理解它的作用。

接着你之前所说的，即使现在最大的问题不一定是我们无法将这些东西重写成更好、更现代的东西。这不是问题。问题在于我们无法确保我们刚刚构建的东西与我们拥有的东西做的是同样的事情，对吧？如果我用Go重写我的大型机……

这比确认它是否按预期工作要困难得多。即使你不使用人工智能来重写东西，只需过去告诉我这段代码是否在功能上与那段代码相同。我甚至会接受这一点。它不需要做所有的工作。我认为在大型机系统上，完整的单元测试套件的存在……

可能比Java等语言的可能性要小。因此，也许你可以看到将一堆Java代码迁移到Python，因为可以推测，创建这些Java代码的人希望已经进行了单元测试，而这可以成为……我认为一些专注于翻译工作的基于代理的人工智能就是这样。

对吧？你知道，他们查看单元测试屏幕，做出他们认为合适的更改，重新运行单元测试，然后集中精力解决失败的测试，以找出他们需要在代码中重新生成的内容。但你之前提到的关于人工智能翻译在从COBOL到Java的过程中会错过细微差别的说法很有趣。当我回顾从

简单语言转向C的时代时，当然那时也有很多这样的说法，对吧？就像，当我处于单个CPU指令的层面时，我可以调整它们，挤出最后一点性能。而你知道，这个C编译器总是会给我这些可能不适合情况的代码块。但随着时间的推移，CPU的

计算能力呈指数级增长，这种担忧变得越来越小，对吧？因为人们会说，嗯，我们拥有的处理能力比几年前多得多。如果代码在C下的效率不如以前，谁在乎呢？

我认为这里也可能是这样，对吧？你会有创建的软件的人工智能，可能没有经过优化，但然后A，这变成了开发者的工作，去查看人工智能提供的10个不同建议，并选择最有效的一个，同时满足业务需求，然后B，事后进行那些小的调整和修改。就像第一批C开发者一样，我们总是进入……

调试器，查看生成的底层代码，并进行很少有人现在会做的调整。对。你会对像我这样的人有什么建议，他们对人工智能感到满意，但今天并没有看到太多价值？你会怎么对我说？就像，忍耐吧。你已经太晚了。继续退休吧。答案是什么？

太早了。正如我所说，另一个我经常听到的说法是，这是你将使用的最糟糕的人工智能。就在昨晚。所以我做这些季度员工更新，现在是时候做Q4员工更新了。因此，我回去查看了Q3员工更新。很有趣，因为其中一张幻灯片上有一张三个月前的人工智能生成的图形。

我想，你知道，让我回去实际尝试生成相同的图形。它并不复杂。它是其中一个15个方块的拼图，孩子们的拼图，你有15个数字在一个网格上。其中一个缺失。你必须滑动它们以获得正确的顺序。因此，我三个月前要求人工智能做到这一点。我说，把软件开发者的职位名称放在这些方块上。

而当时人工智能经常做的事情是，它无法正确地将单词放在方块上。它全都搞乱了。因此我昨晚又试了一次，它是照片级真实的，并且标记正确。相同的系统，但模型在三个月内仅仅改进了那么一点。因此

我想我会说给它一些时间，你知道，我甚至不会说你需要给它更多的时间。事情正在以相当快的速度增长。我还想说，在我与基于人工智能的代码生成的经验中，你只需记住，我们第一次在广泛的基础上处理非确定性算法，这意味着

在大多数情况下，你必须问几次并提供反馈，以获得你所寻找的东西。但一旦你克服了这个障碍，并意识到这是一个期望与你互动并期望更多指导的模型，你将获得更多的生产力，即使你必须要求人工智能给你一个代码块五次才能得到你想要的东西。一旦你得到了你想要的东西，

将那个代码块复制并粘贴，按照行业估计，你的生产力仍然提高了25%到50%。对我来说，我觉得这非常吸引人。现在人们也是如此。如果你向开发者请求一个代码块，你不会得到你想要的代码块。这就是我们进行代码审查的原因，对吧？

这就是我们在那个代码块上反复讨论，直到它刚好合适或至少可以接受。因此，并不是说你刚才所说的，嘿，你需要问几次并改变你的提问。这在没有人工智能的情况下也在发生。确实如此。我们现在只是更快地获得代码块。我想这是周期。因此我现在听到的是……

工程经理，老板们，实际上可以完成所有编码，他们实际上不需要任何人类程序员。那么这是否意味着工程经理现在成为开发者，整个链条被向下推？不，因为我认为如果是50%的生产力提升，需求提升将达到60%。如果是25%的生产力提升，生产力需求将增加35%，对吧？

但这不是危险吗？现在你把人类推向超出机器能够帮助他们完成的事情。这在某种程度上总是如此，对吧？我们的欲望总是稍微超出我们的掌握。这就是推动我们构建新工具的动力，对吧？自人类诞生以来，人们就想要比他们能轻易获得的更多。因此，人们必须弄清楚

如何聪明地工作，而不是努力工作。这就是工具在许多方面作为一个物种的优势。我知道显然其他灵长类动物也使用原始工具，但我们确实是那个发展和专门使用工具以扩展我们能力的物种。在这种情况下，我并不认为人工智能在根本上有任何不同。我们快速回到15个方块的事情。三个月前你运行了提示并得到了结果，对吧？

现在你运行相同的提示并得到了不同的、更好的结果。你是在自托管那个人工智能模型，还是在使用服务？那是一个服务。因此，我想问的是，大公司是否能够自托管这些模型，并在三个月内看到这样的转变？

基本上，如果你自托管某些东西，通常更新它所需的时间比使用服务要长。这是我的论点。那是一个非常宽泛的概念。但在人工智能方面，似乎比旧的东西要复杂得多。自托管在资源需求达到那种水平时非常棘手。那里的担忧是数据泄露或帮助训练其他人的模型，还是……

其他不同的事情？这不是我的担忧。好的，所以担忧可能来自隐私。但对我来说，这只是会是，好的，从服务中，模型一直在更新，或者至少被调整到看起来像是一直在更新。而在内部，如果我有模型，是的，我把所有东西都放在我的四面墙内，但老板们期望他们在外部世界看到的东西，类似于mid-journey级别的变化。

来自OpenAI的任何东西。但在内部就像，哦，是的，我们抓取了IBM的最新基础模型，因为我们仍然基本上是IBM商店，而这是一个基础模型。我们只是在试图弄清楚如何使其对我们有用。高层老板们看到，好的，所有这些事情在外部发生，但内部没有任何变化。我们仍然以完全相同的方式在内部做事情。人们将如何改变他们的工作，以便于，

训练他们的人工智能统治者，这将在接下来的12个月内接管他们的工作。或者也许问题是，他们不会训练它。因此，他们在12个月内仍然有工作。测试的整个想法，我认为在这个背景下非常有趣，因为质量保证在我进入这个行业的时间里。并且我认为在我们所有人进入这个行业的时间里，一直是一个根本上确定性的任务，对吧？是的。

你输入事实X、Y和Z，你可以合理地期望得到答案A、B和C。到目前为止，我们所有的测试脚本都是以这种期望编写的。我将输入这些输入，这里是我将得到的确切输出。你将LLM纳入方程，事情变得更加有趣。

如果你是一个测试工程师，我认为现在的情况更有趣，因为你必须找出解释结果的方法。而我看到的迄今为止的做法是，你最终会得到LLM实际上作为测试方程的一部分，因为你基本上需要有一个LLM来解释来自另一个LLM的响应。如果你使用的是托管并不断更新的东西，

对这一点的需求变得更加紧迫，因为你正在处理一种快速发展的技术，世界在你脚下不断变化。即使你在前面有像RAG这样的东西，也许你有某种搜索你的内容的东西，或者你习惯于得到的东西。当他们问下一个问题时，你应该得到一个答案，这意味着大约以下内容。如果你有一个模型，它不断更新并且被服务，

也许那个答案从根本上改变。这就是我认为拥有这种敏锐度和回答你之前问题的必要性，自动化测试的需求从未如此之高。

我认为在技术领域我真的非常非常关注的一个技能集是测试技能集，并确保你从手动测试演变为下一代自动化测试，因为这就像一个全新的世界，当第一次从软件中得到的答案在每个层面上都会有所不同。

而且有许多有效的方式来表达同样的事情。这就是我认为需要进行大量投资的地方，即重新审视测试脚本。下一代自动化测试是什么样的？感觉我们仍然在把意大利面扔到墙上。我认为测试必须，我是说，是不是用大炮对抗大炮，或者用火对抗火，取决于你喜欢什么隐喻，但，

它将不得不像它所测试的系统一样融入人工智能。因此你之前提到的RAG。你想要认为，或者我想我应该开始，事情一直以来的运作方式是，如果你去一个系统并提出一个问题，它必须是高度优先的LLM，因此它必须是一个非常具体的查询，也许带有下拉菜单或其他东西，以获得特定的答案。

这就是测试一直以来的传统方式。我们使用像Selenium和Quick Test Pro这样的东西。所有这些东西。只是它用于说，好吧，你在这里输入这些值，你应该在这里得到这些值。但我认为现在我看到更多的是测试工程师和

因为答案将是以自然语言返回的，而即使是同样的问题被问到，短语的表达方式在每次调用中都会有所不同。测试脚本需要在后端集成一个LLM，带有一个非常具体的提示，即，我希望你查看这个

已输入的句子或段落。我希望你告诉我，如果它归结为以下事实，我希望你告诉我不，如果不是，这样你实际上就有一个LLM在测试方面，能够处理响应可能返回的变化和措辞。我们认为，

下个月的温度将比现在高30度。下个月，我们认为它将达到100度。你可以用不同的词表达同样的想法的所有不同方式都必须由后端的测试脚本解释，该脚本使用LLM来表示，

你可能会看到用一百种不同的方式表达，但归根结底，唯一合适的回应是告诉你下个月的温度预测将是100度。如果你得到的响应等同于此，给我一个通过。如果不是，给我一个失败。这就是我认为质量保证需要去的地方。我认为，质量保证在接下来的五年里将成为一个更加技术导向的职业。我认为，

在人工智能时代，手动测试。我不知道这是否会切合实际。我真的希望这个回应在我们开始谈论人工智能之前就早就出现。老实说，我仍然不明白如今大规模的手动测试是如何进行的。我明白，好吧，妈妈和爸爸的商店，你创建了一个网站，

你尝试一下，所有这些东西。我明白你是如何手动测试的。即使我也不会浪费时间以任何形式或方式编写自动化测试。但像谷歌这样的大型项目，对吧？忘掉人工智能。我不明白人们如何仍然被期望手动测试。

现在，当我们谈论数百万用户时，随机部分的用户，没有人能预测他们的行为。我们谈论的是成千上万的开发者。我们谈论的是每天多次发布到生产环境。我们甚至如何仍然在谈论手动测试超出了我的理解。我倾向于同意。然而，我认为在许多情况下，我们仍然是这样。这很有趣，因为它涉及到整个……

关于我们是否朝着一个模型发展的对话，其中要求被记录到不需要SME进行测试的程度，还是它们是高层次的要求

而你有开发人员和测试人员，他们对自己所在的行业了解得足够好，以便能够在要求之上进行这些解释并正确完成。我见过两种方式。最糟糕的组合可能是你试图将不精确的要求与不特别接近业务的技术人员配对。

并且无法进行那种解释，这是一个独立的话题。但就你的观点而言，无论你是否有人工智能，许多相同的问题仍然存在。我认为人工智能所做的是加剧糟糕的情况，并可能加速良好的情况。如果你有那些基本的良好实践，

你将比那些稍微滞后并未制定正确政策和程序以及做事方式的人更好地为人工智能做好准备。我想插入关于文档的一件事。这让我们回到了业务需求文档。是的，那些东西曾经是一个东西。我认为在某些领域仍然是一个东西。我可以看到一个完全完善的业务需求文档是为测试代理文档提供支持的。

这就是规则。我是说，这就是我们总是应该手动测试的内容，是否涵盖了所有案例？更有趣的是，测试代理现在实际上可以，嘿，你考虑过这些事情吗？回到银行。我们想进行转账。好吧，我们不能进行负转账，对吧？我没有看到这种情况。你想让我为此写一个案例吗？这些事情可能会自动出现。 我觉得你刚刚描述了

在测试期间应该以一种我可以轻松编写代码来验证你的要求是否被实现的方式。 我无法轻松编写代码来验证它是否有意义，这就是我对你刚刚所说的，Darin的理解，对吧？

这就是我认为手动测试真正介入的地方。我不会验证，如果我将这两个数字作为输入，我会得到这两个数字的和作为输出。任何开发者都可以编写验证这一点的代码。是否将数字相加而不是相乘是有意义的，这就是我能做的。我有点理解你所说的……

使用人工智能查看存在于要求下的测试集，并建议可能被遗漏的边缘案例，对吧？正确。我认为这是一个非常有趣的应用。很好。但你们两个都证明了我的观点。我设置了一段文本。我设置了提示，我得到了Victor模型的响应，我得到了Derek模型的响应，它们是不同的。

但现在我们必须解决并弄清楚哪个是正确的。或者它们都是正确的，具体取决于情况？答案是肯定的。欢迎来到编程和人工智能的世界。因此，Derek的所有联系信息将在本集描述中列出。Derek，感谢你今天与我们在一起。非常感谢。我们希望这一集对你有所帮助。

如果你想讨论或提问，请与我们联系。我们的联系信息和Slack工作区的链接在devopsparadox.com/contact。 如果你通过Apple Podcasts订阅，请务必在那里给我们留下评论。这有助于其他人发现这个播客。现在就去devopsparadox.com注册，以便在我们发布最新一集时收到电子邮件。感谢你收听DevOps Paradox。

♪♪♪