Tobi Lütke at Shopify, Luis von Ahn at Duolingo, and Sebastian Siemiatkowski 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? Dan Lorenc, CEO of Chainguard, 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.