AI Makes Developers Faster. Why Can It Make Teams Slower?

AI 让开发者变快了，为什么反而可能让团队变慢？

This was first published on the Vibsync blog. Reposting for the DEV community. The short version: AI reliably makes each developer faster. Whether it makes the team faster is a separate question — and the gap between the two is where a lot of quiet cost hides. Below: the five coordination costs that eat the difference, a ten-question diagnostic, and five operating principles.

本文首发于 Vibsync 博客，现转载至 DEV 社区。简而言之：AI 确实能让每位开发者变得更快。但它是否能让整个团队变快则是另一个问题——而这两者之间的差距，正是许多隐性成本潜藏的地方。下文将探讨：蚕食效率的五种协作成本、一份十问诊断表，以及五项运作原则。

Picture three developers, three AI coding agents, and one repository. Each developer can now produce candidate code, tests, and refactors faster than before. Yet releases move at the same pace, review queues grow, and the same facts keep getting rediscovered. That’s not a paradox, and it isn’t a reason to slow anyone down. It’s a reminder that individual speed and team speed are different quantities, and AI coding agents scale the first far more easily than the second. Give everyone a faster typewriter and you get more pages — not necessarily a better book, written faster, by a group.

想象一下，有三名开发者、三个 AI 编程助手和一个代码仓库。每位开发者现在都能比以前更快地生成候选代码、测试用例和重构方案。然而，发布进度依然缓慢，代码审查队列不断堆积，同样的问题也在反复被重新发现。这并非悖论，也不是让大家慢下来的理由。这提醒我们：个人速度与团队速度是不同的量级，而 AI 编程助手在提升前者方面远比提升后者容易。给每个人一台更快的打字机，你只会得到更多的页数——但这并不意味着团队能更快地写出一本更好的书。

Individual output is not team throughput. It’s worth separating two things we tend to blur: Individual output — how much finished work one developer (plus their agent) produces. Team throughput — how much shippable, coherent work the group produces together, after review, rework, waiting, and reconciling everyone’s changes. AI agents lift individual output directly. Team throughput is what’s left after the coordination overhead is paid, and that overhead doesn’t shrink just because each person got faster.

个人产出不等于团队吞吐量。我们需要区分两个容易混淆的概念：个人产出——指一名开发者（及其助手）完成了多少工作；团队吞吐量——指团队在经过审查、返工、等待和协调各方变更后，共同产出了多少可交付、连贯的工作成果。AI 助手直接提升了个人产出。而团队吞吐量是扣除协作开销后剩下的部分，这种开销并不会因为每个人变快了而减少。

A useful way to hold it in your head — not as a formula to compute, just as a shape: team throughput ≈ the sum of local speed-ups − rework − waiting − reconciliation. When you add agents, the first term grows. If nothing else changes, the last three grow too — because there’s now more work in flight, produced faster, by people who can’t all see what the others are doing.

一个有用的心智模型（不必作为精确公式，仅作为一种形态参考）：团队吞吐量 ≈ 局部提速之和 − 返工 − 等待 − 协调。当你引入 AI 助手时，第一项会增加。如果其他条件不变，后三项也会随之增加——因为现在有更多的工作在进行中，且由无法实时获知他人进展的人员快速产出。

The interesting question for a team lead isn’t “how do I make everyone faster?” It’s “which of those subtraction terms is my real ceiling?” There’s some external signal here worth taking seriously. In one 2025 study of experienced open-source developers, participants working on mature codebases they knew well completed the measured tasks more slowly with AI assistance, even though they expected AI to speed them up. The conditions were specific, so this does not generalize to “AI slows you down.” The narrower lesson is more useful: perceived speed and measured task time can diverge. And the 2025 DORA report frames AI as an amplifier — it magnifies the strengths and the dysfunctions an organization already has. That suggests weak coordination can become more costly as AI increases the amount of work in flight.

对于团队负责人来说，有趣的问题不是“我该如何让每个人变快？”，而是“这些减项中，哪一个才是我的真正瓶颈？”这里有一些值得重视的外部信号。在 2025 年一项针对资深开源开发者的研究中，参与者在处理他们熟悉的成熟代码库时，尽管预期 AI 会提速，但实际完成任务的速度反而变慢了。由于实验条件特殊，这不能概括为“AI 会让你变慢”。更具参考价值的教训是：感知速度与实际任务耗时可能存在偏差。2025 年的 DORA 报告将 AI 定义为一种“放大器”——它会放大组织现有的优势和功能障碍。这意味着，随着 AI 增加了在途工作量，薄弱的协作可能会变得更加昂贵。

The five coordination costs

五种协作成本

When AI raises individual output without improving collective delivery, the gap often comes from some mix of these five costs. None of them are new — AI can raise the volume and the speed at which they hit.

当 AI 在不改善集体交付的情况下提升了个人产出时，差距往往源于以下五种成本的组合。它们并非新问题，但 AI 可能会增加它们发生的频率和强度。

Duplicated discovery. One person’s agent works out that the staging database resets nightly, or that a module must stay backward-compatible during a migration. That fact is real and hard-won — and it lives in one chat history. The next agent, on another machine, re-derives it from scratch, or worse, derives the opposite. The team keeps paying for the same lesson.
重复发现。 一个人的助手发现测试数据库每晚都会重置，或者某个模块在迁移过程中必须保持向后兼容。这个事实是真实且来之不易的——但它只存在于一个聊天记录中。另一台机器上的另一个助手会从头开始重新推导，或者更糟的是，推导出相反的结论。团队不得不为同一个教训反复买单。
Decision drift. Someone decides “we’re standardizing on integer cents, never floats.” It’s correct, it’s stated aloud once, and then three agents that never heard it quietly make three different choices. Nobody disagreed; the decision just didn’t travel.
决策漂移。 有人决定“我们统一使用整数分，绝不使用浮点数”。这个决定是正确的，也曾口头传达过，但随后三个没听到该决定的助手悄悄做出了三种不同的选择。没人反对，只是决策没有传达到位。
Ownership ambiguity. With everyone moving fast, “who’s on the payments refactor right now?” stops having an obvious answer. Two people pick it up, or nobody does because each assumed the other had it.
所有权模糊。 当每个人都行动迅速时，“现在谁在负责支付模块重构？”这个问题不再有明确答案。结果可能是两个人同时在做，或者因为都以为对方在做而导致无人问津。
Handoff loss. Work moves between a morning session and an afternoon one, between a laptop and a CI box, between one developer and the teammate covering for them — or between Claude Code and Codex. Each hop drops context: the decision just made, the task half-finished, the question still open, the files someone was mid-edit on.
交接丢失。 工作在上午和下午的会话之间、笔记本电脑和 CI 环境之间、开发者和代班队友之间，或者 Claude Code 和 Codex 之间流转。每一次跳转都会丢失上下文：刚做出的决定、未完成的任务、悬而未决的问题，以及正在编辑的文件。
Collision and reconciliation. Two agents edit overlapping parts of the same file on two branches. Git faithfully reports the conflict — after both sides did the work. The collision was created hours earlier, when neither side knew the other had started. Now someone spends the afternoon untangling it.
冲突与协调。 两个助手在两个分支上编辑同一个文件的重叠部分。Git 会忠实地报告冲突——但那是在双方都完成工作之后。冲突在几小时前就已经产生，当时双方都不知道对方已经开始工作。现在，有人不得不花一下午时间来解决这些冲突。

Notice what these have in common: they are not primarily model-capability problems, so a better model or a faster agent does not fix them by itself. They are coordination problems, and they can get worse precisely when individual work gets faster.

请注意它们的共同点：它们主要不是模型能力问题，因此更好的模型或更快的助手本身无法解决这些问题。它们是协作问题，而且恰恰在个人工作变快时，这些问题可能会变得更严重。

Five operating principles that cut the cost

五项降低成本的运作原则

The fix isn’t to slow anyone down. It’s to make the coordination that used to happen implicitly in a small, synchronous team happen explicitly — because you cannot assume that every agent has read your Slack or can see the context in a teammate’s private session.

解决办法不是让任何人慢下来。而是将过去在小型同步团队中隐性发生的协作变得显性化——因为你不能假设每个助手都读过你的 Slack 消息，或者能看到队友私下会话中的上下文。

Shared decisions travel. When someone settles a rule — “v1 API frozen for 90 days” — it should land somewhere every agent can retrieve when it starts, not in one chat. Decide once; make the decision available to every agent.
共享决策的传递。 当有人定下一条规则——例如“v1 API 冻结 90 天”——它应该存放在每个助手启动时都能检索到的地方，而不是只存在于一个聊天记录中。决策一次，让每个助手都能获取。
Ownership is visible. “Who’s on what” should be a live, shared picture, not something you reconstruct by asking around.
所有权可视化。 “谁在负责什么”应该是一个实时的、共享的视图，而不是需要通过四处询问才能拼凑出来的东西。