Faster Developers Don’t Make a Faster Team

更快的开发者并不等于更快的团队 - JetBrains 博客

Air

一个智能代理开发环境

关注

• 关注：

• X X

获取一些灵感

智能代理 AI

AI

JetBrains

JetBrains AI

更快的开发者并不等于更快的团队

Gleb Malkov

工程团队关于与AI代理协作的洞察。系列文章第一部分。

过去几个月，我与各类工程组织进行了大量探索性对话，从拥有16名开发者的软件机构到电信公司、游戏工作室和拥有数千名开发者的咨询公司。几乎所有团队都在询问是否应该使用AI代理。在一家金融数据提供商的调查中，约80%的工程师每天都在使用AI代理。当我将听到的内容按三个层级分类——个人开发者、团队和组织——一个模式逐渐显现。个人开发者现在可以借助代理大幅提升效率，但收益分布不均。组织层面涉及可见性、成本和控制。团队层面则是收益停滞的领域：少数人效率大幅提升，但即使重新设计工作流程的团队也难以将更快的实现转化为更快的交付。

以下是我最常听到的三种场景。

1. 每个人都有代理，但无人共享配置

当我询问开发者是否共享提示词、规则或指令文件时，诚实的回答通常是某IT服务公司架构师告诉我的版本：“我们还没做到这一步。我们只是在早上喝咖啡时分享一些知识。”

即使团队开始规范化实践，这种共享也往往通过潜移默化的方式传播。一家法律科技公司的工程总监表示：“没有统一标准。我们会将规则存放在[AI团队]的仓库中，然后通过分享有效方案，慢慢渗透到更老的.NET项目中。”

当共享机制系统化时，反而变得脆弱。一家拥有上百个仓库的移动公司平台负责人解释道，他将基础规则存放在一个仓库中，并复制到每个服务中：“如果更新了基础规则，就需要更新所有仓库，而这些仓库可能已经被个性化定制。”

一家咨询公司的解决方案架构师观察了50多个客户团队后补充道，共享配置往往只是表面功夫：

“人们热衷于创建代理、技能、CLAUD.md文件等一切内容。但他们会发现这些配置实际上可能降低质量。有些配置甚至完全不起作用。”

结果是团队内部差距逐渐扩大。一家地图公司的工程经理举例说明：“20%的工程师生成了80%的代码或消耗了80%的token。我们不清楚其他80%的工程师是不够聪明，还是没有正确使用，或者需要培训。”

一家金融数据提供商的高级工程师表示：“专业能力存在明显差距。如果你写了一个糟糕的提示词，代码库需要被读取三次。”

一家云咨询公司的CEO提出了所有问题的核心：“在我的团队中，有一个超级明星开发者，他的效率是其他人的10倍。我如何捕捉他的行为模式，并在团队中推广？”

关于如何与代理协作的知识分散在个人配置、Slack对话和维基中。每个代理都从零开始处理任务；每个人都要重复解释相同的规范，输出质量取决于谁在发提示而不是团队的共识。一位大型咨询公司的高级工程师坦言：“没有人真正成熟。这项技术太新了，还谈不上成熟。”

“随着我们不断推进，瓶颈逐渐转移到代码审查和规划阶段。如今的实现过程其实非常迅速，”法律科技公司的工程负责人表示，他们已经在任何人工审查拉取请求之前，就运行了AI审查关卡。

这家地图公司进行了测量：“如果只看纯粹的数字，拉取请求的耗时实际上增加了。这可能是因为人工参与环节或对质量信心不足，导致人们倾向于检查所有内容。但目前我们还没有确切的答案。”

一家大型网络设备供应商的平台团队发现存在同样的瓶颈：“我们基本上是在尝试将非代理驱动的流程应用于变化极其迅速的工作。”

“仅仅因为你能够构建100个功能，并不意味着你应该这么做。人们无法消费这么多内容。”

一家游戏公司的首席工程师总结了演示与团队实际工作流程之间的差距：“实验是一回事，但将东西投入生产环境——包括所有流程、优缺点、审查以及2026年人们需要处理的各种事项——则是另一回事。”

瓶颈也向上游转移。目前每五到六名开发人员只配备一名产品经理，开发人员处理工作的速度如此之快，以至于将待办事项推进到可供人工或代理处理的状态变得极具挑战性。

审查流程原本是为人类节奏的变化设计的。如果验证输出的成本超过了它带来的节省，团队实际上反而出现了倒退。

3. 自动化枯燥工作会带来新的运营负担

团队清楚地知道他们会将哪些任务交给代理。一家游戏公司的工程负责人分享道：“每当有人创建一个MR（合并请求）时，我们都希望运行特定的流程。每天晚上，我们都会运行一个文档更新器，遍历所有仓库以确保所有内容保持一致。”

他的下一个目标是：“以更自主的方式升级库、升级框架、解决已识别的安全漏洞。”然而，对于许多团队来说，仅启动这些后台自动化流程本身就是一个障碍，因为缺乏时间和专用的基础设施。

一些团队已经通过手动操作证明了这一点。一家代理机构曾将一个模糊的客户工单在10分钟内就转换成了一个准备就绪的拉取请求。现在他们希望这个流程能够自动运行，设想的是：“当我们完成一天的工作后，第二天回来时，所有我们要求的任务都已完成。”

对于那些成功构建了运营流水线的团队来说，阻碍他们扩展的因素并非缺乏创意，而是自动化运行的位置、谁来负责以及如何覆盖每个项目。一家咨询公司的高级工程师构建了这样一个系统——一个运行在虚拟机上的Docker容器中的代理，响应Webhook事件——但随后遇到了阻碍：

“最大的问题在于我们必须维护它。如果我们在一个客户上部署，还需要想办法将更新分发到另一个项目。”

与此同时，平台负责人变成了一个人类API。从这家移动公司的情况来看：“今天，后端团队问我们：‘能否在GitHub的CI中提供一个密钥和一个用于自动生成测试的密钥？’”而当每个团队都自行自动化时，协调工作就会崩溃。游戏公司曾经历过：“关于如何控制每个人都想创建代理的情况，我们进行了非常激烈的讨论，但我们没有任何治理手段。”

这些情况的共同点

仅仅为每个开发者配备一个能干的代理，并不能单独解决这些问题。一些团队缺乏共享的基础设施，而另一些团队已经在构建它，并发现维护它所需的持续工作。正是为了弥合这一差距，我们才推出了 Air Teams。

在接下来的系列文章中，我将逐一探讨三种场景——共享的上下文和技能、为代理输出构建的代码审查流程，以及团队共同拥有的自动化流程。基于真实客户的案例，我将展示如何通过共享意图、决策、影响和验证结果，帮助下一位开发者独立理解变更内容，并减少审查工作量。

敬请期待。

• Share

• Facebook

• Twitter

• Linkedin

Prev post

Air Teams: Bring Your Best Agentic Workflows to the Whole Team – and Automate Repeatable Work