AI-native means rewriting the organization
In 1882 Edison’s Pearl Street Station began supplying power in New York. By rights the electric motor should have revolutionized the factory. Yet for decades afterwards American manufacturing productivity showed none of the leap people expected.
The economic historian Paul David explained why in his well-known 1990 paper, “The Dynamo and the Computer.” Early factories adopted electricity by swapping their steam engine for one large electric motor and leaving everything else alone: the line shaft still ran the length of the ceiling, and belts still dropped from it to drive every machine. The power source changed; the way the factory was organized did not. Around 1900, electric motors provided less than 5% of the mechanical drive in American factories. Even by the early 1920s they had only just passed half.
The real change came when factories were redesigned. Each machine got its own small motor, the shafts and belts disappeared, and plants could be laid out by process rather than by drive shaft — single-story, brighter, more flexible. Only after that did the productivity surge appear in the statistics.
In 1987 the economist Robert Solow wrote a line that has been quoted ever since: “You can see the computer age everywhere but in the productivity statistics.” It could be said again today, almost word for word.
Today’s line shafts and belts
Much of the AI inside companies today is still at the “swap the steam engine for a motor” stage.
McKinsey’s 2025 global survey found that nearly nine in ten respondents’ organizations use AI regularly, yet the “high performers” who attribute 5% or more of EBIT to AI make up only about 6%. Of all the factors the survey tested, fundamentally redesigning workflows was among the strongest contributors to business impact.
A report from MIT’s Project NANDA the same year was blunter: behind $30–40 billion of enterprise spending on generative AI, 95% of organizations saw no measurable return. The report located the problem not mainly in model quality but in brittle workflows, systems that cannot learn from feedback, and misalignment with day-to-day operations. Its methodology is disputed, and the authors themselves call it directional. But anyone who has tried to roll out AI inside a company will probably recognize those causes.
Buy the tools, open the accounts, run a few pilots — and find that nothing has changed. These are today’s line shafts and belts.
Making coding faster is not enough
My own view comes from an AI engineering team I have led over the past year.
We rebuilt the development process around “large models plus coding agents” and brought one system’s delivery cycle down from weeks to days. But if you ask where the biggest change came from, the answer is not that code got written faster.
Amdahl’s law explains why. Suppose coding is 40% of the delivery cycle, and the rest is clarifying requirements, waiting, review, testing, integration and release. Then even if coding becomes ten times faster, delivery as a whole is only about 1.56 times faster. Even if coding took no time at all, delivery could be at most 1.67 times faster.
So what really has to change is the other 60%. Almost everything we did afterwards changed the process; the tools barely changed. Requirements had to be written in a form an agent can understand and verify, with acceptance criteria written before any work began. Batches got smaller, each delivering a piece that can be verified on its own. Review shifted from reading code line by line to asking whether the design is sound and whether tests cover the critical paths. Role boundaries moved too: product managers came closer to the code, and engineers spent more time on architecture and verification.
It reminds me of building Personal DevCloud at Huawei. A new engineer used to need 7 to 10 days from joining to their first commit; we brought that down to 10 minutes. We did not buy a faster compiler. We redesigned, end to end, the chain of hand-offs and waiting — requesting an environment, granting permissions, configuring the pipeline. There were no large models then, but the principle is identical: the ceiling on efficiency is usually set by hand-offs and waiting, and rarely by how fast any one person works.
Across the business
Beyond engineering — in design, e-commerce operations, content production and supply chain — I see the same pattern.
Generate images and short videos with AI at scale and production can become many times more efficient. Very soon, though, the bottleneck moves: who enforces brand guidelines, how assets get reviewed, which content performs, and how that feedback returns to the next round of generation. If review still moves at the old pace, one asset at a time, all the extra capacity simply piles up in front of the review queue.
Supply chain is the same. However good the demand forecast, if production plans are still set at a monthly meeting, accuracy goes unused. In building intelligent scheduling, we spent far more time connecting data and changing how decisions are made than on the model itself.
What AI amplifies first is usually the bottleneck an organization already has.
Where the rewrite begins
If I were to offer one piece of advice to a company that wants to become AI-native, it would be: start with a complete business process, not with a tool.
Pick a process that matters to the business and runs end to end, and redesign it from start to finish: which steps AI can take on, which must stay with people, how work passes between them, and how results are measured. The measures should be end to end — time from request to release, time from order to delivery — rather than “lines of code generated by AI” or “number of calls.”
Then let the organization itself change. Roles, team boundaries and how performance is evaluated all need to move with it. This is the hardest step, because it touches people.
Finally, capture what you accumulate along the way: data, standards, evaluation methods and reusable processes. These are a company’s real assets in the AI era. Models can be swapped; these do not go out of date.
A closing thought
Electrification took about forty years from invention to showing up in productivity. We probably won’t get that long; competition will force the process to move much faster. But the order is likely to be the same: first the tools, then the processes, and finally the organization.
The people who first redrew their factories went on to define twentieth-century manufacturing.
References
- Paul A. David, “The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox”, American Economic Review, 80(2), 1990
- Robert M. Solow, “We’d Better Watch Out”, New York Times Book Review, July 12, 1987
- McKinsey & Company, The State of AI in 2025
- MIT Project NANDA, The GenAI Divide: State of AI in Business 2025