# The Long Becoming
**作者**: Alfred Lin
**日期**: 2026-05-05T13:49:01.000Z
**来源**: [https://x.com/Alfred_Lin/status/2051660439667527715](https://x.com/Alfred_Lin/status/2051660439667527715)
---
A true redesign is the single largest factor separating companies that capture value from AI from those that do not.
--
@tobi at @Shopify, @LuisvonAhn at @duolingo, and @klarnaseb at @Klarna all traveled a familiar road. A bold internal memo becomes a public artifact. Headlines follow. Then, months later, a clarification or a walkback. Klarna paused its hiring freeze. Duolingo walked back the replacement framing. Shopify softened its language without abandoning the principle. What we see in public posts and headlines is just the visible tip of an iceberg. What we do not see is the wrestling beneath the surface. What does it mean to become a native of a paradigm you did not grow up in? Becoming is harder than declaring.
For two decades, we used the terms "enabled" and "native" to differentiate the adopters of technology shifts. Cloud-enabled meant lifting existing applications onto AWS. Cloud-native meant designing for the cloud from the first line of code. The two paths looked similar early on and diverged dramatically a few years later.
The same divide is here again. The AI-enabled company adds an AI assistant to the same sales team and measures the number of emails saved. The AI-native company asks: if we were starting from scratch today, how would we build each layer from the bottom up?
The most advanced AI founders we’ve spoken with found that a true redesign (of your product, process, workflow, and company) is the single largest factor separating companies that capture value from AI from those that do not. It is the willingness to rebuild from first principles and take your product, processes, workflows, and companies apart, then put them back together. For them, it’s a refounding moment. Most companies stop short and install the assistant on top of yesterday's process, then wonder why their business looks roughly the same.
What does becoming look like in practice? Practice is usually unsexy and resembles solving a sequence of bottlenecks. You solve one, and the rate-limiting step moves somewhere else. The work is figuring out which bottleneck you are in right now and moving your organization to the next one.
The first bottleneck is adoption. Do people actually use the tools? To answer that, we start leaderboards of token usage to encourage adoption. Soon enough, we see adoption, but is it productive or just token-maxing? How should engineering managers help their teams adopt effectively? @lorenc_dan, CEO of @chainguard_dev, recently shared his Token Rule with his team and gave us permission to publish it. He expects every engineering manager to have token usage near the median of their direct reports. Below the median, leaders lack the lived experience to coach. Far above it, they need to be teaching, not hoarding leverage. It is a small, mundane policy change from token leaderboards. That is the point. Adoption is cultural and needs to be shaped by leadership.
Once people are actually using the tools effectively, the second bottleneck shifts to true engineering velocity, measured by your organization's pull requests. At a recent board meeting, a CTO told me the top five to ten percent of his builders are now five times more productive than they were a year ago. The median builder is up by 20 percent. The job to be done is to train the rest of your team so the velocity of your top decile becomes accessible to the rest.
Once engineering velocity rises, the third bottleneck moves again. Now, it is product velocity and product experience quality. Engineers can ship, but can the company decide what to build fast enough to keep up? Roadmaps that used to take quarters now take weeks. Product managers, designers, and leaders with great taste and judgment who generate great product ideas become the rate limiters. This is where most companies stall. They scale engineering velocity into a firehose pointed at the wrong target. Once you can ship anything fast, the question becomes whether the experience itself is meaningfully better.
Across those three major bottlenecks, one habit separates the natives from the visitors and enables them to increase throughput. The fourth bottleneck is building your own operating system for development and the tools that comprise that system: the custom eval harness, the ticket-routing agent, the code-review agent, the security review agent, and the on-call agent that triages production incidents before a human reads them. AI-native companies keep finding these small bottlenecks, removing them, and encoding them into their development operating system. They also realize that most of their development system will not last. The tool shipped last quarter is already aging. The agentic pattern from six months ago is already crude. Schumpeter's creative destruction now applies inside the company. AI-native organizations build, throw away, and rebuild without ceremony or nostalgia because the cost of building and rebuilding is low.
The fifth bottleneck will come down to how you want to work and organize your team. The observation that smaller teams can do more and move faster with AI is powerful, but it could also create significant chaos. How you decide to break up the puzzle pieces of work in your organization, align your teams, and bring it together into a masterpiece should be rethought in this new AI age. We invented waterfall development to allow large armies of software engineers to code and submit to weekly and monthly builds without breaking them. We invented two-pizza teams and agile development in the age of the internet, cloud, and microservices, paving the way for decentralized development. We have yet to reach an agreement on how best-in-class development will be done in the age of AI, so it is ours to create and own.
The long becoming is uncomfortable, but also invigorating as we build the future. Most of these struggles don't make for good headlines. That is precisely how you know it matters.
## 相关链接
- [Garry Tan reposted](https://x.com/garrytan)
- [Alfred Lin](https://x.com/Alfred_Lin)
- [@Alfred_Lin](https://x.com/Alfred_Lin)
- [24K](https://x.com/Alfred_Lin/status/2051660439667527715/analytics)
- [@tobi](https://x.com/@tobi)
- [@Shopify](https://x.com/@Shopify)
- [@LuisvonAhn](https://x.com/@LuisvonAhn)
- [@duolingo](https://x.com/@duolingo)
- [@klarnaseb](https://x.com/@klarnaseb)
- [@Klarna](https://x.com/@Klarna)
- [but is it productive or just token-maxing](https://x.com/Alfred_Lin/status/2036433182774727105)
- [@lorenc_dan](https://x.com/@lorenc_dan)
- [@chainguard_dev](https://x.com/@chainguard_dev)
- [gave us permission to publish it](https://x.com/Alfred_Lin/status/2049122878394978316)
- [five times more productive](https://x.com/Alfred_Lin/status/2031379148703408414)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:49 PM · May 5, 2026](https://x.com/Alfred_Lin/status/2051660439667527715)
- [24.1K Views](https://x.com/Alfred_Lin/status/2051660439667527715/analytics)
- [View quotes](https://x.com/Alfred_Lin/status/2051660439667527715/quotes)
---
*导出时间: 2026/5/6 12:21:15*
---
## 中文翻译
# 漫长的“成为”
**作者**：Alfred Lin
**日期**：2026-05-05T13:49:01.000Z
**来源**：[https://x.com/Alfred_Lin/status/2051660439667527715](https://x.com/Alfred_Lin/status/2051660439667527715)
---
真正的重塑，是区分一家公司能否从 AI 中获取价值的最大单一因素。
--
Shopify 的 @tobi、Duolingo 的 @LuisvonAhn 和 Klarna 的 @klarnaseb 都走过一条相似的路。一份大胆的内部备忘录变成了公开的文件。随之而来的是头条新闻。然后，几个月后，澄清或回撤紧随其后。Klarna 暂停了其招聘冻结。Duolingo 收回了关于“替代”的表述。Shopify 软化了其措辞，但没有放弃原则。我们在公开帖子和头条新闻中看到的只是冰山一角。我们看不到的是水面下的角力。在一个你并非成长于其中的范式里成为“原生”一代，这意味着什么？成为，往往比宣称要难得多。
二十年来，我们一直使用“赋能”和“原生”这两个术语来区分技术变革的采用者。云赋能意味着将现有的应用程序迁移到 AWS 上。云原生意味着从第一行代码开始就为云端而设计。这两条路径在早期看起来很相似，但在几年后却出现了巨大的分歧。
同样的鸿沟再次出现。AI 赋能的公司在同一个销售团队中添加了一个 AI 助手，并计算节省了多少封邮件。AI 原生的公司则会问：如果我们今天从零开始，我们要如何从底层向上构建每一层？
我们交谈过最先进的 AI 创始人都发现，真正的重塑（重塑你的产品、流程、工作流和公司）是区分一家公司能否从 AI 中获取价值的最大单一因素。这是愿意从第一性原理出发进行重建，将你的产品、流程、工作流和公司拆解，然后再重新组装起来。对他们来说，这是一个“重新创业”的时刻。大多数公司浅尝辄止，只是在昨天的流程之上安装一个助手，然后纳闷为什么他们的业务看起来还是老样子。
在实践中，“成为”是什么样子的？实践通常并不性感，它就像解决一连串的瓶颈。你解决了一个，限速步骤就会转移到别处。工作就是要弄清楚你当前处于哪个瓶颈，并将你的组织转移到下一个瓶颈。
第一个瓶颈是采用。人们真的在使用这些工具吗？为了回答这个问题，我们建立 Token（令牌）使用量的排行榜来鼓励采用。很快，我们看到了采用，但这是富有成效的，还是仅仅在刷 Token 量？工程经理应该如何帮助他们的团队有效采用？@chainguard_dev 的首席执行官 @lorenc_dan 最近与他的团队分享了他的“Token 规则”，并允许我们发布。他期望每位工程经理的 Token 使用量都接近其直属报告的中位数。低于中位数，领导者缺乏辅导所需的实战经验。远高于中位数，他们需要去教学，而不是囤积杠杆。这与 Token 排行榜相比，只是一个微小的、平庸的政策变更。但这正是重点。采用是文化层面的，需要领导层的引导。
一旦人们真正有效地使用了工具，第二个瓶颈就会转移到真正的工程速度上，这通过你组织的 Pull Request（拉取请求）数量来衡量。在最近的一次董事会会议上，一位首席技术官告诉我，他表现最好的 5% 到 10% 的构建者现在的生产力是一年前的五倍。中位数的构建者提高了 20%。要完成的工作是训练你团队的其余成员，让你前十分位成员的速度也能被其他人企及。
一旦工程速度提升，第三个瓶颈会再次转移。现在是产品速度和产品体验质量。工程师可以发布代码，但公司能否足够快地决定构建什么以跟上步伐？过去需要按季制定的路标现在只需要几周。拥有绝佳品味和判断力、能产生伟大产品创意的产品经理、设计师和领导者成了瓶颈。这是大多数公司停滞不前的地方。他们将工程速度扩大成一把指向错误目标的高压水枪。一旦你能快速发布任何东西，问题就变成了体验本身是否有意义的提升。
在这三个主要瓶颈中，有一个习惯将原生者与访问者区分开来，并使他们能够提高吞吐量。第四个瓶颈是构建你自己的开发操作系统以及组成该系统的工具：自定义评估工具、工单路由代理、代码审查代理、安全审查代理，以及在人工阅读之前对生产事故进行分类的值班代理。AI 原生公司不断发现这些小瓶颈，消除它们，并将其编码到他们的开发操作系统中。他们也意识到，他们的大部分开发系统都不会持久。上季度发布的工具已经老化。六个月前的智能体模式已经显得粗糙。熊彼特的创造性破坏现在适用于公司内部。AI 原生组织进行构建、丢弃和重建，没有仪式感也没有怀旧情绪，因为重建的成本很低。
第五个瓶颈将归结为你希望如何工作以及如何组织你的团队。较小的团队可以利用 AI 做更多事并移动得更快，这一观察很有力，但也可能造成巨大的混乱。你决定如何拆解组织中的工作拼图、协调团队并将其组合成杰作，应该在这个新的 AI 时代重新思考。我们发明瀑布开发是为了让庞大的软件工程师大军能够编写代码并提交到每周和每月的构建中而不至于破坏它们。在互联网、云和微服务时代，我们发明了两块披萨团队和敏捷开发，为去中心化开发铺平了道路。关于在 AI 时代一流的开发应该如何进行，我们尚未达成共识，所以这需要我们去创造和拥有。
漫长的“成为”过程是令人不适的，但也是令人振奋的，因为我们正在构建未来。这些挣扎大多上不了头条。这正是你知道它很重要的原因。
## 相关链接
- [Garry Tan 转发](https://x.com/garrytan)
- [Alfred Lin](https://x.com/Alfred_Lin)
- [@Alfred_Lin](https://x.com/Alfred_Lin)
- [24K](https://x.com/Alfred_Lin/status/2051660439667527715/analytics)
- [@tobi](https://x.com/@tobi)
- [@Shopify](https://x.com/@Shopify)
- [@LuisvonAhn](https://x.com/@LuisvonAhn)
- [@duolingo](https://x.com/@duolingo)
- [@klarnaseb](https://x.com/@klarnaseb)
- [@Klarna](https://x.com/@Klarna)
- [but is it productive or just token-maxing](https://x.com/Alfred_Lin/status/2036433182774727105)
- [@lorenc_dan](https://x.com/@lorenc_dan)
- [@chainguard_dev](https://x.com/@chainguard_dev)
- [gave us permission to publish it](https://x.com/Alfred_Lin/status/2049122878394978316)
- [five times more productive](https://x.com/Alfred_Lin/status/2031379148703408414)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [9:49 PM · May 5, 2026](https://x.com/Alfred_Lin/status/2051660439667527715)
- [24.1K Views](https://x.com/Alfred_Lin/status/2051660439667527715/analytics)
- [View quotes](https://x.com/Alfred_Lin/status/2051660439667527715/quotes)
---
*导出时间: 2026/5/6 12:21:15*