作者 | Rachel Laycock
大约两个月前，我成为了Thoughtworks的首席技术官。在那之前，我一直领导Thoughtworks的现代化平台和云服务，而数字化转型的基础就是现代化已经存在于系统内部的软件。领导团队跟我说：“嘿，你即将成为Thoughtworks的首席技术官。祝你好运。在未来的10年、20年里，最具颠覆性的技术即将摆在你面前，你需要关注它。” 我在这个行业已经有20年了，无数次看到一些技术达到炒作周期的高峰，元宇宙、区块链、移动技术，任何你所能想到的，它们的确改变了很多东西。
但对我来说，这一次的不同之处在于，AI 对于Thoughtworks的业务模式多么具有颠覆性。我们通过技术来解决客户的问题，而使Thoughtworks如此伟大的秘密武器是我们交付软件的方式。我们使用的原则、方法以及我们关于持续交付和微服务的书籍都源于我们构建软件的方法。所以当一项技术出现并声称：“嘿，我可以写代码，你不再需要人了。”作为首席技术官，我需要警觉并迅速制定技术战略，这影响着我们向客户交付软件的方式以及我们所要提供的建议。
编码并不是软件的全部
世界上每家咨询公司、每家软件开发公司都雇佣着数百名专注于这个领域的人，因为我们都在互相竞争。我很快意识到，每个人的谈论都集中在编码部分。但我在想，等等，这里好像不对劲。交付软件远不止编码。
多年来，我一直在强调，当人们关注代码时，他们认为构建软件就是坐在电脑前，面对IDE编写代码，这似乎就是全部内容。这也是为什么Thoughtworks多年来一直在使用极限编程实践包括结对编程。多年来，我们的客户一直在问，为什么我要支付两名开发人员的工资来编写相同的代码？这很昂贵。我们不得不做很多解释工作，实际上这是一个巨大的错误假设，因为这项工作是有设计部分的。同时由两个大脑来开发代码，提出的设计方案最终会交付更高质量的代码，更少的缺陷和更低的成本。
技术的快速变迁需要重新构建软件
但真正的问题是，编码并不是全部工作。软件在不断变化。正如我所说，我曾经负责现代化平台和云服务。我认为世界上大约有20%或更少的软件是在云上运行的，毕竟其中许多软件已经存在了很长时间，迁移起来并不容易。现代化是非常昂贵的，因为你并不能简单地重写这些软件。
说到底，你阅读代码的次数要比你编写代码的次数多得多。大约20年前，我大学毕业后的第一份工作被称为系统分析师。那是他们称呼毕业生的方式，这份工作的实质就是修复错误和缺陷，这被看作是让我们了解代码库的一种方式。但我学到的是，编写代码的错误方式和坏的代码风格要比正确方式和好的代码风格多得多。这激发了我的兴趣，想知道如何编写良好的代码，使其易于维护，并允许在未来继续发展业务，而不会受到代码的束缚。因为构建软件不仅仅是关于能多快地构建软件，更是关于是否首次就构建了正确的软件。我们都听说过技术债这个词，技术债越多，改变软件就越困难。
那么我们该怎么办？我们重新构建它。你的组织中有多少系统已经被重新构建过？很多，对吧？否则世界上就不会有成千上万的技术顾问和开发人员不断地重建和重写软件。有时这是因为它最初编写得很糟糕，或者它使用了无法迁移到云的技术栈编写的。但有时是因为你的业务正在变化，你需要新的产品和新的软件。技术就在我们脚下不断变化。
我们一直在借用建筑领域的术语。我的兄弟是一个真正的建筑师，他建造真正的建筑物。当他们在建筑方面做决策时，如果做得正确，它们可以立足百年。而软件却与此完全不同，它是一个不断变化的领域。因为你不断重建代码，而成功与否取决于代码的状态、最初编写时的质量，以及不断变化的业务环境。
关注Thoughtworks的人都知道，我们在过去的10多年中一直在编写技术雷达。雷达的隐喻体现了我们应该关注什么技术、平台、技巧和工具。它是由我们的前任首席技术官出于内部组织的目的而创建的，而伴随着人员的增长，跟踪所有这些变化变得非常困难，所以她创办了一个技术咨询委员会来帮助她理解这一切。
你会注意到每六个月就会有新技术、新平台、新技巧出现。事实上，上一份技术雷达是在上周开始制作的，通常会在一个月左右发布。考虑到目前基于大语言模型和生成式AI的工具太多，我们不得不单独评估它们。与其逐个评估，我们甚至不得不把它们全部放在一起来进行相对评估。这就像一个已经非常疯狂的领域，我们正在处理的复杂性令人难以置信。
生成式 AI 成为新的编码伙伴
让我们回到阅读代码比编写代码更多的话题，回到结对编程以及我们使用这些方法的原因上。
这是Jean Bartik。她是最早的程序员之一。你们可能不知道，在编程的历史上，大多数最早的程序员实际上是女性。她说她们当时总是成对编写代码，因为她们发现这样可以相互检查对方的设计，提出批评意见和更多的想法。我认为这就是生成式AI最令人兴奋的事情之一，因为它也可以做。
在编写代码时，你要把它视为合作伙伴，因为软件工程实践真的很重要。如果你不合作或不进行代码审查，或者不花时间进行设计，而只是继续重写，继续修复错误，你会遇到更多的麻烦。
我们调查了许多主要客户，并将我们与他们的内部软件开发人员以及供应商进行了比较，尽管他们可以更快地推出产品，但这其中也有更多的缺陷、更多的错误、更多的问题、更多的重复工作。
这就是为什么在开发过程的早期你就要仔细地考虑设计的想法。因为最终，当我们到达部署阶段，如果能够持续地部署而没有问题或者问题较少时，我们的成本就会更低。你必须能够全面看待整个开发周期，因为这不仅仅关于编写代码。其实我没有告诉你任何新东西，这些事情早已存在，我们整个行业只是不断地重建软件。
因此，只是考虑生成式AI如何帮助你更快地编写代码，是非常狭隘的。你需要思考整个交付周期，以及生成式 AI 如何成为整个交付周期的一部分。这样，你就可以获得可以工作的、高质量的软件。否则，你只能在小范围内获得好处。
生成式 AI 帮助改进软件流程
一份来自Github的研究表明，人们实际上坐下来编写代码的部分在日常工作中只占26%到27%。所以我们知道开发软件远不止于此。
关于生成式 AI，我们学到的另一件有趣的事情是，即使它可以让人们更快地完成开发软件或删除代码等许多重复任务，好处实际上只存在于中级工程师及以上的级别。因为说到底，它不是Google，它不会给你答案。它只会提供以前已经做过的事情的模式。如果你不是高级工程师，你无法判断得到的信息是真是假，这样反而会减慢开发的速度，接收了太多的选择和太多想法，却不知道哪一个是正确的。
所以当我们思考如何将生成式AI应用于构建软件时，它并不是为了让开发人员更快，而是为了改进整个流程。这将带来很多机会，因为生成式AI可以在软件开发生命周期中为你的人员提供很多帮助。接下来我会快速地介绍一下。
我们拥有的大语言模型在不断变化，目前它在哪些方面表现良好呢。让我们从简单的模式匹配开始。它可以接受自然语言，比如“为我做一些计算”，然后它可以生成代码，对于重复性的任务来说，完成得也不错。正如我前面所说，它对已经具有经验的人来说是一个很好的伙伴。
因为我一直工作在现代化改造领域，而在现代化改造中，一个很大的问题是没有人真正解决大型主机的问题。有多少人尝试过现代化改造他们的主机系统，然后因为成本太高而放弃？人们通常只是重新编写它，或者只是在它周围包一些包装器。
所以我们即将开始进行一些实验，因为如果生成式 AI 可以将自然语言转化为代码，将代码转化为自然语言，那么也许它可以解决这个问题。我昨晚听说IBM已经发布了一些东西，他们声称可以做到这一点，但我相信这只是个开始，这非常令人兴奋。生成式 AI 还可以做一些疯狂的怪事，比如用星球大战的隐喻来解释代码，所以你可以玩得很开心。
20年前，你可能是一名Java工程师，或者是一名C#工程师。但现在情况不同了，尤其是作为在我们这样行业的一名顾问，你需要学习Ruby、Python的各种概念，你要能在IDE内提供上下文。使用了 Copilot，它可以帮助你记起已经模糊的东西。在使用生成式 AI 之前，你必须去 Google 自己搜索答案。如果你有一个异常消息，作为一名初级开发人员，你会将它输入到Google中，再放入Stack Overflow中寻找答案，最后选择最受欢迎的那个答案。这样做的好处是，如果你选择了最受欢迎的答案，那么它可能只是一个好答案而已，但使用Copilot之类的工具，你可以获得具备上下文的答案，从而加快你的工作流程。
使软件交付变慢的原因之一是对瀑布方法的抱怨，即各阶段的交接问题。在不同的阶段之间，你只是在不断地传递东西，有人提出需求或者是一个想法，然后依次进入代码、测试、部署阶段，哦，出现了问题，那我们把它全部回退吧。但这个问题可能发生在两年后，早期的程序员已经离开了，因为他们只在组织里待了两年。所以现在如果你是一个初级程序员，你看着这个问题，可能要花上三倍甚至四倍的时间来弄清楚发生了什么，以及如何解决它。但如果你创建这些想法、用户需求、测试、部署的反馈循环越快，你就越能减少重复工作，并更快地实现你的目标。
所以你可以开始思考软件开发生命周期的所有这些不同部分，让生成式 AI 扮演其中某部分的不同角色，以及可以做的事情和工具。这听起来真是既令人惊叹，又令人恐惧，又令人兴奋。
我们一直专注于构建、编写好的软件和代码，即便有了生成式 AI，你仍然需要有好的方法和方法名称，但 AI 可以为你生成文档。想象一下，你离开两周后回来了，代码库发生了什么变化？你让 AI 给我一个总结，总结过去 190 次提交中代码库中的所有变化，它就可以帮助你来做一些研究和发现。
关于软件架构和设计的一个难点是考虑到所有的跨功能问题，如安全性问题、可访问性问题和性能问题。生成式 AI 可以告诉你，这里有大约 10 个问题，如果你是一位经验丰富的软件架构师，你就应该考虑并关注这些问题，你能辨别当前的情境下有 8 个问题与你无关，但剩下的2个问题很重要。但如果你不是一位经验丰富的软件架构师，如果你为解决这 10 个问题都修改了代码，那么最终你将得到很难更改和使用的软件。这就是为什么我会提到这一点，即人们的专业知识仍然如此关键。
实际上，作为技术领导者，我的担忧之一是，我们如何培养员工的专业知识？有 AI 之前，当我一开始读了某些人的代码，我会想，这到底是怎么回事？这个人写代码时吸食了什么疯狂的迷幻药吗？有了生成式 AI，这种情况就不太会发生了，它会告诉你它做了什么。它给你一些实现的选项，但如果你没有经验和专业知识来对这些选项做出判断，那么可能会生成更多糟糕的软件。这是我的预测之一，即在我们真正看到这项技术如何帮助创建更好的软件之前，我们将首先生成更多糟糕的软件。
在我早期评估所有 AI 这些不同技术及其对软件生命周期的影响时，我发现一切都回归到了现代软件的核心原则。任何真正在构建现代软件的人都知道，现代软件的关键在于流程。它的关键在于从系统中消除浪费，并使开发和交付团队进入流程状态，以便尽快将最高质量的产品交付给客户。
亚马逊的新 CEO Andy Jassy创建了一个工程效率开发者体验团队，因为他认识到在软件开发生命周期内存在很多浪费。生成式 AI 可以帮助减少某些浪费，比如查找一些信息。再次强调，AI 还可以帮助减少认知摩擦。它是否可以减少开发者体验摩擦？可能吧。它是否可以减少运营模型的摩擦？可能不行。所以生成式 AI 还有很长的路要走。
但生成式 AI 可以消除许多流程中的障碍，这就是为什么你必须观察整个软件开发生命周期，包括思考我们如何培养未来的工程师成为优秀的工程师。因为我们大多数人都是通过从困难的事情中学习来取得进步的，这是人类不幸的真理之一。我们的父母学到了一个艰难的教训，然后他们尝试教给我们。但是，我并不听你的，我要自己学习这个艰难的教训。这几乎是人类天性：从困难的事情中学到东西。那么在没有机会学习困难的事情的情况下，我们如何培养出优秀的工程师呢？
因此，这将是我们必须解决的问题。正如我所说，生成式 AI 可以帮助解决很多问题，但也有一些问题它不能解决，我们作为领导者仍然需要关注这些问题，仍然需要思考如何使用精益原则以消除浪费，以使人们在他们的角色中能够高效地发挥作用。
生成式 AI 会取代开发人员吗？
生成式 AI 会取代开发人员吗？我觉得不会很快，多年来与客户合作的经验告诉我，产品需求永远不会减少，它总是会变得越来越大。我们想要越来越多的东西，我们需要完成的事情越来越多，技术领域不断变化，我们总是试图进行变革，这就是原因。
因此如果我们能够让团队效率提高 20% 到 30%，或者未来可能是 50%，那会意味着我们会减少 20%、30% 甚至 50% 的人员吗？不，我们可能只会将 20%、30% 或者 50% 的软件添加到系统中。而且如果没有对其进行严格审查，如果没有工程师查看输出，那么这些软件可能会被编写得更加糟糕。因此，这可能会导致更多的遗留代码，制造混乱。
这就是我个人的预测，短期内，它可能会产生更多的挑战和复杂性，但我们必须应对这一挑战，找出让事情变得更好的办法。
我认为使用精益原则确实是正确的方法。当然，我也提醒了风险。但具体来说，在软件交付生命周期内，风险通常只是一种幻觉。所以你必须从两方面考虑它。最后，我想说的是，AI 可以让你更快地编写代码，因为它消除了很多重复性任务，这的确很棒。但你必须考虑整个生命周期，以及它影响的不仅仅是编码，而是真正高速生成的高质量的软件。这些工程实践更加重要。
但等等，我们未来还需要软件吗？
未来我们还需要软件吗？
这是我在思考的问题，因为作为一名领导者，我必须思考，如果在我们的系统中构建的软件，特别是我们拥有的内部业务软件，真的只是用于暴露和回答我们的问题，并添加新的信息，然后继续暴露并回答问题。我们还需要多少新的软件？我不知道。当然，这可能是明年或后年的一个话题。
但在短期内，我们可能会创建更多的软件。因此，我认为重要的是在不被落下的同时，采取深思熟虑的方法。我可以保证，你组织中的每位软件工程师都已经在使用生成式 AI。我还可以保证，侵犯知识产权的情况已经在发生。因此，了解整个软件生命周期，知道如何治理这些问题，在未来几年对于我们所有的技术领导者都将非常重要。
