随着GitHub将其第三方编码代理扩展到Claude和Codex，它希望巩固开发人员对其自身平台的忠诚度。

　　开发人员从未如此倾向于使用人工智能，但从未如此倾向于信任其输出。在Stack Overflow的调查中，在开发中使用人工智能工具的受访者比例持续攀升（2023年为44%，2024年为62%，2026年为83%），但信任并没有跟上。在2025年的准确性问题中，只有大约33%的人信任人工智能的输出，而46%的人不信任它。2026年，Stack Overflow改变了问题，但仍然发现只有7%的开发人员信任人工智能做出重要的工作决策，如果他们可以轻松检查输出，则上升到48%。

　　因此，采用远远领先于信心。这很可能是某人介入并修复信任差距的机会。

　　GitHub在这里有机会，即使开发人员更喜欢其他人的编码代理。团队已经使用它来检查、测试和审查代码。帮助他们从Claude或Codex的工作做同样的事情，为开发人员提供了更多选择，同时使其自己的平台更加粘。这是一个非常聪明的柔术动作，但它能奏效吗？

　　早在2023年，我担心GitHub对Copilot的热情会分散其对Git的注意力，特别是使平台有用的可见性和协作。现在有更好的可能性：人工智能可以使这些功能更有价值。随着提出更改的工具数量的增加，公司需要在检查、测试和接受它们的方式上保持连续性。简而言之，人工智能可以使GitHub比以往任何时候都更相关。

　　使用不是信任投票

　　仅仅因为我们使用人工智能来更快地构建，并不意味着我们一定相信它。2026年的调查明确了这一区别。其修订后的信任问题询问了人们依赖人工智能的条件。还有？嗯，大约48%的人表示他们信任它，但只有当他们可以轻松验证输出时。只有7%的人隐含地信任它做出重要的工作决策。如前所述，这些数字不能与之前的准确性问题直接比较，但它们确实描述了一个实际的讨价还价：人们想要帮助，但越来越多地，他们也想要可以检查的证据，因为他们担心人工智能“几乎，但不完全正确”。

　　这是使用人工智能的明智方式。助理可以通过查找不熟悉的API或提出小的更改来节省时间，而我们也不必完全授权它确定客户的付款是否被正确处理。我们对法学硕士的信心应该与特定任务及其后果相关联。

　　公司的标准不应该因为代理人编写了代码而改变。审查员仍然需要知道更改应该完成什么，哪些检查通过，以及谁接受了它。这就是团队如何赢得信心，随着时间的推移委派更多工作。

　　不同的代理人，相同的规则

　　GitHub已经开始围绕这个机会进行构建，因为它寻求成为更广泛的人工智能工具领域的治理层。因此，其第三方编码代理（目前处于公开预览中）包括Claude和Codex，而不仅仅是Copilot。问题或提示可以成为提议的更改、拉取请求或需要进一步审查的问题。GitHub表示，这些在其平台上运行的代理受到与Copilot云代理相同的安全保护和限制。请注意，这些策略不会自动扩展到VS Code中的本地代理，这是一个重要的边界。

　　有用的部分是连续性。公司可以尝试不同的发电机，同时在评估工作的地方保持一致。每当首选助理发生变化时，就不需要重新发明要求、现有测试、审查责任和验收规则。正如我所指出的，鉴于事情的发展速度如此之快，构建人工智能的变革很重要。

　　考虑一个代理被要求修复授权错误。公司需要保留一个简单的要求：一个客户永远不能阅读另一个客户的记录。从副驾驶切换到克劳德不应改变该要求或强制执行它的回归检查，或者谁有权接受补丁。如果架构正确，新代理是另一个在既定流程内工作的供应商。

　　企业可以花费大量精力将工具融入其现有职责和流程中。如果切换代理迫使他们重建该安排，模型选择将以订阅价格无法捕获的方式变得昂贵。保存它的平台可以使实验变得实用。有理由相信GitHub可以成为那个平台，因为多年来它一直以人类为主导的发展。

　　一个好的平台的引力

　　GitHub不会仅仅通过收集代理活动来获得信任，其企业信任的历史也不能保证其未来。但GitHub处于一个良好的位置，可以帮助开发团队将证据与他们即将做出的决定联系起来，有足够的上下文来挑战看起来不错但可能不是的代码。

　　顺便说一句，我并不是说我们需要确保系统（无论是GitHub还是其他东西）应该永远坚持验证每一个琐碎的变化。GitHub最近在公共预览中引入了Copilot代码审查的可选功能，以批准拉取请求并满足所需的批准规则。它不是自动的；管理员必须启用它，并且可以通过文件路径限制它。但这是一个好兆头，表明事情的发展方向。

　　它也相当有用。团队可以合理地自动接受一些常规更改，同时将敏感工作保留给知识渊博的审查员。但启用另一个人工智能批准本身并不能提供独立证据。公司仍然必须决定哪些检查证明该权限是合理的，以及何时必须进行干预。GitHub自己的文档警告说，Copilot评论可能会漏出问题，并建议用人工评论来补充这些问题。

　　我喜欢GitHub这样做的方式。虽然有些人担心GitHub的微软化，认为该公司正在使GitHub Copilot服从于销售微软人工智能服务的更大任务，但GitHub开放对第三方代理的访问实际上是开发人员和商业天才。对于开发人员来说，他们可以使用他们想要的任何前沿模型，并通过GitHub便捷地计费。通过这种方式，即使Claude或Codex赢得编码任务，GitHub也可以留住付费客户。具有讽刺意味的是，这种扩大的选择导致GitHub作为一个平台更难离开。企业应该权衡一致审查和控制的便利性与对GitHub的更大依赖性的可能性，但便利性通常对开发人员来说是胜利的。

　　其他平台可以提供类似的控制，因此GitHub并不能梦游进入长期代理成功。即便如此，它有一个明显的机会让开发人员更改编码代理，而不会让公司重建将代码投入生产的流程。如果GitHub做对了，即使其他人编写代码，它也能留住客户。这是一种超级聪明的方式，可以坚持GitHub对开发人员需求的长期关注，同时也提供了一个非常以微软为中心的平台未来。