Over eight years at Facebook, I wrote roughly a million lines of code. I worked on News Feed, Groups, Messenger for Kids, and Workplace. I became a principal engineer. I know what it feels like when a company is moving fast.
In the first three months of this year, using AI coding tools, I matched that output: a million lines of production code. Eight years compressed into a quarter.
So I should be the person telling you that AI has changed everything. And it has, though not in the way the loudest voices are saying. The question that stays with me is not whether AI can build faster. That is obvious. The question is why, if that is true, the largest and most capable technology companies on Earth do not seem to be shipping ten times more product.
A product director at one of those companies answered it for me over lunch. I asked whether AI had changed her team’s pace. She laughed. “My engineers are faster,” she said. “Everything else is exactly the same speed.”
That sentence names something larger than software. For years, we assumed the bottleneck in technology was building—that if engineers could just produce faster, everything else would accelerate with them. AI has removed that bottleneck. What it has revealed beneath it is the real one: not production, but the human system that surrounds production. The coordination inside organizations. The habits and attention of users outside them. The institutional, cognitive, and social machinery through which new things must pass before they can reach the world.
We mistook the visible constraint for the binding one. Now the deeper one stands exposed.
In 2015, I built a feature at Facebook that let users overlay a template on their profile photo—a flag, a badge, a frame to show support for a cause. I prototyped it quickly, shipped it, and moved on. Then the French-flag template went live after the Paris attacks, and millions of people used it simultaneously. The system collapsed. I had designed the database with two-way graph edges: fine for a prototype, catastrophic at scale. The infrastructure team had to step in, redesign the storage on the fly, and make the edges one-way to stop the cascading failures.
Facebook learned in forty-eight hours that the feature was wildly popular. But notice what happened: the code took days. The crisis it produced—and the organizational response required to stabilize it—involved database engineers, incident-response protocols, and an architectural overhaul that no amount of faster coding would have prevented. Production was fast. Everything around production was not.
Messenger Kids taught me a different version of the same lesson. The engineering challenge of building a messaging app for children was real but solvable. What consumed the project was what lay beyond the code: a complete redesign of the account architecture to comply with COPPA, the federal children’s privacy law. Consultations with child-safety organizations. Parental-consent mechanisms that had to satisfy standards the FTC had already rejected once before. Privacy policies parsed by lawyers who understood the regulatory history.
And even after all of that, the world pushed back. Advocacy groups filed formal complaints with the FTC. A hundred child-development experts sent a public letter to Mark Zuckerberg asking him to pull the app. Senators demanded answers. Years later, the FTC alleged that Facebook still had not gotten it right.
The code shipped in months. The product took years to reach anything like stability in the world. That gap—between what engineering can produce and what institutions, regulators, and publics will accept—is the gap AI has not closed. It is also the gap most AI productivity stories skip entirely, because it is not a story about tools. It is a story about legitimacy.
A feature that takes a month to ship at a large company does not take a month because an engineer spends four weeks typing. It takes a month because a company must simultaneously clear product review, design review, data instrumentation, operations readiness, legal sign-off across jurisdictions, security audit, marketing, press coordination, and documentation. AI has compressed the first step—writing the code—dramatically. It has not compressed the rest. And the rest was always where most of the time actually went.
When Microsoft’s Recall feature was technically ready in mid-2024, security researchers raised enough concerns that the company pulled it back and spent months rebuilding its architecture. The engineering was finished. What was not ready was the institutional confidence to ship it. That pattern—built, but not shippable—is now the norm, not the exception. And it will become more common as AI makes building faster while leaving everything else unchanged.
But there is a second constraint, and it operates outside the company entirely. It lives in the habits and cognition of users.
In 2013, Facebook unveiled a major News Feed redesign: larger images, cleaner layout, new sub-feeds for different content types. It tested well in mockups. It looked modern. And when the company began rolling it out, engagement dropped. People spent less time on the site. They did not navigate to the places they used to navigate. Facebook stopped the rollout and, a year later, shipped a far more conservative version instead.
The redesign was not bad design. It was too much change, too fast, for a population of users whose habits had been trained by the old layout. I was there. I watched hundreds of millions of people vote with their behavior against a product that was, by most objective measures, better than what it replaced.
This is rooted in cognition, habit, and the limits of human attention. Working memory holds roughly three to five items at a time. Habit formation takes weeks to months. Status quo bias—the measurable pull toward the current state of things—is one of the most replicated findings in behavioral economics. These are not preferences a better product can simply override. They are constraints that dictate how fast a product can change before users start to disengage.
And they lead to a conclusion the technology industry has been reluctant to state plainly: mature software is no longer constrained by what can be built. It is constrained by what can be integrated into a user’s existing life without triggering resistance, confusion, or abandonment.
Research on feature fatigue has found that capability-rich products attract buyers but frustrate users: more features increase initial appeal while degrading the long-term experience. Industry data tells the same story. In a typical software product, a small fraction of features drives the vast majority of daily use. The rest is surface area that exists without being inhabited. Shipping ten new features when one would do is not generosity. It is noise.
I nearly pursued a Ph.D. in human-computer interaction. I had housing lined up at the University of Washington and a research assistantship confirmed. I stayed at Facebook because I liked building more than writing papers. But the central insight of those HCI courses has never left me: interfaces are not neutral surfaces. They are relationships between a system and a person’s habits, memory, and attention. Change an interface and you are asking a human being to revise a piece of daily life. There is a speed limit on how often you can make that request before the person stops cooperating.
I should be honest about where this argument does and does not apply. Internal tools, developer infrastructure, data pipelines—products with small technical audiences and low regulatory exposure—can move much faster with AI, and some already are. The coordination overhead is lighter, the user base more tolerant, the cost of imperfection lower.
The argument applies to the products that dominate public life: the large consumer and enterprise platforms where habits run deep, regulations are layered, and the consequences of a bad launch cascade through press, politics, and user trust. These are the products AI evangelists most often point to when they wonder why everything has not accelerated. The answer is that those products were never bottlenecked on code. They were bottlenecked on everything code gets wrapped inside before it can reach a human being.
There are early signs of a structural response. Companies are building protocols for AI systems to connect directly to tools and data, bypassing graphical interfaces entirely—a move toward AI intermediaries that absorb complexity on a user’s behalf. That direction is promising. It is also, if the human-factors literature is any guide, dangerous in its own way. When people delegate to automated systems, they stop monitoring them, and the failure modes of inattention are different from the failure modes of overload but no less consequential.
I do not know what the winning design looks like. What I do know is what the problem looks like, because I have spent my career on both sides of it: as the person who could build almost anything, and as the person who watched almost everything slow down on its way to the world.
I used to think the bottleneck was engineering. I was the engineer. I was wrong. The bottleneck was always the human system surrounding the engineering—the coordination, the legitimacy, the habits, the attention. AI has not solved that. What it has done is something more disorienting: it has made the real bottleneck visible by eliminating the one we were used to.
Our tools have gotten faster. We have not. And the question this era has to answer is not how to build more, but how to close the widening gap between what our machines can create and what our institutions and minds can absorb.