When everyone has AI and the company still learns nothing
When everyone has AI and the company still learns nothing
当每个人都用上了 AI，公司却依然一无所获
Ethan Mollick has been writing about AI adoption in organizations for a while now. In Making AI Work: Leadership, Lab, and Crowd, he makes the point that individual productivity gains from AI do not automatically become organizational gains. People may get faster, write better, analyze more, automate more, or quietly become cyborg versions of themselves. The company may still learn almost nothing.
伊森·莫利克（Ethan Mollick）长期以来一直在撰写关于组织如何采用 AI 的文章。在《让 AI 发挥作用：领导力、实验室与大众》（Making AI Work: Leadership, Lab, and Crowd）一书中，他指出：个人通过 AI 获得的生产力提升，并不会自动转化为组织的收益。员工可能会变得更快、写作更好、分析更多、自动化程度更高，或者悄然进化成“半机械人”般的个体，但公司本身可能依然几乎学不到任何东西。
A lot of companies are now entering the phase where GitHub Copilot licenses are provisioned, ChatGPT Enterprise exists somewhere in the stack, Claude or Gemini or Cursor show up in pockets, and every team has at least one person who is much further along than the official enablement material assumes. Some of this is visible, yet much of it is not. Management sees license usage (“Where is the ROI for the 2 mio € we paid Anthropic last year?”), maybe prompt counts, maybe a survey, maybe a few internal PoCs that feel encouraging enough to put into a steering committee deck. In other companies, AI went straight to IT and died.
许多公司现在正进入这样一个阶段：GitHub Copilot 的许可证已经发放，ChatGPT Enterprise 存在于技术栈的某个角落，Claude、Gemini 或 Cursor 在员工中零星出现，且每个团队中至少有一位成员的 AI 使用水平远超官方培训材料的预期。这些现象有些是可见的，但更多是隐蔽的。管理层看到的只是许可证的使用情况（“我们去年付给 Anthropic 的 200 万欧元投资回报率在哪里？”），或许还有提示词（prompt）的数量、一份调查问卷，或者几个看起来足够令人鼓舞、足以放进指导委员会演示文稿中的内部概念验证（PoC）。而在另一些公司，AI 项目直接被丢给 IT 部门，然后就此夭折。
I think everyone knows this is the phase where it gets complicated, like, really complicated. The “messy middle” of AI adoption starts when AI use is everywhere, uneven, partially hidden, difficult to compare, and not yet connected to organizational learning.
我想大家都知道，这就是事情变得复杂——我是说，变得非常复杂——的阶段。当 AI 的使用变得无处不在、参差不齐、部分隐蔽、难以横向比较，且尚未与组织学习挂钩时，AI 采用的“混乱中间地带”便由此产生。
Everyone has Copilot now
现在每个人都有 Copilot 了
The first phase of AI adoption is (mostly) comfortable because it looks like other enterprise rollouts. You buy seats. You define acceptable use. You run training. You create a champion network. You ask people to share use cases in a Teams channel, which will briefly look alive and then become one more corporate attic full of good intentions.
AI 采用的第一阶段（通常）是舒适的，因为它看起来就像其他企业级软件的推广一样：购买席位、定义合规使用规范、开展培训、建立种子用户网络。你要求员工在 Teams 频道分享使用案例，这些频道起初看起来很活跃，但很快就会变成另一个堆满“良好愿望”的企业阁楼。
The second phase is much stranger: one team uses Copilot as autocomplete and calls it a day. Another team runs Claude Code in tight loops, with tests, reviews, and constant steering. A product owner suddenly prototypes real software instead of mocking screens in Figma. A senior engineer delegates a root-cause analysis to an agent and comes back to the valid solution in under an hour; this would’ve taken him two weeks without AI. A junior person produces polished code but has no idea which architectural assumptions got smuggled into the system. A support team quietly turns recurring tickets into workflow automation, because they know exactly where the work hurts and nobody in the Center of Excellence ever asked the right question.
第二阶段则要奇怪得多：一个团队把 Copilot 当作自动补全工具用完即止；另一个团队则在紧密的循环中运行 Claude Code，伴随着测试、审查和持续的引导；产品经理突然开始原型化真正的软件，而不是在 Figma 里画草图；资深工程师将根本原因分析委托给 AI 代理，不到一小时就得到了有效的解决方案，而这在没有 AI 的情况下本需两周；初级员工产出了精美的代码，却完全不知道哪些架构假设被“走私”进了系统；支持团队悄悄地将重复性工单转化为工作流自动化，因为他们最清楚痛点在哪里，而卓越中心（Center of Excellence）里从未有人问过正确的问题。
All of these things can happen in the same company at the same time. That is what makes the messy middle messy: the adoption unit is no longer the organization, and maybe not even the team. It is the loop inside the work!
所有这些事情可能同时发生在同一家公司。这就是“混乱中间地带”之所以混乱的原因：采用 AI 的单位不再是组织，甚至可能不再是团队，而是工作流程中的每一个“循环”！
Mollick’s Leadership, Lab, and Crowd frame is useful here. Leadership sets direction and permission, The Crowd discovers use cases because the Crowd does the actual work. The Lab turns those discoveries into shared practices, tools, benchmarks, and new systems. But the part I keep getting stuck on is the same one that shows up in agentic engineering again and again: how does the learning actually travel?
莫利克的“领导力、实验室与大众”框架在这里很有用。领导层设定方向和权限，大众（Crowd）发现用例，因为他们是实际工作的执行者。实验室（Lab）将这些发现转化为共享实践、工具、基准和新系统。但我一直困惑的地方，也是在代理工程（agentic engineering）中反复出现的问题：这些经验究竟是如何传播的？
The old change machinery is too slow for this
旧的变革机制对此太慢了
Most companies will try to process AI adoption through the machinery they already have. Communities of practice, brown-bag sessions, champion networks, enablement decks, office hours, monthly demos, surveys, maybe a dashboard. Fair enough, I did it, you did it. Some of that helps, especially in organizations that still need permission to experiment at all.
大多数公司会试图通过现有的机制来处理 AI 的采用。比如实践社区、午餐分享会、种子用户网络、赋能演示文稿、答疑时间、月度演示、调查问卷，或许还有一个仪表盘。这很合理，我也做过，你也做过。其中一些确实有帮助，尤其是在那些仍需要获得许可才能进行实验的组织中。
But the interesting AI work does not wait for the next community meeting. It appears inside a code review, a sales proposal, a research task, a product prototype, a production incident, a test strategy, a compliance question. Or when someone figures out that for a certain class of product components, they can set up something close to a dark factory: write the intent, let the agent run a very loose loop, apply enough backpressure to keep it on track, evaluate the outcome against strong scenarios, refine the intent, and repeatedly get high-quality results. By the time the story is cleaned up enough to become a best-practice slide, the important learning has often lost its teeth. What made it useful was the friction: the missing context, the test that failed, the weird API behavior, the moment where the agent sprawled into nonsense and someone had to pull it back.
但真正有趣的 AI 工作不会等待下一次社区会议。它出现在代码审查、销售提案、研究任务、产品原型、生产事故、测试策略或合规性问题中。或者当有人发现，对于某类产品组件，他们可以建立一种类似于“黑灯工厂”的模式：写下意图，让代理运行一个非常宽松的循环，施加足够的反向压力以保持其轨道，根据强有力的场景评估结果，优化意图，并反复获得高质量的产出。等到这个故事被整理成最佳实践幻灯片时，其中重要的经验往往已经失去了锋芒。真正让它有价值的是那些摩擦：缺失的上下文、失败的测试、奇怪的 API 行为，以及代理陷入胡言乱语时有人不得不将其拉回来的那一刻。
I have been thinking about this through the same lens as the elastic loop. AI collaboration is not one mode! It stretches from tight, synchronous co-driving to looser, asynchronous delegation. The adoption question is not simply “are people using AI?” It is whether teams know which loop size to use, where they need resistance, which artifacts should survive the loop, and how those artifacts become something the organization can learn from.
我一直通过“弹性循环”的视角来思考这个问题。AI 协作不是单一模式！它涵盖了从紧密的、同步的“共同驾驶”，到更宽松的、异步的“委托”。采用 AI 的问题不仅仅是“人们在用 AI 吗？”，而是团队是否知道该使用哪种规模的循环，在哪里需要阻力，哪些产出物应该在循环中保留，以及这些产出物如何转化为组织可以学习的知识。
That is a much harder question than tool usage or bean (token) counting. 这是一个比工具使用率或豆子（Token）计数难得多的问题。
Scrum was built for expensive iteration
Scrum 是为昂贵的迭代而生的
I argued that much of modern software process exists because human iteration used to be expensive. Sprint planning, estimation, standups, user stories, ticket grooming, handoffs, all the ceremony around coordination and risk reduction. Reasonable, given the constraints. If a single iteration takes days or weeks, you need structures that prevent people from wasting too many of them.
我曾论证过，现代软件流程之所以存在，很大程度上是因为人类的迭代曾经非常昂贵。冲刺计划、估算、站会、用户故事、工单梳理、交接，所有围绕协调和降低风险的仪式，在当时的约束条件下是合理的。如果单次迭代需要几天甚至几周，你就需要结构来防止人们浪费太多的迭代周期。
But agentic engineering changes the economics: It makes more options materializable! It lets teams move from intent to prototype to evaluation much faster. It lets product people see working software earlier. It lets engineers test more hypotheses before committing. It does not magically make delivery easy, but it moves the constraint away from implementation and toward intent, verification, judgment, and feedback.
但代理工程改变了经济学：它让更多的选项变得可实现！它让团队能以快得多的速度从意图走向原型再到评估。它让产品人员能更早看到可运行的软件。它让工程师在做出承诺前能测试更多的假设。它并不能神奇地让交付变得容易，但它将约束从“实现”转移到了“意图、验证、判断和反馈”上。
The awkward thing is that many organizations spent twenty years calling themselves agile while preserving the organizational reflexes agile was supposed to remove. Now AI makes real agility more plausible, and the system still asks for two-week sprint commitments, handoff documents, and all the stuff that assumes iteration is scarce.
尴尬的是，许多组织花了二十年时间自称“敏捷”，却保留了敏捷本应消除的组织惯性。现在，AI 让真正的敏捷变得更加可行，而系统却依然要求两周一次的冲刺承诺、交接文档，以及所有那些假设迭代是稀缺资源的老旧流程。