Transcription
人工智能工具加速了编码，但软件交付 [音乐] 并没有变得更快。GitLab 首席执行官 Bill Staples。瓶颈是什么？>> 人工智能和编码代理，如 Cloud Code 和 Codeex，正在加速开发人员工作的编码方面，但这会导致整体软件交付的下游瓶颈。你知道，像代码审查、错误修复和安全检查等事情都因代码而不堪重负。团队和领导者并没有看到创新速度的整体提升。我们称之为人工智能悖论。如果你愿意，工具的碎片化会导致开发人员生产力受到影响，因为这些工具不是由同一家公司在同一个平台构建的，共享相同的数据。它们显然是断开连接的，由个别开发人员或开发人员体验团队手工组装而成。这种碎片化导致他们在软件生命周期中移动软件时，不得不整天切换上下文。这导致他们必须将关于该软件的上下文记在脑子里。深入探讨典型的开发人员工具如何为软件开发生命周期制造这些障碍，从而影响开发人员的生产力。它们将自己的上下文存储在自己的数据系统中，你可以使用 MCP 打开该上下文，但你在身份和相应的安全潜在安全问题方面受到限制，然后你还受限于云连接，你知道带宽或网络节流可能会适用于数据访问的围墙花园，以及你实际上能够从该供应商的云中提取什么，因此这种碎片化的上下文会导致问题。我们还有一个信任问题，即使有出色的人工智能工具，一些个人和团队在某些情况下也犹豫将控制权交给人工智能。一些组织还没有准备好将某些方面的数据放入另一个云或人工智能供应商的控制之下。而且，如果没有对流程进行一致的验证和确认，就不清楚哪些任务适合人工智能，哪些任务将继续需要人工批准。人工智能还有监管方面的问题。你知道，尤其是在美国以外的国家，对数据驻留有严格的要求，并且正在出现各种新法律，这些法律将推动特别是金融领域监管的公司的治理要求和标准，要求它们在如何使用人工智能方面非常谨慎。然后是预算问题，你知道人工智能的预算从何而来，这显然通常需要抵消其他成本，而人工智能的成本可能非常高，而且可能不可预测，因为人工智能供应商通常会根据服务的基础成本收取使用费，这会导致预算的进一步碎片化和扩张。因此，所有这些工具挑战都会阻碍客户在整个软件生命周期中采用人工智能。人工智能代理如何使软件开发生命周期更加困难、更加复杂？>> 代理依赖于上下文。因此，它们做的第一件事就是查看它们拥有的上下文。但是，你知道，为了将软件从构思一直移动到生产，必须执行一系列任务。没有共享的上下文，代理可能会在后期造成更多瓶颈。代理还需要大量的指导和协调。因此，如果你在多个工具和多个供应商之间编排代理，你也会增加工程师进行这种指导所需的开销。随着团队查看市场上出现的各种不同工具（开源和商业）并将其引入而没有治理，人工智能的扩散也带来了风险。这些可能会导致成本爆炸，因为你知道人工智能是由令牌驱动的，它们可能或可能不在通用合同下，或者不在组织的成本控制下。最后但同样重要的是，你知道，信任是一个真实因素。你知道，你真的信任所有供应商和底层 LLM 代币提供商以及你组织的数据吗？>> 那么，我们如何解决人工智能自动化在软件开发中带来的问题呢？>> 这不仅仅是工具解决方案。这不是用一个工具替换另一个工具，也不是引入更多工具。这确实是一个复杂的人、流程和技术挑战。重新思考软件开发生命周期中顺序的基于流程的交接。是时候转向更持续的创新循环了，在这个循环中，代理能够为我们处理许多这些交接，并且还能够根据最初制定的业务需求和技术需求进行学习和验证，并继续独立地进行迭代，以驱动正确的质量水平，然后人类才需要介入。同样重要的是，我们要解决上下文挑战。你知道，拥有碎片化的工具，每个工具都有自己的上下文，正如我所说，这不会带来最佳结果。因此，这就是我们在这里感到兴奋的一个方面，因为我们一直采取平台方法，并为客户提供生命周期中的各种工具来完成所有阶段，例如我们目前正在构建的 GitLab Orbit 服务。当我们思考解决这个问题时，我们还必须考虑执行环境。人们经常说，你知道，上下文是代理的关键。你提供给代理的上下文越多，结构化得越好，它就越能进行推理、做出决策并采取行动。而且，你知道，通过 MCP 在多个供应商之间将上下文拼接在一起通常很困难。因此，拥有一个计算（代理）和数据共置的环境，我们称之为内部循环架构，其中代理、数据和上下文都在一个网络和一个系统内。我们相信这将带来更高质量、更快、成本更低的人工智能结果。最后，尤其对于人工智能来说，信任正在发生的事情至关重要。你知道，一切都必须是安全的，必须被记录和跟踪，以便能够回顾性地看到所做的推理、所采取的行动，以及由谁在何时执行的，以便拥有审计跟踪并确切了解发生了什么变化以及为什么以及由谁更改的，包括由代理和指导它们的那些人。所以，这确实是解决方案的一个关键部分。而且，在具有内部循环架构的通用环境中，计算和数据共置，这会大大简化这一点。你有一个流程，而不是在人类和工具之间进行交接，你有一个连续的创新平台，可以在一个云中完成所有这些。这就是为什么许多团队发现，通过与战略供应商建立关系进行整合，例如与 GitLab，我们与许多客户分享，GitLab Ultimate 有大约六个月的投资回报期，三年内投资回报率高达 483%，当你采用 GitLab Ultimate 平台中的最佳功能时。这是由人类驱动的生产力提升。我们将我们解决这个问题的方法称为智能编排。这确实是我们公司目前在整个平台上的重点，包括我们新的 Duo 代理平台。>> 你能详细说明一下这个智能编排的概念吗？>> 当我们谈论智能编排时，我们实际上是在谈论三件事：工作流程、上下文和护栏。首先，关于工作流程，我之前提到过，你知道，软件开发过程必须改变，而不仅仅是工具。我们必须超越这种基于阶段的过程，转向持续的创新循环。在人工智能方面，我们必须超越一对一的人工智能聊天体验，这种体验在 Cursor 或 Cloud Code 等 IDE 中现在很普遍。我们正在转向这种多代理的代理群方法，这些代理异步地处理复杂的任务，从产品需求到编码、测试和审查，再到合并请求。以及诸如安全分析、实时安全审查、代码审查和静态分析等任务，以及管道创建和管道监控以及管道失败时的修复。现在，我们快速谈谈上下文。例如，考虑一个代理进行代码更改。你知道，在当前一代人工智能工具中，它能够访问该项目的源代码，但它可能无法访问描述该代码需求的 issue 或 epic，可能无法访问该代码的安全扫描，以及你知道昨天运行显示该代码块实际上存在安全问题。出于其他原因，代理可能不知道该软件将构建到哪个环境或将在哪里部署。所有这些上下文都可以塑造和改变并带来更高质量的结果，如果代理能够将其上下文放入其上下文窗口并进行推理的话。通过我们正在构建的知识图谱，我们对代码进行语义索引，并连接与该代码相关的其他上下文片段。我们可以以非常有效的方式将其交给 LLM，使其能够推理与该代码相关的实体，并访问它做出良好决策和采取行动所需的信息。在我们 GitLab Orbit 的一些早期测试中，我们发现代理的准确性提高了 40%，速度提高了 25%，这得益于结构良好的全生命周期上下文。最后是护栏，系统必须考虑组织设定的标准以及它所处的监管和合规要求，这一点非常重要，代理在这些护栏内采取行动时，必须承担与人类工程师相同的责任和义务。因此，能够在同一个地方应用这些护栏，并让人类和代理在相同的策略驱动的、声明性的、有据可查的规则下工作，是我们正在构建的平台的一个非常重要的部分。我们也认为策略门必须普遍且自动地应用。也就是说，无论是人类编写的代码还是代理编写的代码，都适用相同的规则，相同的审计，相同的治理，无论软件是在何处编写或在哪里流动，这都是我们统一平台方法的一部分。说这是流程、平台和上下文的结合使您能够克服之前描述的碎片化，这种说法准确吗？>> 完全正确。是的，说得很好。>> 你能给我们一些实际的例子吗？>> 即使在 GitLab 内部，我们也一直在构建我们的平台并在内部使用它，当然。你知道，当我想到工作流程部分时，我们让工程师使用该平台来加速代码开发。我们看到中度到重度用户贡献的合并请求比轻度或从不使用的用户多两到三倍。有些团队在构建软件和创建 MRS 时经常遇到管道失败的问题。我听过我自己的工程团队的故事，例如，当他们使用 Duo 代理平台中内置的修复失败管道流程时。响应管道失败的能力可以从几小时缩短到几分钟。因此，再次强调，将执行和数据放在同一个地方，能够在整个软件生命周期中应用代理，确实可以带来一些非常显著的改进，从而实现我们正在寻求的全面创新速度提升。>> 哪些共同点驱动了客户的成功？首先，我看到了客户在实验人工智能和思考它如何真正加速组织创新方面的准备程度和意愿的全部范围，以及那些更具前瞻性、早期采用者，他们不仅愿意尝试工具，尤其愿意改变软件工程的流程，以便真正利用人工智能，这些人正在看到早期成果。其次，这可能并不令人意外，但那些在整合和统一平台方面进行了更多有意识努力的人，他们在采用人工智能方面生活得更简单，因为他们已经获得了共享上下文的好处，并且他们的流程已经作为人类工程方法的一部分被定义，这也导致了更简单、更有意识的人工智能方法来处理软件工程，并且可以在人类和人工智能在基于平台的软件工程方法上进行协作时保持和谐。因此，我认为有意识地去做，并且真正具有前瞻性地看待人工智能，并不仅仅考虑工具，还要考虑所需的流程变更，是成功的关键因素。这一切如何改变一名中层开发人员的工作及其角色？>> 我认为开发人员将从编写代码转向真正定义代码需求，代码应如何构建，甚至更广泛地如何将软件作为整体业务的一部分进行架构。他们还需要从纯粹的实现和关心语言语法和代码行转向验证代码，而不仅仅是技术验证，还要根据最初设定的业务需求进行验证。我认为他们的执行从真正关注已分配给他们的工作项的战术性转向更具战略性地思考“为什么”。你知道，为什么业务要求解决这个问题，为什么软件需要这样运行，而不仅仅是“如何”。这确实是他们有机会成为一个更具战略性和创造性的个人贡献者角色的机会，他们将成为一个利用人工智能代理的超能力并跨系统协调的编排者，而不是仅仅专注于特定项目的某个部分。我认为对正确代码的强调会更大，不一定是编写代码，而是实际能够阅读代码并验证它是高质量的代码，并且符合业务需求以及架构良好的服务将是工作的重要组成部分。因此，今天可能由更高级别的经理和架构师完成的事情，将成为中层人员的机会。他们基本上获得了在组织中提升战略重要性和影响力的能力。通过代理结果测试和驱动质量的能力是该角色中的一个重要部分，因为他们再次关注他们正在创造的业务成果，而不仅仅是交付到项目中的一段代码。这对开发人员来说是一个绝佳的机会，可以培养战略技能，更接近理解业务需求，编排系统并指导人工智能代理。>> 完全正确。>> 你对首席信息官和首席技术官有什么建议来将这些经验教训付诸实践？如果你是一名首席信息官，负责管理组织的共享基础设施，那么你的一项非常重要的职责显然是组织的安全性与合规性。这通常还包括作为该职责的一部分来分析或评估人工智能。并且，正如我所分享的，思考软件工程将如何在人员、流程和技术边界之间发生转变，并支持这种巨大的转变，同时确保业务的安全与合规性不受影响，这一点非常重要。因此，如果这属于你的职责范围，为你的软件工程团队提供支持，那么我认为采用平台方法非常有意义。我认为，对人工智能持前瞻性态度，并提前设定组织的标准，以便能够解除采用的障碍，这一点将非常重要。如果你不负责这一块，而是与首席技术官或其他组织部门合作，为他们提供开发人员体验，那么他们了解我们在这里讨论的挑战并支持他们进行转型就非常重要。我知道 GitLab 的首席技术官和首席信息官在这里正在非常紧密地合作处理这些事情。>> Bill，对于希望采纳您所描述的经验教训的组织来说，第一步是什么？>> 第一步是审计当前在工具上的投资水平，在存在碎片化的地方考虑整合。我认为衡量软件交付的端到端流程非常重要。不仅仅是编码速度，而是从构思到生产需要多长时间。正如我们所讨论的，在开始时就考虑安全和治理也很重要，即购买一个内置人工智能治理、具有审计跟踪并能够在购买解决方案时识别合规性差距的系统。你知道，成本是我们确定的一个潜在挑战。因此，显然，简单性是关键。你整合和统一工具的越多，你对人工智能的真实成本的可见性就越好，并确保你从中获得投资回报。你知道，很多团队喜欢做试点。我认为这是一个很好的方式来快速尝试软件并评估它是否能解决你团队的需求。我认为试点是一件好事，但尤其重要的是，当你考虑整合以及团队和代理在整个生命周期中协同工作时，你应该考虑试点，因为它需要人员、流程和技术变革，并且在生产环境之外的安全环境中进行试点是关键。当你考虑自主性以及组织快速发展的能力时，我会说要提前定义你希望人们坚持的标准，以及那些更自由的形式，他们可以做出决定的事情，这将加速组织做出决策和抓住人工智能机会的能力。所以，这些可能是我首先会关注的事情。人们可以使用一些核心指标来评估他们在这一旅程中的进展吗？>> 是的，客户问我的头等问题之一是，我如何衡量人工智能的真正价值？我将其分为几个不同的类别。首先是端到端指标，正如我所说的，不仅仅是人工智能生成的代码行数或人工智能节省的编码小时数百分比，而是考虑整体周期时间。从构思到生产需要多长时间。当你考虑合并请求时，这是将人工智能代理编写的代码实际投入生产的能力。这个周期非常重要。因此，从创建合并请求或拉取请求到实际部署的时间。这对许多团队来说是一个新的瓶颈。理解这一点很重要。部署频率。代码多久才能真正投入生产？这可能是另一个值得关注的瓶颈。然后是变更失败率，这也是一个很好的考虑因素，因为你知道，如果你生产出更多的代码并将其交付给客户，但错误却在增加，那么这一点就没有意义了。因此，查看管道失败和查看错误逃逸率也非常有价值。最后一点，我知道这在很多团队的脑海里已经很久了，但要关注平均恢复时间。当生产环境出现问题时，你多久能恢复正常运行？当然还有治理和质量，你知道，看看有多少安全漏洞按严重程度划分以及趋势，你的合规性审计准备情况等等。以及最后一类，业务成果。你知道，你的开发人员满意度是在增加还是在减少？因为开发人员满意度直接关系到软件创新和速度，在整个生命周期中节省的时间，再次是端到端，这对于将组织的创新能力烘焙回去非常重要，然后是成本效益。你知道，你的人工智能成本是否与你从投资中获得的相应价值相匹配。GitLab 首席执行官 Bill Staple，非常感谢您分享关于在软件开发生命周期中有效使用人工智能的内部见解 [音乐]。>> 非常感谢 Michael，感谢您邀请我。