人工智能辅助编码、开源等的前景

人工智能辅助编码、开源等的前景 我们努力为读者提供最新趋势。但在回顾了去年的数据研究和许多 2025 年预测后，我们仍然有一些未解问题。

为了更好地了解未来，The New Stack 的编辑们确定了 14 个需要回答的问题。然后，我们找到了 120 多位行业专家来帮助我们了解开源的未来、开发人员对 AI 的使用以及 IT 基础设施。

超过 30 位专家平均对他们最了解的话题给出了 4 个深入预测。其中一些答案已在 The New Stack 中报道过。在这篇文章中，我们首先重点介绍最重要的结论。然后，重点介绍阐述这些结论的具体问题和答案。

开源与竞争力 安全性和维护者的时间是开源的最大威胁。 未维护的组件有望取得逐步进展。 开源可以成为对抗开发者平台集中控制力量的最有效方法。 大型平台公司是否会赢得人工智能堆栈之战，目前尚无共识。 人工智能代理 尽管长期持乐观态度，但人们仍然担心许多内部人工智能代理项目将在 2025 年被放弃。 人工智能对开发者流程的影响 当开发人员审查生成的代码的质量并将工具集成到他们的工作流程中时，人工智能辅助开发将给他们带来挑战。 2025 年开发人员手动测试软件所花的时间与 2024 年大致相同。 云和数据基础设施 专家认为，工作负载向私有云和本地云的迁移速度不会超过向公共云的迁移速度。 当组织从批处理转向流处理时，对于需要克服哪些障碍尚无共识。 开源与竞争力 考虑一下普通的企业应用程序组件，到 2025 年，未维护或过时的开源组件的比例将增加或减少多少？ 未维护组件的进展有望逐步改善。回答此问题的六位专家中有​​五位认为，到 2025 年，开源且未维护的组件的比例将下降，其中两位认为下降幅度将达到 10% 左右。人工智能和 DevOps 工具的持续采用被认为是改善的原因。其中一些专家是这样说的：

“这种下降趋势将由软件供应链安全意识的增强所推动，这种意识的增强是由Log4Shell等事件引发的，以及Snyk等工具的广泛采用，这些工​​具可自动更新依赖项。软件物料清单 (SBOM)的监管要求和npm等平台中生态系统治理的改善也在识别和解决不受支持的组件方面发挥着至关重要的作用……总体而言，积极主动地维护依赖项卫生可能会在减少企业系统中的过时组件方面产生实质性的收益。”—— Lightrun产品营销主管Eran Kinsbruner “希望通过更多地采用依赖管理和更新自动化，以及改进持续集成和部署等 DevOps 实践，可以帮助企业应用程序在 2025 年平均减少 5-10% 的过时组件。不过，这一减少将取决于技术债务和资源限制的数量，以及企业各自的优先事项。”—— PagerDuty开发者关系和社区高级经理Kat Gaines 您认为 2025 年对抗开发者平台集中控制的最成功举措是什么？ 开源可能是对抗开发者平台集中控制力量的最有效方法。回答这个问题的八位专家中有​​三位认为，推广开源替代方案是对抗开发者平台集中化的最佳方式。其他人则看到了开源、人工智能辅助编码工具正在与大型平台公司有效竞争的迹象。

“开源方法应该会自动减少对开发者平台的集中控制，因为可以自行分叉项目或构建所需的内容。但实际上，很多人不愿意分叉，因为与保持社区团结相比，这是一个耗时且可能浪费的过程。如果没有必要，社区不会愿意分叉。” — Kate Obiidykhata ， Percona云原生产品和服务解决方案营销经理 “我认为，随着 Cursor AI（将用户从 GitHub Copilot 中移出）、Surfer/Codium IDE、用于全栈应用程序的 Bolt.new 的兴起，甚至桌面 ChatGPT 应用程序中的新功能（允许基于共享 Xcode 等应用程序编写 Swift 代码），我们已经看到了开发者平台控制权的分散化。”—— Madhukar Kumar ， SingleStore首席营销官 开发人员会在 2025 年迁移到大型平台公司构建的 AI 堆栈吗？ 关于大型平台公司是否会赢得 AI 堆栈之战，目前尚无定论。一些专家认为，未来专业公司可以与大型平台公司竞争。从长远来看，对广泛数据源的需求可能会让大型平台公司占据优势。

“数据是人工智能的命脉。为了构建有意义的人工智能应用，开发人员必须能够直接访问为其提供支持的相关企业数据。当开发人员迁移到平台公司时，他们的人工智能堆栈和数据共存于同一位置，他们可以充分发挥数据潜力，避免在平台之间移动数据带来的不必要的治理风险，并加快其应用的价值实现时间。” — Jeff Hollen，Snowpark 产品总监、Snowflake生态系统和开发者平台 “我发现开发人员倾向于使用能够帮助他们更快地构建应用程序和解决方案且使用起来直观的工具。组织希望 AI 堆栈能够将生产力和效率与一流的安全性和数据隐私相结合。能够赢得开发人员信任的工具将是那些建议高质量代码和适合其代码开发流程的编辑器的工具……开发人员目前正在评估这些 AI 技术将如何为他们带来价值。很少有大型平台公司通过早期推出就获得了市场收益和影响力。我看到小公司通过为开发人员带来目标价值而获得了吸引力。”—— Okta客户身份首席技术官Bhawna Singh “我认为 AI 可以实现许多不同的细分用例，我们将看到开发人员既使用大型平台提供的功能，又使用解决特定问题的工具。例如，开发团队可以使用GitHub Copilot来帮助完成日常编码任务，但使用不同的 AI 堆栈来审查代码、生成测试或管理 [基础设施即代码]。我目前正在构建这样一个工具 Blackbird，它使用 AI 来生成和编辑 OpenAPI 规范。大型平台将涵盖大多数常见用例，有些可能会延伸到细分领域。但作为一名开发人员，我认为我们将开始拼凑一些替代的 AI 堆栈，这些堆栈将更有效地以极低的价格解决细分问题。”—— Matt Voget ， Ambassador Labs技术总监 人工智能代理 到 2025 年底，2024 年内部构建 AI 代理的所有努力中至少有一半会被放弃吗？ 我们的调查参与者表示，尽管长期持乐观态度，但人们非常担心许多内部人工智能代理项目将在 2025 年被放弃。在回答这个问题的 14 位专家中，有 5 位专家预计 2024 年至少有一半的努力将被放弃，有 2 位专家不同意这一前提。回答这个问题的其余 7 位专家承认不确定结果会如何。 “虽然许多组织一直专注于内部构建 AI 代理，但我们预计到 2025 年底将发生重大转变。预计在 2025 年至 2026 年期间，市场上将出现大量商用 AI 代理进入主流。在Kobiton，我们认识到在 AI 代理发展的早期阶段，内部开发 AI 代理仍然可行。然而，随着更复杂、更精致的 AI 解决方案在商业上可用，维持内部开发工作的成本和复杂性可能会超过收益。因此，我们预计，2024 年内部构建 AI 代理的大部分计划将被逐步淘汰，转而采用这些先进的、随时可部署的解决方案。这种转变反映了行业更广泛的趋势，即利用专门的、市场驱动的 AI 工具，与定制的内部开发相比，这些工具具有出色的性能和可扩展性。”—— Kobiton 首席技术官Frank Moyer “人工智能的本质往往使早期的努力在相对较短的时间内变得过时，导致许多努力被放弃。我们在大型数据模型项目中看到了这种情况，重新调整资源以推进可能会花费高昂。”—— Josep Prat ， Aiven流媒体服务工程总监 “规模较小的努力将会失败，因为公司将意识到两件事：他们的数据比他们想象的要脏得多，需要付出巨大的努力才能清理干净；当 GPT-5 和 Claude 4 问世时（2025 年），它们的开箱即用性能将使任何规模小于标准普尔 500 指数公司的内部项目变得多余。”—— Cosine首席运营官杨力 “新兴技术需要时间才能成熟，而人工智能代理的使用也将经历类似的成熟曲线。成功的组织是那些采取慎重措施、逐步整合人工智能代理并在学习过程中进行调整的组织。那些期望快速见效的企业可能会厌倦并放弃努力。”—— Krishna Subramanian ， Komprise联合创始人兼首席运营官 “目前还很难说。构建 AI 代理的成功将取决于组织调整其 API 策略以支持机器对机器交互的能力。未能解决安全漏洞、可扩展性和 [投资回报] 等挑战的公司可能会放弃这些努力。然而，那些投资于设计模块化、可重复使用、可外部化的 API 并实施强大的合规框架的公司将更有能力实现可持续的 AI 集成并避免项目放弃。” — Postman首席执行官Abhinav Asthana 人工智能对开发者流程的影响 2025 年，依赖 AI 辅助软件开发的开发人员面临的最大挑战是什么？这些挑战将如何影响 GitHub Copilot 用户？ 人工智能辅助开发将给开发人员带来挑战，因为他们需要审查生成的代码的质量并将工具集成到他们的工作流程中。回答这个问题的 17 位专家中，许多人表示担心，人工智能生成的代码的增加实际上会增加开发人员的工作量，因为它需要人工审查。几位专家担心，缺乏经验的开发人员无法识别人工智能何时吐出坏代码。安全和信任是其他挑战。

“对于依赖它的开发人员来说，要问的问题是，如果它被拿走，他们会非常失望、有点失望还是不失望？今年早些时候对我们的工程师进行的一项非正式调查显示，28 名受访者（我们在 AI 技术领域的积极实验者）中只有 2 人会因为这个原因而感到非常失望。我从中得到的结论是，这些工具在某种程度上是有用的，但还没有证明它们是无价的，以至于工程师们如果因为预算原因而削减它们，会非常直言不讳。”—— Colin Bowern ， Octopus Deploy高级副总裁 “由于无法识别 AI 代码中的缺陷，代码质量下降可能成为一个问题。目前，经验丰富的开发人员可以从 AI 辅助软件开发中获得巨大收益，因为他们有经验识别 AI 代码何时不正确。随着 AI 辅助编码的继续发展，查找 AI 错误的技能将以超过 AI 在生成无错误代码方面的改进速度下降。” — Scott Wheeler ， Asperitas云实践负责人 “虽然 GitHub Copilot 等 AI 编码助手被宣传为通用生产力工具，但它们过度放大了经验丰富的开发人员的能力，同时可能阻碍新手的学习过程。高级开发人员对系统设计、架构模式和技术权衡有着深刻的理解，可以有效地“说 AI 助手的语言”。他们确切地知道要问什么，可以快速验证生成的代码，并了解实施建议的解决方案的更广泛影响……经验不足的初级人员只能依赖 AI 建议。虽然这可能会增强他们对语言无关性思考的需求，但考虑到消除学习过程中失败的担忧，这现在看起来有点不切实际。”—— Freshcode联合创始人兼董事会成员Artem Barmin 由于自动化程度的提高和人工智能技术的采用，开发人员手动测试软件所花费的时间是否会大幅减少？ 2025 年，开发人员手动测试软件所花的时间与 2024 年大致相同。在回答这个问题的 15 位专家中，有 7 位回答“否”，3 位回答“是”，其余专家的回答则更为细致入微。

“如果某些开发人员指出他们的生产力提高了 10 倍，而由于解决问题的问答和测试速度较慢，总体结果只是微不足道的边际收益，那么这是没有意义的。” — Amanda Brock，OpenUK首席执行官 “我认为这个数字还会增加。开发人员将花费更多时间运行自定义测试和工作流程来验证他们没有编写且无法轻松解释的代码。”—— Cosine 的 Yang Li “自动化通常在应用于变化最小的稳定产品时会产生最高回报。然而，在 Kobiton，我们观察到了一个意想不到的趋势：手动测试时间环比增长了 22%，超过了自动化测试 17% 的增长。这种转变主要是由人工智能辅助工具推动的新应用程序开发速度加快所推动的。随着这些应用程序的快速发展，变化的频率和程度使得全面自动化变得不那么可行。因此，对灵活的手动测试的需求不断增加，以确保新功能和更新保持质量标准。这种动态强调了需要采取一种平衡的方法，即自动化和手动测试相互补充，以适应人工智能技术推动的快节奏开发环境。”—— Frank Moyer，Kobiton “是的，团队将能够自动创建单元测试和基于意图的功能测试。这不会消除 UAT 等手动测试，但将有助于将这些手动测试转换为回归测试的自动化。”—— Copado推广高级副总裁David Brooks “AI 正被用于简化一些任务，例如生成测试用例，从而带来快速而微小的收益。虽然这些初步改进可以提高效率并减少人工工作量，但 AI 对测试基础设施的更具变革性的影响将需要更长时间才能实现。需要付出巨大努力来构建和采用可以替代或大幅改变现有测试框架的 AI 驱动解决方案。虽然 2025 年专用于测试的时间可能不会大幅减少，但随着这些技术的成熟和与标准实践的融合，预计 2026 年将出现更明显的减少。” — Supriya Lal，Yelp集团技术主管 “是也不是。开发人员将能够使用 AI 工具完成更大的编码任务，这意味着他们将花费更少的时间重新运行本地开发循环（其中包括手动测试）。他们还将能够快速编写自动化和单元测试，目的是防止回归并尽早发现错误。但我不认为这一定会减少开发人员花在手动测试上的时间。如果说有什么不同的话，那就是 AI 工具可以让开发人员花更多的时间确保他们的代码确实解决了业务问题，因为许多样板​​工作都是自动化的。这可能意味着花在编码上的时间更少，花在手动测试上的时间更多。”——Matt Voget，大使实验室 云和数据基础设施 一般企业迁移到私有云和本地云的工作负载数量是否会比迁移到公共云环境的工作负载数量多？ 专家们并不认为工作负载向私有云和本地云的迁移速度会超过向公有云的迁移速度。在回答这个问题的 15 位专家中，有 6 位回答“否”，3 位回答“是”，而其余专家则描述了一幅混合图景，不同类型的公司和工作负载更有可能倾向于一种环境而不是另一种环境。

“是的，主要有两个原因。首先是优化 IT 支出的压力越来越大。将工作负载迁移到云中的企业发现，公共云并不总是像本地或私有云那样具有成本效益。此外，一些首席财务官忽视了资本支出模型的稳定性和可预测性。 第二个因素是供应商格局和产品组合的变化，例如Broadcom 收购VMware之后的变化。这些转变促使一些公司重新评估其平台战略。在某些情况下，这可能会导致将适当的工作负载迁移到公共云，但在其他情况下，我们看到组织选择替代模型，例如私有数据中心中的托管基础​​架构，这些模型既能控制本地模型，又具有公共云的灵活性和易维护性。” — Justin Giardina ， 11:11 Systems首席技术官 “企业可能会将更多工作负载迁移到私有云和本地云，而不是公共云环境。这一趋势由多种因素推动，最明显的是人工智能基础设施建设的需求，这需要完全控制数据资产，并最大限度地提高网络基础设施的性能，避免使用共享或虚拟网络。”—— Ugur Tigli ， MinIO首席技术官 “到 2025 年，企业将越来越多地优先考虑私有云和本地云环境，作为平衡灵活性和控制力的混合解决方案的一部分。监管合规性和成本优化将推动这一转变，因为企业寻求更好地管理数据主权并满足关键任务工作负载的需求，同时仍利用公共云服务的灵活性。这种转变反映出人们越来越倾向于提供灵活性和控制力的解决方案，尤其是当数据和人工智能成为业务创新的基础时。”—— EDB产品管理副总裁Aislinn Wright “2025 年，‘普通’企业（包括中型企业和长尾企业）将继续加大向公有云迁移的力度。对于大型全球 2000 强企业而言，前景则更加喜忧参半。大部分迁移将转向公有云，但由于多种因素的共同作用，混合云/私有云也将大幅增长： [Kubernetes] 平台日趋成熟，尤其是Red Hat OpenShift，该平台正获得大规模采用。现在，超大规模原生平台有了可行的替代方案。 他们已经完成了许多“唾手可得的”工作负载，例如诞生于云端的客户参与系统，这些系统已经转移到公共云。 在下一阶段，大型企业开始将注意力转向任务关键型后端系统，其中许多（如果不是大多数）系统可能会对流入公共云的内容有所限制。SAP ECC 即将落幕就是一个典型例子，这促使许多企业重新审视其 ERP 系统。其中许多系统最终将进入私有云。如上所述，虽然大多数行动仍将集中在公共云迁移中，但全球 200 强企业工作负载中越来越多的部分将转移到私有云或混合云。” — Tony Baer ， dbInsight LLC负责人 “不。事实恰恰相反：首席信息官和首席技术官已经厌倦了本地解决方案。博通收购VMware 后，许多组织都希望加快从本地迁移到云的步伐。边缘和云之间的计算连续性使组织能够从其云/边缘服务中榨干每一点性能——这对于组织来说几乎是不可能独自完成的。现在，Kubernetes 被视为通用控制平面，对供应商锁定的担忧正在减弱。一些大声（但规模较小）的组织大胆宣称他们的“遣返”，但这些公司远不能代表主流组织的担忧。仅仅因为拥有几十名员工的公司37Signals可以节省资金，并不意味着普通企业会从迁移回本地中获得任何好处。”—— Ferymon Technologies联合创始人兼首席执行官Matt Butcher “这取决于企业的优先事项——具体来说，就是速度和成本之间的权衡。优先考虑速度的部门或组织将继续将更多工作负载迁移到公共云环境。然而，对于稳定、资源密集型的业务流程，企业可能会越来越多地考虑将这些工作负载迁移到私有云或本地云以优化成本。无论目的地如何，企业都必须专注于开发无缝跨环境移动和管理工作负载的能力。”—— Acceldata首席执行官兼联合创始人Rohit Choudhary 数据架构 2025 年将克服从批处理到流处理的障碍是什么？ 当组织从批处理转向流处理时，对于哪些障碍将被克服，目前尚无共识。七位专家回答了这个问题，但他们花在解释挑战上的时间比如何克服这些挑战的时间要多。话虽如此，5G 网络切片的改进、实时 API 和协议的标准化、矢量数据库的成本/复杂性的降低以及 AI 用例带来的需求增加都是专家们预计流处理技术采用将增长的原因。

“5G 网络切片的改进将为关键流媒体应用提供专用带宽，使企业用例的流处理更加可靠和可预测。”—— Artem Barmin，Freshcode “对于不支持高效流插入的矢量数据库来说，成本增加和基础设施复杂性问题很常见。有些矢量数据库根本不支持它。为了应对这些挑战，开发人员必须构建和实施额外的系统来处理实时数据，这通常会导致维护多个系统的架构复杂性……随着越来越多的企业开始克服这些挑战，我们预计 Milvus 的采用率将会增加，因为它旨在处理历史数据，同时也为新数据提供一条新路径，以便高效地插入和搜索新数据。”—— James Luan，Zilliz工程副总裁 “我们最终将能够同时查看静态数据湖和仓库数据以及实时流数据，从而使批处理和面向内部的应用程序变得实时且面向外部。一个典型的例子是能够在 Snowflake 中以容器的形式运行像 SingleStore 这样的实时多模式数据库。” — Madhukar Kumar，SingleStore “我们遇到的一个重大障碍是实时处理来自不同来源的数据，因为数据格式、模型、API 和延迟各不相同。但是，今天我们有更好的工具来对动态数据进行建模，这些工具在 2025 年只会有所改进。我们看到Apache Flink和使用它们的数据平台都得到了增强。一些改进围绕着实时 API 和协议的更好标准化，总的来说，我们看到数据网格和事件驱动架构被广泛采用，它们可以更好地支持分散式流处理。但这个问题仍然需要努力，而且永远都需要努力。”—— Josep Prat，Aiven “由于数据是零散的，因此数据聚合对于流处理来说更具挑战性。Apache Flink 和Apache Spark Streaming 等新兴框架正在改进有状态的流处理功能，从而能够在实时环境中更有效地处理聚合和连接。” — Scott Wheeler，Asperitas enter link description here