作者 | InfoQ
译者 | 王强
策划 | Tina
不久前，InfoQ 编辑团队举办了一次年终回顾圆桌讨论，Thomas Betts、Wes Reisz、Shane Hastie、Srini Penchikala 和 Daniel Bryant 几位编辑在讨论中回顾了 2023 年的行业技术趋势，并对 2024 年作出了一番展望。本次圆桌探讨的主题包括：人工智能和大语言模型在软件交付领域的应用、技术领导角色的变化以及软件架构和数据工程的日益集成趋势。本文是完整讨论内容的编译精简版本。
讨论要点
- 人工智能和 ChatGPT 等大型语言模型（LLM）在各个领域（尤其是软件开发）中应用得愈加深入。我们相信产品设计、软件架构“可解释性”和系统运维（“AIOps”）方面还有改进空间。
- 软件交付方法和领导策略发生了显著变化，人们越来越关注道德、可持续性和包容性。许多云原生和平台工程计划首先关注人员和流程，确保组织文化与目标保持一致，这是正确的。
- 软件架构越来越注重将数据工程集成到数据管道、机器学习模型和相关系统的设计和实现中。从设计单体、微服务和纳米服务中吸取的经验教训也得到了广泛应用。
- 开源和非开源许可正在不断发展。架构师必须意识到其代码库中包含的依赖关系的含义，采用软件物料清单（SBOM）。
- 我们对 2024 年的预测包括，人工智能在软件交付中的使用将变得更加无缝，采用人工智能和不采用人工智能的组织和人员之间的鸿沟越来越大，持续交付领域向可组合性和改进抽象的方向前进。
云原生和平台工程的重点
是人员和流程吗
Wes Reisz：对于我在过去的几年里合作过的每一个客户，我们真正解决的问题似乎更多都是和人员相关的。这里推荐由 Matthew Skelton 和 Manuel Pais 撰写的《团队拓扑》，一本关于组织工程团队以实现快速流程、消除摩擦和消除交接，帮助你更快地交付软件的书。如今我们不仅仅是在谈论建立平台团队的需求，而是在谈论如何更有效地建立平台团队。这条赛道非常有意思，大家应该思考为什么要组建这样的平台，为什么要向这个方向前进？
主持人 Daniel Bryant：Justin Cormack 现在是 Docker 的首席技术官，他在 QCon SF PC 上提到，目前平台工程的重点主要集中在技术上，包括容器、云技术、基础设施、代码等等好东西。他说，在他的工作中他意识到，最困难的事情往往是愿景、人员战略、管理和领导力。
组织一直都存在的一个问题是需要强有力的领导才能实现清晰的愿景。对用户的同理心之类的事情听起来像是理所当然的。你正在为用户、开发人员构建一个平台，你需要对他们感同身受。但在我的咨询工作中，很多人构建了组织内部的大型平台，但没有考虑内部用户。他们做出来后都很高兴，但是没有人会使用它，因为他们从未真正问过开发人员：你们想要什么？你们想如何与之互动？
软件交付领导力领域有哪些新变化？
主持人：Shane，InfoQ 常驻文化和方法专家。你是否看到了领导层正在发生变化？是否有不同的策略、不同的愿景或更多的产品思维？有哪些比较大的问题？
Shane Hastie：在领导力领域，我们看到婴儿潮一代正在辞职并退出劳动力市场。我们看到了对目标、对道德的需求，对我们想要雇用的人们的真正有意义的价值观的需求。我认为组织领导层确实在发生变化，但可能速度没那么快。
我认为领导层正在发生根本性的转变，这无疑会凸显社会责任、可持续性、价值观和目标；领导层受到了开发者体验的影响，他们开始更重视人的感受。另一方面，我们进行了大规模裁员，有趣的是，我们听说这些裁员已经催生了更多表现良好的初创公司。
2023 年，麦肯锡的一篇报道说我们可以衡量程序员的生产力，该报道引发了巨大反响。程序员生产力是什么意思？我们如何衡量程序员的生产力？我们应该衡量程序员的生产力吗？我们是否真的从开发者领域的人工智能工具中获得了一些价值呢？当然我可以对自己说，是的，我已经开始使用它们，并且我发现了其中的价值。目前还没有很多严谨的数据，但看起来人工智能让优秀的程序员变得伟大，却不会让糟糕的程序员变好。
我认为让我害怕或担心的事情之一是我不仅在编程领域中看到了这一点，而是在所有的职业中都看到了这一点——优秀的架构师会因为人工智能变得伟大，因为他们拥有触手可及的工具。优秀的分析师会变得更好，因为他们拥有触手可及的工具。但我们如何让新人获得基础的能力，让他们成长为优秀的架构师、分析师、程序员并充分利用人工智能呢？这里有很多可以探索的东西。
基于 AI/LLM 的辅助工具
对软件开发有何影响？
主持人：Thomas，你的团队使用 Copilot 这样的东西吗？
Thomas Betts：我们采取了较为谨慎的态度。我们有一个 Copilot 试点项目，因为我们试图弄清楚它是不是符合我们的公司标准。有人担心数据，比如 Copilot 获取我的代码并将其发送出去来生成响应，那么我的代码去了哪里，是否泄漏了？
人们对这些大型语言模型普遍关心的问题之一是，它们是建立在什么之上的？它会用我们的数据吗？因此我们对此持谨慎态度。我们的试点结果相当有前景，我们正在研究它适合用在哪些场景中。谈到成本，如果考虑到生产力的提升也是可接受的。
我认为 Copilot 和类似的工具有一些非常好的用例，比如生成单元测试、帮助你理解代码、让初级开发人员参与其中。我们的代码库有 10,000 行，但新手不知道这些代码意味着什么，而且他们可能不愿意每天问每个人，这有什么作用？这是做什么的？现在他们可以让 Copilot 给他们解释每行代码的意义，甚至帮助他们更好地修改代码。
回到互联网出现之前的日子，那时候大家必须去图书馆在卡片目录中查找信息。现在我们有了谷歌，谷歌让我成为更好的研究人员，因为一切都触手可及。我不需要把所有的知识都记在脑子里。今天的 Copilot 一样，是你可以用来更好地完成工作的另一种工具。
主持人：Srini，你的团队是否在使用 Copilot 之类的东西，你个人认为它有价值吗？来年你打算用这种技术做什么呢？
Srini Penchikala：这些工具可以让程序员成为更好的程序员，但它们不会为你解决问题。你需要知道你需要解决什么问题。我认为这是另一种形式的复用。例如，假设我需要连接到 Kafka 代理，可能是使用 Java 或是 Python 语言。我可以使用可用的库或自己编写一些东西，或者现在我可以询问 ChatGPT 或 GitHub Copilot，“嘿，给我一些连接到 Python 的代码片段。”让它们告诉我如何使用 Python 或 Java 程序连接 Kafka。
如果我们能正确使用它并成为高效率的程序员，这就是另一种形式的复用。我认为这些工具将帮助我们在它们合适的领域提高生产力。
Wes Reisz：在我看来，这些工具确实正在帮助开发人员驱动我们的代码。它们正在增强我们正在做的事情。在此基础上，我们作为软件开发人员所做的工作的核心是思考问题并解决问题。Gen AI 并没有取代我们思考问题的方式。我们仍然需要了解问题并设法解决这些问题。它所做的，实际上只是帮助我们做一些在更高的抽象层次上的工作，它们是增强技术，这才是人工智能时代的真正意义所在。
Thomas Betts：Copilot 是为开发人员设计的，但我认为 ChatGPT 中的大型语言模型对于软件开发领域的其他人也很有用。我欣喜地看到项目经理和产品经理试图搞明白如何给它更好地编写需求。我们的用户体验设计师会问别人，我应该问哪些问题？有哪些可能的设计选项？我也喜欢让程序员问问题，每个人都可以从这位助手上受益。尤其考虑到我们是远程工作的，经常需要凌晨两点解决问题，所以没法随便问同事解决方案。而它是不睡觉的，我可以随时请求 ChatGPT 帮助我解决问题。它可以以不同的方式增强每个人的工作。
Shane Hastie：我确实在产品管理领域、用户体验和设计领域看到了很多这样的例子。现在还有一些专用工具，我经常使用的一个是 Perplexity。作为一名研究人员，对我来说它最棒的事情之一就是为你提供资料来源，告诉你在哪里可以找到资料，然后你可以对“这是否是一个可靠的来源”做出价值判断，这样就不会面临什么黑箱问题。
主持人：Ed Sim 是一位风险投资家，他说人工智能会减轻组织的运维负担。我也确实认为，下一步要通过人工智能减轻许多运维负担，我们需要更好地解释这些运维操作，并搞明白为什么系统建议采取这些操作。
Wes Reisz：我认为这不仅仅是一件好事，而且是一项法律要求。欧盟的 GDPR 专门讨论了机器学习模型。它的要求之一是可解释性。当我们使用大语言模型时，不仅要先考虑数据的来源和收集方式，还要考虑一系列的领域。“可解释性”是 GDPR 要求系统具备的一项法律要求。
云现代化工作进展如何？
现在大家都是云原生了吗？
主持人：换个话题，Wes，当你我上次参加 QCon SF 和 KubeCon Chicago 时，你提到你在云现代化领域做了很多工作。你在这个领域看到了什么，遇到了哪些挑战？
Wes Reisz：去年我所做的相当多的工作都是在企业云现代化工作领域。在各种峰会中我们认为云已经是一个既定的结论。但在过去的几年中我们发现，有相当多的组织仍在向云迁移。我首先要指出的是，当我们谈论云时，它并不是真正的目的地。云更多的是一种心态，更是一种思维方式。如果你看看 CNCF 生态系统，它确实与特定的软件集是否运行在某个云服务提供商上没有关系。
云讲的是我们构建软件的思维方式。Kubernetes 的创建者之一 Joe Beda 在定义云运维模型时，将其定义为自助服务、弹性、API 驱动，这些就是云的特征。当我们真正谈论云迁移和现代化时，我们首先应该关注它不是目的地，也不是位置，而是一种思维方式。这意味着我们要让事物变得更加短暂，让事物变得非常有弹性，充分利用全球资源。仅仅重新构建应用程序是不够的，有时你必须真正重新打开你的思路。
如果你要从数据中心运行的数据库转向全球范围的数据库，例如 AWS Aurora、Azure 的 Cosmos DB，甚至 CloudFlare、CloudFlare 的 D1 之类的东西，它会改变你对数据库的看法。我认为这需要更多地重新构想你的系统、重新思考如何进行灾难恢复以及如何看待蓝 / 绿之类的事情。当你开始谈论全球规模的数据库时，所有这些变化都会发生。我们还要考虑整合无服务器等等一大堆云特性相关的内容。
再次强调，仅仅将云视为一个位置的想法是一个陷阱。我刚刚提到了无服务器，它肯定起源于云服务提供商，但即便你没有云也能以云原生方式来操作。我们要理解云是一种思维方式，而不是目的地，这一点至关重要。
很多时候，当你迁移到更基于云原生的生态系统时，必须进行一些组织文化上的转变。我认为文化重置非常重要。如果你不重置组织的文化，那么你会把那些云原生时代之前，云原生后已经不复存在的实践带进云的世界。我认为这导致了很多反模式。今天，我在这个领域真正思考的两件事就是如何在云现代化时重新构想和重置。
主持人：我确实看到了这种转变，这种演变很大程度上来自于那些真正以创新技术为中心的人们。我们在某种程度上都处于这个领域，但现在有很多问题更多来自于后期采用者，他们只是想把事情做好，可能对最新技术不太感兴趣。我非常看好 EBPF 和 Wasm 这样的东西。如果你进入云领域，这些技术将会非常令人兴奋。大型企业做的事情是逐步实现现代化，而不是一蹴而就完成迁移，否则往往只会陷入灾难。人们现在也在关注诸如成本之类的问题，用更少的钱做更多的事情，这是一个重要因素。
单体应用 vs 微服务 vs 纳米服务
主持人：今年 InfoQ 非常流行的趋势之一是从整体到微服务，还有纳米服务 / 函数即服务。那么请问 Thomas，微服务和单体应用哪个最好？显然，这要具体情况具体分析对吧？
Thomas Betts：我记得在 QCon 2020 上，我的年度热门文章之一是我们向微服务迁移并回归的旅程。大家听说过这样的故事，很多组织正在采用微服务，因为觉得它可以解决我们所有的问题，或者我们正在构建一个新系统，将从微服务开始。但如果你不愿意承担这种级别的运维开销和负担并管理分布式系统，为什么要增加复杂性呢？软件本身就已经够难了，那么什么样的规模最合适呢？
我们不喜欢单体，因为它们是大泥球。但这并不意味着你的结构和组织很好的情况下单体也一定会是大泥球。如果你的代码结构良好，那么它就是可维护的，是可读的，并且软件是可持续的。随着时间的推移，修改软件也会变得更容易。
我是否需要一个分布式系统才能获得这种好处？我认为不是这样，人们现在正在寻找合适规模的服务。有一个故事中组织从函数即服务转向了单体应用，还节省了资金。将产品尽快推向市场总是比将产品放在货架上并继续开发两年要好。你没有赚到钱，所以你也无法存钱。
我什么时候可以说彻底改变我的架构的很大一部分是正确的决定？我们维护这个系统的实际成本是多少？我们两年前做出的这个架构决定仍然有意义吗？事情经常会随着时间的推移而改变。你一年前、两年前、三年前做出决定的标准，根据你当时掌握的信息，是正确的决定，但现在可能就不合时宜了。转变值得吗？那得看看你的情况。架构师的答案永远是具体情况具体分析。
Srini Penchikala：微服务、单体架构和无服务器架构都是模式，它们都有可以增加价值的领域，但也有自己的局限性，就像任何设计模式一样。如果你没有在正确的地方使用它们，你只会看到这种解决方案的缺点。
此外，架构既要考虑环境，又要考虑时间背景。五年前有效的解决方案现在可能不再是正确的，这就是架构的演变。再次强调，我认为所有这些都是针对正确问题的良好解决方案。你只需要弄清楚什么才是对你有用的即可。
Wes Reisz：过早的优化是万恶之源。过早的微服务是现代架构罪恶的根源。单体架构其实还不错，它们解决了一系列问题。一个简单的例子，考虑一个简单的堆栈跟踪。当你处于单体架构中遇到错误时就会有堆栈跟踪。你可以追踪它。你收到一个错误，抛出异常，你可以遍历堆栈跟踪，查看它来自哪里，帮助解决应用程序的问题。
现在，将同样的问题放入微服务环境中后，突然之间，你有了一个分布式堆栈跟踪，你必须设法将其整合在一起。如果你没有正确的可观察性来组装分布式堆栈跟踪，那么怎么才能用以前单体时期的堆栈跟踪经验来解决问题呢？你必须有一定程度的可观察性才能成功运维你的系统。如果你没有这样的能力，那么构建微服务就会是巨大的风险。微服务解决了一个问题，但你必须确保你正在解决的这个是正确的问题。
Thomas Betts：具体怎么选往往是折衷的。人们总是说我们要么选单体要么选微服务，但其实这里有一个范围。找到适合你的方法以及你在该范围内的位置，这就是权衡。每个决定都有优点和缺点，权衡利弊，做出正确的决定，并随着时间的推移再次评估方案。
主持人：看看目前的情况。我们应该转向微服务吗？我们应该转向单体架构吗？我认为这可能会成为架构师工具链中的一个令人着迷的领域。
我们是否看到与可持续发展相关的
想法和行动有所增加？
主持人：我相信许多在云领域工作的人们已经思考这个问题有一段时间了。我很想了解人们对可持续性的看法。Shane，你认为这在更宏观的层面有多重要？
Shane Hastie：只要这方面的行动不是做样子，那就真的很重要。我们的行业产生的碳与航空业一样多。我们可以做得更好，也应该做得更好。我们应该采取有节制的、节俭的方法。这对我们的组织有好处，对我们的客户来说会更好，对地球也应该更好。我们不仅仅是在架构上，而且应该从根本上采用节俭的方法。
我想到了我最近的一个播客，提到了 Jason Friesen 构建了用于应急响应的低影响技术，这种技术旨在应对所有基础设施都被迫退化的环境。地震后、火灾后，我们如何确保我们正在使用的基础设施能够真正救焚拯溺？现在，它们会降低碳排放吗？是的。运行成本会更低吗？大概如此。用户界面会同样直观吗？可能不会。
Thomas Betts：有很多资源是一直都在运行的，因为启动它们非常容易，而且我们不会关闭它们。出租车不会整天在酒店外面空转，因为它就停在那里即可。我们的软件也是如此，我们应该能够关闭一些东西。
获取有关碳使用量的实际数据很困难，公司需要考察自己的云供应商，研究你的软件的碳足迹。这些软件是运行在一切都依赖煤炭的弗吉尼亚州，还是运行在拥有更多绿色能源的地方？我们去年就谈到了这一点，我们希望看到的这种讨论成为趋势，目前它并不是讨论的焦点。现在有了一些平台的帮助，获取这样的报告变得越来越容易。
我认为我们将看到一些关于软件绿色程度的小绿色指标开始流行。我觉得人工智能会以某种方式提供帮助，因为这是一个复杂的问题，有时如果你可以把计算需求扔给它，它可以找出我们很难找到的答案。我们将看看未来一两年这些事情会发生什么变化。
Srini Penchikala：沿着同样的思路，也许我们可以将这种消耗作为一种债务类型的事物来跟踪，就像我们对待技术债务一样。我们跟踪应用程序或软件组件，看看每个组件在绿色计算方面的影响有多大，这样做会很好。
软件架构 数据工程
主持人：Thomas，你提到架构越来越多地涉及数据管道、ML 模型以及依赖于它们的系统。我正在阅读的一些资料说人工智能的用例正从诸如编写文本之类的狭隘任务演变为企业工作流程和自动化。我很想更深入地了解这一点，听听你的看法。
Thomas Betts：我想我们去年就讨论过这个问题。我认为现在我们设计的不仅仅是数据管道，还有机器学习模型和整个工作流程，可能边上已经自带了数据分析。这就像是我们的操作系统，一切都会同数据仓库打交道，我们会分析数据并做出各种决策，诸如此类。
甚至一些机器学习能力也成了这个体系中的一等公民，它们是我们产品的一部分，是我们必须拥有的系统的一部分，而不是一个漂亮的小附加组件。这意味着架构师关心的所有功能，例如可持续性、冗余和容错之类，现在就需要在我的数据管道上使用它们。这不是什么可选项，不是那种今晚可以不用，明天再用的东西。
不，我们从批处理切换到流处理，所有这些东西都需要启动并运行起来，否则我们的系统作为一个整体就跑不下去了。现在机器学习和人工智能已经和架构设计紧密结合，不可分割，我们没法再把它们切割开来独立看待了。
主持人：这就是云、数据工程和人工智能的渗透结果，渐渐地，一切都融合在一起了。
InfoQ AI 和 ML 趋势报告摘要
主持人：Srini，我很想深入了解你对人工智能和机器学习趋势报告的看法。有没有一些关键的点让你非常在意的？
Srini Penchikala：数据无疑是一切的基础，包括人工智能和各种新趋势的基础都是数据。总而言之，2023 年当然是 ChatGPT 之年，也是生成式 AI 之年。人们使用 ChatGPT 的用例五花八门，但对我来说，我认为大多数用例仍然属于我所说的“hello，world”用例。
当你在一家真正的公司工作时，你无法将所有数据放入云端并让 ChatGPT 或开放式 AI 对其进行训练。你仍然需要做一些制衡。一些增强的检索方案能帮助你使用自己的私人信息增强训练模型，为你的公司获得更多特定领域的预测。
2024 年，人工智能和生成式人工智能相关的话题肯定会得到更多关注。负责任的人工智能也会是一个重大主题：我们如何才能使这一代人工智能解决方案更加道德、更少偏见、更少幻觉？此外，安全性也将成为一个大话题：我们如何在保障安全性和隐私性的情况下使用这些应用程序？
还有一个大题目是 LLM ops，它将是在企业环境中运维这些大型语言模型所需的另一个重要主题。我们如何将这些模型投入生产？我们如何扩大它们的规模以及如何像我们所说的那样以节能的方式使用它们？我们怎样才能让大语言模型更加绿色？所有这些都将受到更多关注。
在数据方面，数据流仍然是数据方面的一个重要组成部分，仍然是现代数据架构堆栈的核心部分。这个领域将继续增长，并为公司提供更多实时解决方案。大语言模型和生成式人工智能的创新实际上正在带来一些新的创新趋势和创新产品，例如矢量数据库。为了使大语言模型发挥作用，你需要以称为向量嵌入的特定格式呈现数据。
有一些新的专用数据库专门用来管理这些数据，它们在这个领域受到了很多关注。看看它们如何进化将会是很有趣的事情。另外一个就是云。云始终是任何 IT 解决方案的基础。我认为多云的使用是一种持续的趋势。如果你有多种不同类型的用例，那么在某种程度上它会继续变得更流行。你实际上可以使用不同的云供应商，云供应商 X 用于分析用例，云供应商 Y 用于其他用例，你不必在所有事情上都依赖于一个提供商，并且你可以利用每个云供应商的最佳解决方案。多云使用是我们看到的另一个趋势。基本上，无论是在什么架构里，数据都将发挥重要作用。
负责任和道德的人工智能：
每个人的责任？
主持人：Srini，我很想深入了解你对人工智能和机器学习趋势报告的看法。有没有一些关键的点让你非常在意的？
Shane Hastie：我认为这个话题的确得到了关注。具体来说，仅仅因为我们可以做某件事，并不意味着我们应该这样做。当我们这样做时，我们如何确保我们做的事情是“正确”的？这些都是我们要讨论的东西。我觉得我们作为一个行业正在慢慢朝着更加道德的方向发展，但这也与领导力有关。我们正在驱动一艘油轮，而不是一支快艇编队。
Thomas Betts：我觉得这是跨越整代人的主题，所以变化会比较缓慢。有时你只需要等待下一代成长起来，他们就是带着这些期望长大的。
我倾向于在有道德要求的行业工作。我们需要接受道德培训，就像不要贪污受贿就是一种培训。但怎样编写没有偏见的软件？这并不是现在大家都会接受的训练。我希望我们正在朝着这一目标前进，但现在有太多数据证明我错了。
Srini Penchikala：这应该是未来的“能力”之一，因为我们确实需要编写负责任的解决方案。
Wes Reisz：我认为底线是我们必须保持勤奋。我们能够利用当今可用的惊人资源做越来越多的事情。我们如何确保自己尊重隐私、遵守保密要求？我们如何确保我们的成果不会造成伤害？我们如何确保我们正在构建正确的系统，确保安全、正确地做事？我认为这些都是处理软件道德的重要课题。我们还没有将这些东西作为我们日常工作的一部分，但我们确实必须继续保持勤奋并确保我们做正确的事情。
开源许可的未来
主持人：在过去的几年里，我们看到 OSS 许可领域发生了一些变化。我认为这是一个道德问题，我很想听听你们对 OSS 许可变更的看法，这是否是开源的终结？或者这是新的黎明吗？
Thomas Betts：悲观的答案似乎总能吸引更多流量，“OSS 已死”也许是一个很好的标题，但它并没有死。软件物料清单是一个正在开始流行的概念，我认为这是出于大家对脆弱性的担忧。零日黑客攻击了你使用的某些存储库、你使用的某些软件包，然后因为大家都在用它们，每个人都会自动获取最新版本，这个小小的变化就会蔓延开来。多年来有过很多案例，其中人们都以为自己有了一套良好且稳定的依赖体系，但其实你并不知道你究竟依赖的是什么东西。
当我们处于闭源环境中时，所有代码都是公司自己人写的。是的，你拥有这一切。但这并不是我们现在生活的世界的样子。如果你问我正在运行的某个软件中的每一行代码都是什么来历，我无法回答你，而且我认为没有人可以告诉你。如果你拉入五个 npm 包或七个 NuGet 包，它们会产生一系列依赖项。这个问题也和可持续发展有关。编写开源软件的人们如何谋生？这只是一个副业项目吗？如果你的软件获得成功，你什么时候会想把它变成一项业务并辞掉自己的日常工作，你通过什么手段来赚钱支持你的开发工作？
一些大公司会花钱支持开源，或者会给你添加人手来维护你的开源项目。业内有几种融资模式，但如果我们能看到更多软件公司以更简单直接的方式支持那些开源作者就更好了，毕竟他们的开源项目可能是这些公司几乎所有软件依赖的东西。你可以免费获得这些开源成果，但你是一家价值数亿美元计的公司，为什么要使用免费的东西？如何才能让行业更轻松地支持这些活动？我不知道我们是否已经有了良好的融资模式。这不是应用商店那么简单，只要单击一个 99 美分的购买按钮就能买一个依赖包，不是这样的。
Srini Penchikala：我同意。开源并没有消亡，另外免费和开源对我来说并不是同义词。开源不仅仅是免费。它只是不需要任何成本。另外开源无处不在，甚至 LLM 领域也开始使用它。看看它将在这个领域如何演变是非常有趣的。当然，我自己也是开源的忠实粉丝。我使用了很多框架。我过去曾为其中的几个做出过贡献，所以我绝对对此非常尊重。
Wes Reisz：我认为我们中没有人会说开源已死，但我确实认为，有的公司会用其他公司的开源成果造出新的东西，然后拒绝开源，不向上游做出贡献，甚至开始与原来的开源软件竞争。然后，构建原始开源软件的人们开始质疑他们的工作是否有意义。这些都是必须解决的挑战，我认为这又回到了我们之前讨论过的软件道德问题。什么是道德的、什么是正确的以及我们如何处理这些类型的问题？
我们对 2024 年的软件交付领域有哪些预测？
主持人：Thomas，请问你对 2024 年的预测有哪些？会出现哪些大技术、大方法、领导层的大变革？
Thomas Betts：去年我还会想，机器人会取代我的工作吗？现在我还没失业，不过我确实认为，我们正在走出这些技术最初的炒作周期，这真是太神奇了。是的，ChatGPT 在一天之内就有 100 万用户采用，这是一个炒作周期，而它必须冷静下来。新模型正在变得越来越好，它们正在不断发展。人们正在学习做他们真正擅长的事情。我认为我们将开始看到这些技术渗入到我们已经讨论过的所有层面。它们将会让每个人的工作都变得更好做一些，我们将开始看到各种各样的专门工具，针对产品经理的，针对开发人员的，针对用户体验的，针对企业搜索的，这就是一个趋势。
人们现在会谈论 ChatGPT 和大型语言模型，但我们并不会去讨论搜索引擎是怎么运行的，我们已经习惯了把它们当作日常工具。在某些时候我们会发现，人工智能也像搜索引擎一样走入幕后，司空见惯。我认为，当我们停止谈论人工智能时，人工智能就真正达到了它一开始要达到的目标。我希望我们不要在每次交流中都提到人工智能，因为这意味着我们还没搞定它。我预测，明年我们不会迎来通用人工智能，我们还没有达到奇点。相比之下，我们将获得一些对每个人来说并不是那么革命性的工具，但它们会变得越来越好用。实际产品的炒作也是一件好事，这说明大家开始真正用它们了。
Shane Hastie：人工智能领域的很多专用工具将更加关注产品管理、UX 设计等特定方面，这是非常重要的。这些工具会让那些老手获得更高的效率。我还是担心新人会被丢下，我希望我们能够找到方法让大众普遍提升到可以真正利用这些工具的水平上。对我来说这是更大的风险之一，因为我们可能会创建一个差不多分成两层的系统，一层是经验丰富、非常优秀的专家，另一层则是被拒之门外的普通人。
此外，我看到组织文化正在稳步改善。我们在道德方面做得越来越好。我们在可持续发展方面做得越来越好。我们不仅会更多考虑开发人员体验，还会考虑员工体验。我们与业内人士合作和相处的方式稳步、缓慢地改善。
Wes Reisz：我记得有人创建了一种名为 CUE 的编程语言。虽然它不是通用编程语言，但它是一种真正专注于数据验证、数据模板和配置等的编程语言。
我在 Kubernetes 领域听到很多信息，尽管 CUE 和 Kubernetes 没有直接的支持，但由于它植根于 Go，因此用的人还是很多的。Weaveworks 的 Stefan Prodan 最近创建了一个名为 Timoni 的项目，被称为 Kubernetes 的包管理器。它由 CUE 提供支持，灵感来自 Helm。它的想法是让你不再像 Helm 那样将 Go 模板与 YAML 混合在一起。新的一年中，我真的对 CUE 和相关产品很感兴趣。
Srini Penchikala：明年，如果我们还在到处谈论人工智能，那就意味着我们还没有实现它的目标。我认为人工智能将成为幕后透明的软件开发结构，它会让一切都变得更好。我认为它将开始变得更加隐形，带来更多隐性价值，这就是它应该有的样子。
另外，唯一能够经久不衰的架构是弹性架构。一定要确保你的架构在可扩展性方面具有弹性，或易于切换到不同的设计模式。
主持人：我们都对人工智能感到兴奋，这是有充分理由的。我们的行业就像一艘油轮，这艘巨轮转向需要一段时间，但只要我们都从好的角度思考这些事情，考虑道德和可持续性，考虑到我们的现实情况，那么最后我们肯定会走向正确的未来。
原文链接：
https://www.infoq.com/podcasts/2023-year-review/
声明：本文为 InfoQ 翻译，未经许可禁止转载。
