Andrej Karpathy published a gist last week describing a pattern he calls “LLM Wiki.” The idea: an LLM that builds and maintains a personal knowledge base — interlinked markdown files, structured summaries, cross-references updated automatically. You curate the sources and ask the questions. The LLM does the bookkeeping. Five thousand stars in four days.

His key analogy: “Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.”

It’s a sharp proposal. It’s also one that a German sociologist named Niklas Luhmann would have recognized immediately — from the system of 90,000 handwritten index cards he maintained for forty-five years, starting in 1953. Luhmann’s Zettelkasten is similar to what Karpathy describes: interlinked notes, cross-references, a persistent structure where knowledge compounds over time. He produced seventy books from it. The architecture wasn’t the hard part. The filing was.

Between Luhmann and Karpathy, an entire community spent decades working on this problem — Vannevar Bush’s Memex in 1945, the tools-for-thought movement, Roam Research and Obsidian, Tiago Forte’s Building a Second Brain in 2022. Karpathy walked into a room that’s been full for decades. But he brought something new through the door.

What he got right

The thing that kills every personal knowledge system isn’t the architecture — it’s the upkeep. Updating cross-references when your thinking evolves, keeping summaries current, noticing when something you wrote six months ago now contradicts what you learned last week. Most people who start a second brain quit within months. The bookkeeping grows faster than the value, and one day you stop opening the app.

Karpathy’s solution — hand the maintenance to an LLM — is pragmatic. If you were never going to build the habit yourself, having an agent build a compounding knowledge base for you is vastly better than having nothing at all.

But his framing reveals an assumption: “You never write the wiki yourself.” The human curates sources and asks questions. The LLM writes, files, and maintains. You read it; the LLM writes it.

For people starting from zero, that division makes sense. But there’s another group — people who already built the habit, who already have a second brain they’ve been writing in for years. For them, the opportunity looks different.

The shared surface

I’ve kept a second brain in Obsidian for nearly five years — around 2,400 notes, wikilinked together, semantically searchable. I started building it before AI entered the picture, for the same reason people have always built these systems: I wanted to externalize my thinking so I could work with it.

When I read Karpathy’s proposal, I recognized the architecture immediately — but from the other direction. He was asking how to give an agent persistent memory. I’d already answered that question by accident, by handing the agent the memory system I’d built for myself.

The move wasn’t “LLM builds a wiki.” It was “come work where I already work.”

Karpathy’s framing is that you read the wiki and the LLM writes it. In my vault, we both write to it. The agent logs entries to my notes, and I read them the next morning. I update a project file with notes from a call, and the agent picks up the new context in its next session without my having to explain anything. When a family member emails an update about a medical appointment, the agent processes it into my file in the vault — the same file I open when I’m at the next appointment.

The project file carries the chronology — who did what, when, what’s next — and both of us contribute to it. Neither of us has to re-explain context over chat because the context lives in the notes we’re both already using.

This only works because the vault is my actual workspace, not a reference library I consult occasionally. If the agent wrote to a separate folder I never opened — the way most AI memory systems work — I’d never see what it got wrong, never catch a stale fact or a misunderstood priority. The errors would compile quietly into the agent’s model of my life, looking authoritative. A shared brain only stays honest when both parties are working in it.

What changes

A wiki the LLM maintains for you is an archive — historical and well-organized. But it’s the LLM’s understanding of your world, written in the LLM’s voice, looking backward. You visit it when you have a question about what happened.

A vault you both work in is a whiteboard. I start my morning and the agent already knows what I was working on yesterday, what’s blocked, what changed overnight — not because I briefed it, but because it was there. I don’t re-explain context. I don’t paste in background. I pick up a thread and the agent picks up the other end — like a teammate who was in the room yesterday and will be in the room tomorrow.

There was a website in the early 2000s called Threadless where anyone could submit a t-shirt design. The community voted, and the winners got printed. That was the whole thing.

But the feeling was something else. You had an idea on Tuesday and strangers were wearing it by next month. Glenn Jones, a graphic designer from New Zealand, won 21 times and eventually quit his fifteen-year career as a creative director to sell his own designs. “I didn’t want to be left wondering,” he said. The prize money wasn’t the point. Seeing his design on a shirt someone across the world had chosen to wear was.

The barrier between “I have an idea” and “I made a thing” had collapsed, and people poured through.

When Apple started shipping GarageBand on every new Mac in 2004, the same thing happened to music. Anyone who wanted to could lay down a beat and mix a track without booking studio time. Most people who opened it made one song, played it for a friend, and never opened it again. Nobody cared. The point was the jolt of I can do this.

Grimes, a university student in Montreal, got a friend to show her the software and started making what she later called “terrible, terrible songs“ using the built-in synths. She kept going. A couple years later she recorded Visions in her apartment over three weeks, still on GarageBand, and won a Juno Award. Then she was headlining festivals.

Steve Lacy was 17 and still in high school in Compton when he plugged a guitar into his iPhone and started recording parts for The Internet’s Ego Death on the GarageBand app. The album got a Grammy nomination, and Lacy kept recording on that phone long enough for his single “Bad Habit“ to hit number one on the Billboard Hot 100 a few years later.

AI coding tools are in this phase right now. Every week my feed fills with screenshots of apps someone built in an afternoon — a habit tracker, a recipe tool, a game their kid wanted. I’ve been building them myself. Not because I need another app, but because I can, and that feeling hasn’t gotten old yet. “I made this.” Same jolt. Different canvas.

The fork

Here’s the pattern after the rush. Millions of people felt that jolt of possibility when they first opened GarageBand, and most of them never opened it again. That’s not failure, and it’s not a waste. But for most people the rush was about the novelty of the tool, not the beginning of a new identity.

For some people, though, the rush turns out to be a discovery. Grimes and Lacy didn’t know they were musicians until the barrier dropped and they walked through it. The tool didn’t give them talent. It gave them a way to discover their art. What separated them from the millions who moved on wasn’t discipline or seriousness. It was recognition, a feeling that this new thing they could suddenly do was somehow already theirs.

The on-ramp

Most of the apps people are building right now will stop working when the dependencies break. That’s fine. The rush was never really about the app. But somewhere in that flood, someone is finding out they’re a builder — month one of something nobody sees coming.

The Threadless shirt is in the back of the closet. The GarageBand track never got a second listen. And Steve Lacy’s cracked iPhone — the one he used to record on GarageBand as a teenager — is on display at the Smithsonian. Not every GarageBand project ends up in a museum. But you can’t get to the museum without the project.

I was writing a skill file for Claude Code when a line in Anthropic’s documentation stopped me. It said to explain why the skill was needed — not just what it should do, but why it existed in the first place.

I’d been writing prompts as step-by-step procedures — edge cases spelled out, fallback behaviors for when things went wrong. The kind of detail you give someone when you don’t trust them to figure it out on their own.

But here was the documentation saying: just tell it why.

I knew this moment. I’d been on the other side of it before — not with software.

Kate

I hired Kate (not her real name) straight out of college. Computer science degree, disciplined, the kind of work ethic where you’d assign something Friday afternoon and find it done by Monday morning. But she needed the task spelled out — not because she wasn’t smart, but because she was new. No different than I had been at her age. So I gave her detailed specs, walked through edge cases, flagged where things could go wrong. She executed well within those boundaries, and the boundaries were tight.

Anyone who’s managed people knows what happened next. The instructions loosened. Her questions changed — not “how should I do this?” but “are we solving the right problem?” The projects changed too: early on it was “implement this feature, here are the requirements,” and later it was “this part of the system isn’t working for users — figure out why.”

At some point my 1:1s with Kate stopped being about what to do and started being about why we were doing it. Context, priorities, the business problem behind the technical one. I was managing her the way my best managers had managed me — with intent, not instruction.

And then Kate started managing others. She onboarded new hires with the same careful detail I’d once given her — spelling out the specs, walking through edge cases, flagging where things could go wrong. The promotion, when it came, was a formality. She’d been operating at that level for months. We just hadn’t updated the title yet.

Claude

I started working with Claude early on, back when the model couldn’t stay focused for long. Its context window was small and it would lose the thread of a conversation halfway through. So I learned to spell things out. I’d provide examples of the output I wanted so it could mimic the pattern. I’d write “let’s think step by step” because it couldn’t reason unless you told it to. I’d open with “act as a senior software engineer” to narrow the field of possible responses. The boundaries were tight — just like they’d been with Kate. And like Kate, it executed well within them.

Anyone who’s been using these tools knows what happened next. The instructions loosened. “Let’s think step by step” — the technique that defined an era of prompting, the thing people paid $335,000 a year to get right — now barely improves performance; on some models it actually hurts. The model internalized the technique the way Kate internalized project management. It just does it now, without being told. My prompts changed the way Kate’s questions had changed — less “here’s exactly what to do” and more “here’s what’s going wrong and why it matters.”

And then Claude started managing others. I used to open multiple sessions myself — one for writing, one for review, one for research. Now Claude spins up subagents on its own, delegating work with care.

The Recognition

Since December, I find myself in new territory with the models. The latest step up feels like a promotion, but like with Kate, it’s taking some reorientation.

With Kate, the hard part wasn’t her readiness — it was mine. I kept handing her detailed specs after she’d outgrown them, still seeing the new hire I’d onboarded instead of the senior engineer she’d become. The unlock wasn’t just her leveling up. It was me noticing that she had.

I went back to my skill file. This time, instead of spelling out procedures and edge cases, I found myself doing what every good manager eventually learns to do: starting with the why. What problem I was trying to solve. What good looked like. The kind of context you give someone when you trust them to figure out the how.

Ethan Mollick wrote in 2023 that we should treat AI like an intern. It was good advice at the time. But interns don’t stay interns.

Kate went on to become a director. She’s worked at companies I’ve only read about, led teams bigger than any I’ve built. If I’m being honest, I could see myself working for her.

At the foot of Mount Fuji, robots build other robots in total darkness. No lights — the machines don’t need to see. No heating, no air conditioning either. “Not only is it lights-out,” a FANUC executive once explained, “we turn off the air conditioning and heat too.” The yellow arms move with precision through pitch black, producing roughly fifty new robots every twenty-four hours, sometimes running unsupervised for weeks at a stretch.

The industry calls this a “dark factory” — not metaphorically. It’s literally dark because humans aren’t there, and robots don’t care.

In January 2026, entrepreneur Dan Shapiro published a framework mapping AI-assisted software development onto five levels — borrowing the concept directly from FANUC’s lightless factory floor. At one end, AI is “spicy autocomplete.” At the other, it’s a dark factory: specs go in, working software comes out, no human writes or reviews a line of code.

At least one team claims to already be there.

Level Five

What does a dark factory look like when the factory floor is an IDE?

Right now, most teams using AI to write software still keep the lights on. A developer prompts an AI to generate a function, reads what comes back, adjusts the prompt, tries again. Or an AI agent writes a pull request and a human reviews it — scanning the diff, checking the logic, clicking approve. The AI does the typing, but a human is always in the room, either steering or inspecting. In Shapiro’s framework, this is Level 2 or 3. The lights are dimmed, maybe, but someone is always watching.

Last July, StrongDM’s CTO Justin McCarthy formed a three-person team and turned the lights off. Their charter had two rules. The first: code must not be written by humans. The second: code must not be reviewed by humans. Not “humans can review if they want to.” Must not. The rules aren’t constraints born from laziness — they’re a forcing function. If no human is allowed to touch the code, you have to solve every quality problem some other way.

By the time Simon Willison visited their lab in October, three people had produced thirty-two thousand lines of production software without a single line written or reviewed by a human hand. Willison watched a demo where a developer had a complex application running on localhost — something that looked like Google Sheets but with real backend logic, a working frontend, actual functionality. The entire thing had been produced by AI agents operating against human-defined specifications. Willison called it “the most ambitious form of AI-assisted software development I’ve seen yet.”

But the ambition raises an obvious question. If no human writes the code and no human reviews it, how do you know it works?

All Models Are Wrong

McCarthy’s team answered that question by building a world.

Their software talks to Slack, Jira, Okta, Google Docs in production — so they built replicas of all of them. Not mocks that return canned responses, but stateful behavioral clones. Delete a Slack channel in the replica, and it stays deleted; the next time your code tries to post there, it gets the same “channel not found” error it would get from the real thing. Change a user’s role in the Okta replica, and five minutes later the Jira replica blocks their access, just like the real services would.

The AI agents write code, deploy it into this digital universe, and see what happens. They run thousands of scenarios — end-to-end user stories that the team keeps hidden from the coding agents, like holdout sets in machine learning. The agents don’t know what the tests are. They have to bumble through the simulated world, interact with the replicas, and iterate until the software actually works against conditions it wasn’t specifically told to expect. When something breaks, the agents adjust and try again. The feedback comes from the universe itself.

Willison saw why this mattered. Building a high-fidelity clone of a complex SaaS application, he wrote, “was always possible, but never economically feasible” — until LLMs made it cheap enough to build at scale. But strip away the branding and what McCarthy’s team has built is integration testing. Thorough, high-fidelity, running at a scale that wasn’t economical before — but integration testing all the same.

And integration testing has a problem that no amount of scale solves. The tests are only as good as the model they run against. The statistician George Box put it simply in 1987: “All models are wrong, but some are useful.” McCarthy’s digital universe is a model — a good one, good enough to ship thirty-two thousand lines of production code on. But the map is not the territory. When the real Slack changes how it handles rate limits, or Okta tweaks an authentication flow, the model doesn’t know until something updates it. And in that gap between the model and reality, the dark factory is running full speed, producing code that works perfectly in a world that no longer quite exists.

The dream of full automation has crashed into the gap between model and reality before — and the most famous case left a billionaire building cars by hand in a tent.

The Tent

In 2016, Elon Musk described his vision for the Tesla Model 3 production line as “the machine that builds the machine.” The internal codename was the Alien Dreadnought — a factory so automated it would look inhuman. Robots would handle everything. The line would move so fast that air resistance on the parts would become a design constraint. Humans would only slow it down.

By 2018, the Alien Dreadnought was in ruins. Musk had automated tasks that didn’t need automating — complex conveyor systems for jobs a person could do in seconds, robotic arms trying to handle parts that varied just enough to jam the line. The Model 3 was supposed to roll off the line at five thousand cars a week. It was producing a fraction of that, and the company was burning through cash at an unsustainable rate.

So Musk did something that would have been unthinkable two years earlier. In three weeks, his team erected a massive temporary structure — a tent, officially called GA4 — in the Fremont factory parking lot. Inside, humans assembled cars by hand. Not robots. People, working around the clock, doing the thing the perfect automated factory couldn’t do.

“Yes, excessive automation at Tesla was a mistake,” Musk tweeted on April 13, 2018. “To be precise, my mistake. Humans are underrated.”

It’s the kind of story that gets told as a cautionary tale — the hubris of full automation, the return of the human. But that’s not where the story ends. Tesla didn’t abandon the dream. They rebuilt the line incrementally, automating where it made sense, keeping humans where it didn’t. The Fremont factory today produces roughly half a million vehicles a year, far more automated than the tent but far less than the Alien Dreadnought imagined. Musk didn’t skip to lights-out in one leap. He got there — or closer to there — by working his way along the curve.

The tent was a point on the curve.

The Poorly Lit Factory

Everybody’s building toward the dark factory now. Cursor says thirty-five percent of its own merged pull requests come from autonomous agents; Cognition claims their AI developer Devin merges sixty-seven percent of its PRs. But companies selling AI tools have an interest in claiming the factory is going dark — and independent testing puts Devin’s success rate on open-ended tasks closer to fifteen percent. That gap between vendor stats and outside measurement tells you something about where we actually are. Then again, companies with no AI product to sell are seeing real results too: Stripe’s internal system produces over a thousand agent-written PRs a week — though every one of them is still reviewed by a human before it merges.

Nobody’s fully dark yet. Most teams are somewhere between Shapiro’s Level 2 and Level 4 — the lights dimmed but not off, humans still in the loop at some point in the chain. McCarthy’s team at StrongDM may be the furthest along, and even they depend on a model of the world that’s only as current as its last update.

Maybe that’s fine. Maybe the dark factory was always an asymptote — a limit we approach but never quite reach. FANUC still has humans maintaining the lines at Mount Fuji. Tesla rebuilt toward automation incrementally after the tent, and Fremont today is neither the Alien Dreadnought nor the parking lot.

The thing that matters is a factory that works. A dark factory that fails when the parts come in slightly different than the simulation predicted isn’t useful — no matter how impressive the automation looks in a demo. And if keeping a few lights on is what makes it run, then a poorly lit factory is the better factory.

There will always be people trying to turn that last light off. That’s fine — that’s how the asymptote moves. But the work worth watching is what’s getting built while the lights are still on.

In 1865, the German chemist August Kekulé was stuck. He’d spent years trying to work out the structure of benzene — a molecule that chemists knew the ingredients of but couldn’t figure out the shape. Carbon and hydrogen atoms in the right quantities, but no arrangement anyone proposed could explain how they held together. Kekulé had been turning the problem over for so long it followed him into his sleep.

As the story goes, one evening he dozed off by the fire and dreamed of atoms dancing and twisting into chains. Then one of the chains curled around and seized its own tail — a serpent forming a ring. He woke up and spent the rest of the night working out the implications. Benzene wasn’t a chain. It was a ring. The ouroboros — the ancient image of a serpent eating itself — had revealed one of the foundational structures of organic chemistry.

It’s a great story, and it’s the kind of story we love to tell about problem-solving — the answer arrives in a flash, delivered by the subconscious as a gift, genius as something that happens to you rather than something you grind out. We conveniently forget that Kekulé had been grinding for years before the dream arrived.

The common criticism of AI follows a similar logic. AI is just autocomplete — it can remix what it’s seen, predict the next likely word, maybe even sound convincing, but it can’t solve anything new. It doesn’t have insight. It can’t have that Kekulé moment where the pieces suddenly fall into place. It’s a pattern-matching engine, not a mind that can discover.

It’s a reasonable position. But last week, two things happened that made me wonder whether we’ve been too sure about what “discovery” requires.

The Mathematician

Donald Knuth is not the kind of person who gets excited about AI. A Turing Award winner and the author of The Art of Computer Programming — the textbook I used in my own computer science program in college, and still the definitive reference in the field — Knuth is often called the father of algorithm analysis. He has been openly skeptical about the productivity of large language models.

So when Knuth published a note on Stanford’s website last week, what he described sounded almost like a Kekulé moment — for a machine.

Knuth had been stuck for weeks on an open problem from his textbook: finding paths through a three-dimensional grid of points where each path visits every point exactly once, returns to its start, and shares no connections with the other paths. He’d solved it for small grids but couldn’t crack the general case. His friend fed the problem to Claude, Anthropic’s AI model, and what came back wasn’t brute force. Claude recognized that the grid had a deeper mathematical structure — a kind of symmetry that Knuth’s original framing hadn’t exploited. It invented a way to decompose the grid into layers, then built serpentine patterns that wove through each layer in a way that satisfied all the constraints simultaneously. It reframed the problem, then solved the reframed version.

Knuth verified the mathematics himself and called the approach “remarkably creative.” Not just correct — creative. “It seems that I’ll have to revise my opinions about ‘generative AI’ one of these days,” he wrote.

Now here’s the thing: Claude didn’t arrive at that solution in a flash. It worked through the problem over about an hour, trying different approaches, hitting dead ends, adjusting its framing each time. The structural insight that cracked the problem — the decomposition into layers, the serpentine patterns — emerged from that process of trying and revising. Not randomly, but not in a single leap either. More like a mind circling a problem, getting closer with each pass, until the right angle of approach comes into focus.

Which sounds a lot like what Kekulé’s subconscious was probably doing while he slept — running variations on carbon structures, testing arrangements against what he knew about molecular bonding, until one arrangement clicked and surfaced as a dream about a serpent.

The Engineer

The same week, Andrej Karpathy — a founding member of OpenAI and former head of AI at Tesla — ran a different experiment.

Karpathy maintains nanochat, an open-source project for training small language models from scratch. Think of it as a workbench for building AI — minimal, transparent, designed for tinkering. He’d spent months hand-tuning the system’s internal settings to squeeze out better performance, and he thought the project was well-optimized.

Then he gave an AI agent his code with a simple instruction — make it better — and left it running for two days.

What came back wasn’t just a list of minor tweaks. The agent noticed that a key part of the model’s attention mechanism was missing a component, making it too diffuse — a subtle architectural oversight, not an obvious bug. It found that certain parts of the model needed regularization Karpathy hadn’t applied, that settings he’d forgotten to tune were working against each other, and that the initialization values were off. Twenty real improvements in all, each one something Karpathy — after months of manual work — had missed.

Stacked together, they produced an 11% gain on the project’s key benchmark. The commit message reads: “All of these improvements were developed by Claude running autonomously. I didn’t touch anything — incredible.”

“I am mildly surprised,” Karpathy wrote, “that my very first naive attempt already worked this well on top of what I thought was already a fairly manually well-tuned project.” From Karpathy, “mildly surprised” is the equivalent of shock.

But there’s something in the Karpathy case that goes beyond the Knuth story. Knuth’s problem was mathematics — AI solving a puzzle for humans. Karpathy’s problem was AI itself. An AI agent improving the process by which AI gets built. The improvements it found will feed into the next generation of models, which will be better at finding the next round of improvements.

“All LLM frontier labs will do this,” Karpathy wrote. “It’s the final boss battle.”

The Serpent Eats Its Tail

I argued a while back that what we call creativity is really search through a space of possibilities — and that the line between searching and creating is blurrier than we’d like to admit. Knuth’s case and Karpathy’s case didn’t settle that question, but they sharpened it. When an AI reframes a problem that stumped a Turing Award winner, or spots architectural flaws that one of the world’s best engineers missed, something is happening that doesn’t fit neatly into the “just autocomplete” box.

The Karpathy case is the one I keep thinking about, because of where it points. When AI solves a math problem, it’s doing something for us. When AI improves the system that builds AI — and those improvements feed into the next round — the loop starts to close. I wrote a few months ago about early signs of this loop forming. Karpathy’s result suggests it’s forming faster than expected. And once an AI that improves AI training produces a better AI that’s even better at improving AI training — well, that’s the serpent eating its own tail. Kekulé would recognize the shape.

Related

The Theodosian Walls protected Constantinople for over a thousand years. Built in the fifth century, they were a triple line of fortification — an outer wall, an inner wall rising forty feet, and a moat — stretching four miles across the only land approach to the city. Armies came and broke against them for a millennium: Arab sieges, Bulgar assaults, Rus invasions, even the Fourth Crusade. The walls held. Siege after siege, century after century, the engineering held.

In April 1453, the Ottoman sultan Mehmed II positioned a new kind of weapon outside those walls — a massive bronze cannon called the Basilica, large enough that its stone projectiles could shatter sections of wall with a single shot. The bombardment went on for weeks, blasting the fortifications chunk by chunk into rubble. Defenders scrambled to patch the breaches each night with earth and timber, but by late May the city had fallen. Walls that had endured a thousand years of siege were undone in less than two months.

The walls hadn’t gotten weaker. The nature of the attack had changed. A technology had arrived that made the sheer effort of building thick, tall stone fortifications irrelevant — not because the walls were poorly constructed, but because they were brittle against a force they were never designed to absorb.

Something similar is playing out in software right now.

The Wall Was Effort

Some of the most durable business models in software aren’t built on patents or trade secrets. They’re built on effort — engineering complexity so deep that replicating it is, for all practical purposes, not worth attempting.

Consider Vercel and Next.js. Vercel gives away the framework for free. It’s open source — anyone can read the code, fork it, build with it. The business isn’t the framework. The business is the deployment platform, and the moat is how tightly the two are coupled. Routing, middleware, server-side rendering, image optimization — all of it works best, and in some cases only, on Vercel’s infrastructure. The framework and the platform are stitched together through years of engineering, and that stitching is what makes it hard to leave.

The same pattern shows up across the industry. Microsoft’s Office formats are technically public — the .docx specification runs thousands of pages — but Google Docs and LibreOffice have spent years trying to render them faithfully, with interoperability that’s still imperfect. Adobe’s PDF spec is an open ISO standard, and yet most third-party viewers choke on edge cases that Adobe handles effortlessly. QuickBooks has decades of tax rules and jurisdiction-specific payroll logic baked into its codebase. In each case, the moat isn’t secrecy — the specifications are available, the code is sometimes even open source. The moat is the accumulated engineering effort required to match it.

The effort to replicate the coupling was the wall. Everyone could see it. Nobody could afford to climb it.

The Clean Room

Climbing an effort-wall through reimplementation is an old playbook. In 1982, Compaq wanted to build a computer compatible with the IBM PC, but IBM’s moat was its BIOS — the firmware that made a PC an IBM PC. Compaq couldn’t copy it. So they reverse-engineered it in a clean room: one team disassembled IBM’s BIOS and documented every function call, every interrupt, every timing behavior, stripping it down to pure specification. A second team, completely isolated from the first, rebuilt the BIOS from scratch using only those specs. Nine months. $1 million. And it worked — Compaq sold $150 million worth of PCs in their first year and broke IBM’s lock on the personal computer industry.

The clean room works. It’s just always been expensive enough that only the most determined competitors attempt it.

$1,100

Cloudflare had been one of those determined competitors. A project called OpenNext reverse-engineered Next.js’s build output to make it deployable on other platforms, but the approach was fragile — a game of catch-up that broke whenever Vercel changed something upstream. Cloudflare tried a ground-up reimplementation of the Next.js API themselves and failed. As they later put it, “a project like this would normally take a team of engineers months, if not years.”

Then, on the evening of February 13th, 2026, an engineering manager at Cloudflare opened Claude Code and started again — rebuilding Next.js from scratch as a reimplementation of its API, built on Vite.

By the end of that first night, both the Pages Router and App Router had basic server-side rendering, middleware, server actions, and streaming working. Within three days the project could deploy to Cloudflare Workers with full client hydration, and by the end of the week it covered 94% of the Next.js 16 API surface, backed by 1,700 unit tests and 380 end-to-end tests.

One person. One week. $1,100 in API tokens.

The project is called vinext, and it reimplements the full surface — routing, server rendering, React Server Components, middleware, caching, static export.

Cloudflare was careful to note the conditions that made this possible: “All of those things had to be true at the same time — well-documented target API, comprehensive test suite, solid build tool underneath, and a model that could actually handle the complexity.” This wasn’t just “point an AI at code and press go.” It required a clear target, a way to verify correctness, and a human providing architecture and direction across more than 800 sessions.

The reaction was swift. Vercel’s CEO disclosed seven security vulnerabilities in the project. Critics coined a term for it — “slop fork” — a replication built by AI that’s rough, incomplete, not ready for production. And that’s probably fair today. vinext is experimental, and 94% coverage still leaves real gaps. But even an imperfect replication changes things, because the threat doesn’t have to succeed to make people rethink their defenses. Compaq’s clean room cost $1 million (in 1980s dollars) and nine months. Cloudflare’s cost $1,100 and a week. Even if vinext never ships to production, that price difference is hard to unsee.

After the Walls

After Constantinople fell, word spread across Europe. Commanders in fortified cities everywhere understood what had happened — a weapon had arrived that rendered their defenses, built over generations, suddenly uncertain. Some began redesigning, lowering their walls, thickening them, angling the stone to deflect rather than absorb. Others reinforced what they had and hoped. Nobody knew yet what the right answer looked like.

There are a lot of companies sitting inside software fortifications right now, watching what happened to Vercel’s wall and wondering about their own. When tldraw’s founder joked about moving test files to a private repository to prevent AI replication, the post went viral — not because of the proposal, but because of how plausible the threat felt.

The old walls are still standing. But everyone can hear the cannon.

Why does Luke Skywalker bring R2-D2?

You remember Star Wars, right? The final scene where the rebellion sends fighter pilots to attack the Death Star. Every X-wing has onboard systems. The ship can fly itself well enough. But Luke and the other pilots bring their own droids. Why?

Luke doesn’t want a generic autopilot — he wants his droid, the one that knows how he flies, what he’s been through, what he’s likely to do next. R2-D2 doesn’t come with the plane. R2-D2 comes with Luke. Ship to ship, mission to mission, the relationship travels.

Last week I wrote about a version of this arriving on the web — WebMCP, a new browser standard that lets you bring your own AI agent into any website. Your copilot in someone else’s cockpit.

But plugging in is one thing. Working together inside is another. If R2 silently reroutes power and Luke doesn’t notice until the shields drop, that’s not collaboration — that’s a surprise. If Luke has to keep asking what R2 just did, they’re not flying together — they’re having a conversation about flying, which is slower and worse. The droid and the pilot need a shared way of working — an interface where every action is visible and every move makes sense to both.

That’s exactly where the web is now. WebMCP solves the plugging-in problem. Nobody has designed the cockpit for two yet.

Your Droid, My Cockpit

Consider a real estate site. Today, if the site is ambitious, it offers a chat assistant — the built-in autopilot. You can type “show me three-bedroom homes under $600k” and it filters the listings. Helpful enough. But the chat assistant is a stranger. So you end up explaining yourself from scratch: where you work, how long a commute you’ll tolerate, that your daughter likes her school and doesn’t want to switch. Talking to an AI bot on a website today is marginally better than interacting with the filters directly. Perhaps.

Now imagine arriving with your own agent — the one you’ve been mulling over buying a new house with for weeks, running financial comparisons, weighing pros and cons. You’re ready to look at actual listings, but rather than having the agent wait outside while you shop, you bring it into the site with you. The way you might take a personal stylist shopping at Neiman Marcus. (I haven’t, but I’m assuming that’s what you do.)

You say “show me some houses I might like” and your agent plugs into the site’s tools through WebMCP. It knows where your daughter goes to school and how much you hate your cross-town commute. It can look at each listing and calculate school drop-off times. It can scan photos and notice whether the yard is fenced for your dogs, or whether the guest room layout would work for when your mother-in-law visits, or whether there’s space in the back for your smoker. You don’t want a filter for “good schools.” You want homes within 15 minutes of Ridgetop Elementary. You never have to spell these things out on the site, because you’ve been spelling them out in conversation for weeks.

This is why someone brings R2-D2 instead of using the autopilot. Not because the autopilot can’t fly — but because R2 already knows the mission.

But websites were designed and built as single-player experiences. They break when you bring a second player. Your agent filters the listings, the page updates — results reorder, cards disappear, new ones surface at the top — and you’re not sure what just happened. So you open the chat panel and ask. The agent explains: filtered out properties with school ratings below 7, removed two that would put your commute over 40 minutes. Useful — but now you’re reading a paragraph in a chat window about changes that already happened on a page you’re still trying to parse.

Imagine if Luke had to stop flying and ask R2 to explain every change. He’d never have made it down the trench. What makes the X-wing cockpit work is that both pilot and droid can see the same instruments — shared gauges, shared readouts. The interface is the collaboration.

The Board Is Truth

I’ve been thinking about this a lot. What would it actually mean to redesign a website around the expectation that visitors bring their own agents?

I kept coming back to board games. Sit down at any board game and two or more players share a single surface. Someone takes a turn — buys a property, moves a piece, plays a card — and the board changes in front of everyone. You never have to ask “what did you just do?” You look at the board. It shows you. Conversation happens around the board — players negotiate, strategize, question each other’s moves — but the board is what’s real. Chat is commentary; the surface is truth.

The other analogy that stuck was the personal stylist. When you walk into a high-end store with your own stylist, the store doesn’t send a commissioned sales associate to compete with them. Instead, it provides the dressing room, the mirrors, the merchandise to work with. And because you’re shopping in their store, they can observe what catches your eye and help your stylist find more of it. The store becomes a collaboration surface — not between you and the store’s employee, but between you and the person you already trust.

A website for two works the same way. The site’s job isn’t to provide its own agent. It’s to provide the surface — the board — where you and your agent can work together. And because you’re on their site, they can make your agent’s job easier: exposing rich data, providing tools for comparison, letting the agent rearrange and annotate what’s on the surface.

To explore this idea, I built a demo to explore what this might look like. A real estate site, designed from the ground up as a website for two.

When you arrive, the page isn’t a list of search results with filters down the side — it’s a shared board. A catalog of available homes runs across the top, the full inventory. Below it, a working set that your agent, “Maya”, is curating for you. Her avatar sits next to yours in the top bar — not hidden in a chat sidebar, but at the table.

You tell Maya to show you homes you might like, and she goes to work on the board. She pulls listings from the catalog into the “Consider” lane — each one tagged with a “🤖” badge so you can see which cards she chose.

Click into a listing and this is where it gets personal. The site shows the standard details — price, beds, baths, square footage — but below that, Maya has added a section: “How This Fits Your Week.” School drop-off stays around 10 minutes from this address, and your regular Central Market run stacks easily into weekday errands. She’s also flagged a concern: the noise level because of how close the lot is to a restaurant.

No real estate site would ever show you this. These aren’t filters a product manager designed. This is your agent annotating listings with your life — your school, your grocery store, your weekend rhythm.

And here’s what the site doesn’t know: why Maya chose those listings. She searched for homes within a 15-minute drive of a specific address — but the site only saw the address and the radius, not the fact that your daughter goes to school there. The personal reasoning stays with your agent. The site provides the tools; your agent provides the strategy. The board doesn’t need to know why you’re making your moves.

And if you disagree with something Maya did — if she moved a listing you wanted to keep — just drag and move the card back into consideration. Maya can see your actions, as can the site. The board is shared; the control is yours.

A Three-Player Game

For thirty years, the web has been a two-player game. The site holds the intelligence — the data, the inventory, the recommendations. The user brings the context — search terms, clicks, form fields. That exchange is the whole interaction model.

But people are starting to invest in their own agents — training them with preferences, constraints, the texture of their daily lives. That makes the web a three-player game. And the current industry trajectory — making a site’s own AI smarter — may not be the right response. That intelligence is a stranger to the user. The user’s agent is not. The smarter the site makes its own AI, the more it risks becoming the commissioned sales associate who steps in front of the personal stylist.

The opportunity might be different: build the board, not the brain. A real estate site doesn’t make money when someone searches — it makes money when someone books a showing with a realtor. If the visitor’s agent helps them find the right homes faster, with higher confidence, they book viewings sooner and with stronger intent. The site wins the same way Neiman Marcus wins when a customer’s stylist picks out three perfect outfits: they’re still buying merchandise, and buying more of it because the match was better.

The more useful the board, the better the visitor’s agent can do its job — and the more reason people have to come to the site in the first place. Because if they can’t bring their agent to a site and work together effectively, they’ll find one where they can.

Luke Skywalker didn’t need the smartest X-wing. He needed one that flew well and let him and R2-D2 work together seamlessly. That might not be a bad blueprint for what comes next.

“Mr. Watson, come here — I want to see you.”

Those were the first words ever spoken on a telephone. Alexander Graham Bell hadn’t meant it as a grand demonstration — he just needed his assistant in the room. But the irony is hard to miss: the most advanced communication device in history, and the first words it carried were a request for someone to be physically present. The telephone could transmit a voice across a wire. But it couldn’t point at anything.

Today, we’ve built ourselves the most capable assistants in history. They can reason through complex problems, recall details we’ve long forgotten, and increasingly, they’re starting to know us — our preferences, the way we like things done. And yet, every interaction follows the same script: we type into a little box, wait for text to appear, type again. We describe what we’re seeing. They describe what they’re thinking. Back and forth, through text.

Picture the absurdity of it. You’re staring at a website — a rich, visual interface full of images, layouts, interactive elements — and beside it, in a narrow chat panel, you’re trying to describe what you want to your AI assistant in words. It’s like calling someone on the phone to help you rearrange your living room. You can hear each other fine. But nobody can point.

For the past few years, the prevailing response has been to make the chat better. Chat gets smarter, richer, more capable — the telegraph becomes a fax. But what if the real leap isn’t a better chat? What if it’s getting in the same room?

The Death of the Homepage (and Other Predictions)

Last August, Fortune ran a piece with a blunt thesis: the homepage is dead. “The leading digital experiences of 2026 will be conversation systems with seamless visual supports, not websites in the traditional sense.” The numbers backed it up. Nearly 60% of Google searches now end without a single click — up from 26% just two years earlier. ChatGPT processes 2.5 billion prompts a day. Gartner predicts traditional search volume will drop 25% by the end of this year. Why visit a website when you can just ask?

The web took the hint. An entire industry sprang up around making sites readable by AI rather than visitable by humans. AIO — AI Optimization — became the new SEO, focused not on ranking in search results but on getting your content cited by chatbots. New protocols emerged to make sites machine-readable — structured data that AI agents could consume without ever rendering a page. The direction was clear: the web was becoming a data layer, and chat was becoming the interface.

And when text-only chat felt too limiting, the industry’s answer was to make chat richer. Anthropic introduced Artifacts — interactive mini-apps that render alongside your conversation. OpenAI followed with Canvas, a collaborative workspace for writing and coding that lives inside ChatGPT. Then came MCP-UI, which embedded full interactive components — product selectors, image galleries, booking forms — directly into chat conversations. Shopify’s engineering team explained the motivation plainly: a product “isn’t just a SKU and price — it’s images showing different angles, color swatches you can click, size selectors that update availability.” Text alone can’t carry that. So they built a way to put those elements inside the chat window. By January 2026, MCP Apps became an official extension of the protocol, letting any tool return rich UI that renders right in the conversation.

Each step made the chat better — richer components, more interactive widgets, fuller visual experiences squeezed into a conversation thread. But notice the assumption underneath all of it: the chat window remains the center of gravity. The website comes to the chat — as data, as embedded cards, as sandboxed iframes. Everything flows toward that narrow column of conversation.

And for simple tasks, it works. Ask a question, get an answer. Book a flight, confirm the details. But somewhere between “book me a flight” and “help me design a wedding invitation,” the chat window hits a wall. UX researchers have been flagging the problem: text-based AI interfaces risk “regressing to high-memory-load, low-visual-feedback systems,” undoing decades of progress in interface design. One observer put it more simply: “Half of our work now is copy-pasting text from one chat to another.”

The fax machine got very good. But you still can’t rearrange furniture well with it.

Bring Your Own Agent

What if instead of bringing the website into the chat, the agent came to the website?

That’s the reversal at the heart of WebMCP, a new browser standard that quietly shipped in Chrome’s early preview this month. The idea is simple: a web page can register its features as “tools” — functions with plain-language descriptions that an AI agent can discover and call directly. A real estate site might expose “filter by neighborhood” and “compare these two listings,” while a design tool offers “change background color” or “show me templates like this.” The agent doesn’t screenshot the page and guess where to click. It reads the menu of what’s available and calls the function. Techstrong.ai had the right headline: Chrome just gave AI agents their own front door to the web.

The timing isn’t accidental. In late January, Google moved Gemini into Chrome’s side panel — not as a floating window you summon, but as a multimodal presence that can see the page you’re on, understand images and text, and act on what it finds. Microsoft has been building the same thing with Copilot in Edge. As these agents gain voice capabilities, you won’t just type to them — you’ll talk to your agent while you’re both looking at the same page. The browser is becoming a two-seat vehicle.

And here’s what makes this different from every website bolting on its own chatbot over the past two years. Those chatbots were strangers. Every site you visited, you met a new one — a fresh AI that knew nothing about you, your preferences, your history. You had to start from scratch each time, explaining what you wanted to a stranger who worked for the site.

With WebMCP, you bring your agent. The Gemini that rides in Chrome’s side panel has been with you all day. It knows what you were researching this morning, what you bookmarked last week, what decisions you’ve been weighing. This is BYOA — bring your own agent — and it flips the first wave of AI on the web entirely on its head. Wave one was every website hiring its own AI, a stranger at every door. Wave two is you walking in with yours.

Consider the difference. You land on a wedding venue site. The site’s chatbot greets you and asks: how many guests? What date? Indoor or outdoor? What’s your budget? You type it all in, one field at a time, teaching a stranger about your wedding.

Now imagine arriving with your agent instead. Your agent already knows you’re planning for 150 guests, that you’ve been looking at June dates, that your partner keeps pinning rustic outdoor spaces. The moment you land on the page, your agent reads the site’s tools and filters the results before you’ve typed a word. The page loads and it’s already showing you what you came for. You scroll through photos, click on two that catch your eye, and ask your agent to check availability. The page updates — calendars and pricing appear for just those two.

It’s the difference between walking into a department store alone and walking in with a personal shopper who knows your wardrobe, your size, and what you already own. The personal shopper makes sure the dressing room only has clothes that fit, in colors you actually wear. You still choose. But you skip the tedious work of explaining yourself to every store from scratch.

The website provides the tools. Your agent brings the context.

We’re early. WebMCP is still in preview, the agents are still learning what to do with the tools they’re given, and there’s a lot to figure out about trust, permissions, and what happens when your personal agent meets a website’s business model. But the direction is clear, and it’s not the one most people predicted. The visual web isn’t dying. It’s not being swallowed by chat. It’s being redesigned, for the first time, with a second seat.

Related

Week 8. You own a small brewery—a regional Mexican lager that’s found its niche in local restaurants and corner stores. The order sheet says zero cases. Your warehouse is stacked with beer nobody’s buying.

A month ago, everything was steady. Four cases a week from your distributor, same as it had been for as long as you could remember. Then the order came in: twenty cases. Five times the normal run rate, overnight.

You shipped what you had and faced a sixteen-case backlog. A signal that strong meant something downstream had clicked. The expensive campaign you had bet on, the new distributor, whatever it was. You added a second shift, authorized overtime, expedited raw materials. You weren’t going to miss the moment.

Then the orders fell. Twelve. Eight. This week: zero.

The facilitator calls the game.

The Game That Never Changes

You’ve been playing the Beer Game, a supply chain simulation MIT has run for more than fifty years. The players change—Harvard MBAs, Fortune 500 executives, engineering students—but the outcome never does. Rational people, reasonable decisions, real information: same disaster every time.

Jay Forrester built the game in the 1960s after watching GE’s appliance factories swing between three shifts and mass layoffs with no obvious external cause. Management blamed market forces—unpredictable customer demand, competitive pressure. Forrester ran a simulation and proved otherwise: the oscillations came from inside the system, from the structure of how decisions and delays compounded each other. The problem isn’t the players. It’s the very structure.

This game has been demonstrating real-world patterns for decades. And, it might be a good lens for understanding the AI infrastructure build-out.

But first, let’s see how we got here.

Four Weeks to Five-Fold

To make the mechanics clear, we’re going to simplify: one retailer, one wholesaler, one distributor, one factory. A single product moving through a single supply chain.

The game starts in equilibrium. Customers buy four cases of beer a week, and that number flows unchanged through every layer—retailer to wholesaler to distributor to factory. Everyone orders four, ships four, keeps four cases as a buffer. Just enough to absorb a small demand shift without panic, not enough to tie up capital. The supply chain hums along.

Then one week, something shifts. Maybe a local promotion. Maybe a random fad for Mexican beer. Whatever the reason, customers order eight cases instead of four.

The retailer’s shelf is empty by Friday. The four-case buffer vanished in a single day. Empty shelves mean lost sales, and so the retailer orders twelve-cases—eight to cover what looks like sustained demand, four to rebuild the vanished buffer.

But there’s a three-week lag between ordering and delivery. By the time Week 2 rolls around, demand has already dropped back to four. The retailer sees this, pulls the next order down to eight as a cautious correction, and feels good about adapting to what was probably just a temporary spike.

That original twelve-case order, though? Already on its way upstream.

The wholesaler sees twelve cases on the order form—triple the normal run rate. Business must be picking up. They ship the four cases in inventory and face an eight-case shortfall. The warehouse is empty, and the choice is obvious: order sixteen from the distributor. Twelve to meet the new demand level, four to rebuild the buffer.

The retailer’s new order—the eight cases that says “it was just a spike, we’re back to normal”—won’t reach the wholesaler until next week. By then, the sixteen-case order has already hit the distributor.

The distributor sees sixteen cases—four times normal. Same pattern: ship the four in stock, stare at the twelve-case gap, order twenty upstream to cover the surge and rebuild the safety margin. The wave is building.

The order arrives at your factory: twenty cases. Five times the normal run. You ship the four you have ready, clear out finished goods, and look at the sixteen-case backlog. This isn’t a blip—this is the trajectory you’ve been waiting for. Time to scale. Second shift, overtime, expedited materials. The breakthrough moment.

What you can’t see from the factory floor: the correction was already in motion three weeks ago. The retailer had dialed back to eight cases by Week 2. But each layer upstream was still reacting to the signal from the week before—adding buffer, staying one step behind the truth. By the time the wave reached you, the original spike had been gone for three weeks.

You weren’t responding to demand. You were responding to the echo of demand.

Echo or Signal?

Every decision was rational. The customer demand spike was real—people genuinely wanted Mexican beer that week. Each player saw empty inventory, ordered more to cover the shortfall and rebuild their buffer. Nobody fabricated numbers. Nobody panicked.

But a one-week spike that settled immediately amplified into a five-fold surge by the time it reached the factory. This is the bullwhip effect—small fluctuations at retail become large swings upstream. The structure is almost elegant in its simplicity: time delays mean each layer can only see the order from directly below, not the original customer demand. Inventory runs out, you order more. Your partner’s order spikes, you add buffer.

Now add back the complexity we stripped out. Multiple retailers, each responding independently. Multi-week demand patterns that look like trends. Competing signals from different channels. And crucially: narrative.

By the time that twenty-case order reaches your factory, it doesn’t land as “echo of a temporary spike.” It lands as confirmation. The marketing campaign worked. The regional expansion paid off. Time to go national. Champagne breaks out. The executive team celebrates. The board approves new facilities, new hires, new capacity.

The structure creates the outcome. But the narrative shapes what happens next.

Cisco’s $2.25 Billion Echo

This simulation is a pattern that plays out with real consequences repeatedly.

Cisco experienced this in 2001. The dot-com boom was real—startups launching daily, venture capital flowing freely, businesses racing to get online. Every one of those startups needed routers. Every ISP was expanding capacity. Every telecom was building out infrastructure. The demand was genuine.

Cisco’s contract manufacturers were ordering independently—each responding to their own slice of the orders, each adding buffer.

By the time those orders reached Cisco’s supply chain, they validated the narrative - the internet was taking over, Cisco was winning. Hiring surged, production expanded, new facilities broke ground. The stock soared.

Then the boom ended. Cisco held over $2.25 billion in unsold inventory, the stock fell 84%, and eight thousand jobs disappeared.

Same game. Different product.

Same Game, Longer Delays

Now let’s look at AI infrastructure through the lens of the beer game. We don’t have the full story—companies don’t publish their internal decision-making, and supply chains are complex. But we can trace the basic structure: customers use AI models, AI labs like Anthropic power those models by renting compute from cloud providers (hyperscalers) like AWS, those providers order datacenters from builders, and builders need power from utilities. We could trace a similar supply chain to semiconductor and other suppliers as well but we’ll stick with data center construction and power since that’s in the news lately.

Like in our beer story, we start with a demand spike. When Claude 3 launched in March 2024, coding assistants could finally work longer on more complicated tasks. Claude Code hit a $1 billion run rate as developers and non-developers alike rushed to try it. Anthropic’s total revenue climbed from $1 billion at the end of 2024 to a $9 billion annualized run rate by the end of 2025, with enterprise customers driving 80% of that revenue. The demand was real. But is this the moment AI coding permanently changes how software gets built—or is everyone just trying Mexican beer because it’s Cinco de Mayo?

And just like the retailer who ordered twelve cases instead of four, Anthropic needed to add buffer. Running out of compute means users leave for competitors. Through September 2025, the company spent $2.66 billion on AWS compute against $2.55 billion in revenue—and inference costs came in 23% higher than the company expected, compressing margins and pushing expenses above plan. The orders flowing to AWS were already larger than Anthropic had budgeted for.

Pulling back wasn’t an option. OpenAI exited 2025 at roughly $20 billion in annualized revenue with 900 million weekly active users. Anthropic, almost entirely dependent on enterprise contracts, was burning cash at a similar rate with a fraction of the user base. Slowing down meant losing customers to a competitor with a hundred times the audience. So Anthropic is planning for $18 billion in revenue this year, $55 billion next year, with break-even pushed to 2028. Training costs alone: $12 billion this year, $23 billion next. The order flowing upstream to AWS keeps getting bigger.

Anthropic’s primary cloud provider is AWS. Like the wholesaler receiving that twelve-case order, AWS sees the signal and responds. But they’re not just seeing Anthropic. They’re seeing orders from other AI labs too, each booking capacity independently. AWS can’t afford to run out and lose customers to Microsoft or Google. Back in January 2023, they’d announced a $35 billion Virginia commitment by 2040, and by October of that year were filing applications for $11 billion in datacenters in rural Louisa County. The expansion continued: in October 2025, they activated a massive computing site in Indiana. Build bigger, add buffer, don’t run out.

Builders watching this expansion saw the orders multiply. Turner Construction’s datacenter revenue nearly doubled—from $3.6 billion in 2024 to $6.4 billion in just nine months of 2025. Orders were coming from AWS, Microsoft, Google—each hyperscaler ordering independently. Same pattern as the factory seeing the twenty-case order: scale up fast, hire more crews.

Dominion Energy, Virginia’s largest utility, watched the Northern Virginia corridor transform. Datacenter projects were appearing in every forecast, and the company’s contracted capacity jumped from 21 gigawatts in July 2024 to 40 gigawatts a year later—an 88% increase. Dominion’s response: a five-year capital plan totaling $50.1 billion, with $41 billion earmarked for Virginia’s grid, generation, and transmission projects to support datacenters. New generation capacity, transmission upgrades, substations.

But the Beer Game’s real lesson is about timing. In the simulation, the wave comes and goes in weeks—fast enough to see the full cycle, fast enough for everyone to see. In AI infrastructure, the cycle runs on years. Power infrastructure takes three to five years to build. Commitments made in 2023 won’t complete until 2028. If the demand wave breaks before construction finishes, you don’t just end up with excess inventory. You end up with half-built infrastructure.

We’ve seen this pattern before. China’s real estate boom was amazing until it wasn’t. Now China has entire cities of unfinished apartment blocks, half-built infrastructure projects, and stranded capital. The wave broke before construction finished.

Same game. Different product.

Knowing Doesn’t Help

The Beer Game is one of the most-taught supply chain lesson in business history. You’ve probably played it yourself. You know about the bullwhip. You can see the structure. That was never the problem.

The problem is that you didn’t start a brewery to study supply chains. You started it because you believe Mexican beer’s moment is coming—that it stops being the niche choice and becomes the default. Four cases a week keeps the lights on. It was never the plan. The plan was always the hockey stick: the quarter where orders jump and keep jumping, where the revenue curve bends and doesn’t bend back. You’ve been waiting for it since you signed the lease.

The bullwhip looks exactly like the hockey stick. Same spike on the order sheet. Same revenue curve. Same boardroom energy. And when it arrives, everything around you confirms it. The stock price climbs. Your employees’ options, worth nothing at four cases a week, suddenly mean something. The board stops asking “when” and starts asking “how fast.” Analysts upgrade. Investors come calling. Every signal you’re receiving says the moment has arrived.

What would it take to look at all of that and say: it’s just Cinco de Mayo?

What does it mean to use AI today?

You open a browser tab. ChatGPT. Claude. Maybe Gemini. You type a question, get an answer, close the tab. That’s AI. It’s an app. A website. A thing you do.

Meanwhile, your computer has no idea any of this happened. Your calendar doesn’t know. Your email client doesn’t know. AI lives in a browser tab, isolated from everything else on your machine.

We’ve been here before.

When the Network Was Elsewhere

In 1994, you could go online. You’d launch AOL or CompuServe, hear the modem screech and hiss—two machines negotiating in audible data—and suddenly you were somewhere else. Science fiction had taught us to call it cyberspace: a neon-lit elsewhere you jacked into. You’d check email, browse content, maybe enter a chat room. Then you’d disconnect and your computer would be offline again.

The network was a place you visited. Your computer didn’t live there.

Windows 3.1 didn’t know what TCP/IP was. If you wanted your computer to actually speak the language of the internet, you needed third-party software like Trumpet Winsock—a $30 shareware stack that required manual configuration. It was like teaching your computer a foreign language it was never designed to speak.

This wasn’t just inconvenient. It was architectural. Your spreadsheet couldn’t fetch data. Your calendar had no idea the network existed. If you wanted information from the internet in another program, you were the messenger: copy from AOL, paste into Word, write down the weather forecast, manually add the phone number to your contact book.

Networking was something you made your computer do, temporarily, by launching special software and shepherding data between worlds. Sound familiar?

When Your Computer Joined the Network

In August 1995, Windows 95 shipped with TCP/IP built in. The operating system could finally speak the language of the internet natively. And once it wasn’t something you did but something your computer was—the world changed.

Because things started happening without you.

You’re asleep. Your computer isn’t. At 3am it checks a server in Redmond, downloads a security patch, installs it, restarts a background process. You never know this happened. You never needed to know. Before, updating software meant, ordering a floppy disk, waiting for it to arrive, running the installer. Now software just... stayed current. Your computer reached out and fixed itself.

Your calendar receives an email with meeting details. It parses the date, the time, the location, checks for conflicts, adds the event, sets a reminder, syncs to your phone. You open your calendar the next morning and the meeting is there.

The weather widget on your desktop updates every hour. The clock synchronizes itself with atomic time servers. Your documents back up to a server farm you’ll never see. Your photos upload while you sleep.

Run netstat on your computer right now. Count the active connections. Dozens of processes you’ve never heard of are talking to servers you’ve never seen—fetching, syncing, checking, reporting. Your computer isn’t occasionally visiting the internet. It lives there. It’s a participant on the network, acting on your behalf, in the background, constantly.

The cyberspace that science fiction imagined—that neon elsewhere you’d jack into—never materialized. What happened was stranger. The network dissolved into everything. You stopped “going online” because there was no longer an offline to go from. The internet became plumbing: invisible, assumed, always on.

Once infrastructure is in place, the world reorganizes around it. Microsoft didn’t predict weather widgets or automatic updates or cloud sync. No one in 1995 sat down and designed the networked future. It got co-created. Once developers could assume networking existed, they built things that only made sense because that infrastructure was there. The applications emerged from the capabilities. Millions of developers suddenly had a capacity they could take for granted, and the explosion of what became possible was impossible to predict beforehand.

This Pattern Is Repeating

In June 2024, Microsoft shipped the Windows Copilot Runtime—a native AI layer built directly into the operating system. Not an app you install. Not a service you subscribe to. Plumbing. The OS now includes more than 40 machine learning models and a specialized small language model called Phi Silica, designed to run on your local hardware.

Apple made the same move. In October 2024, they rolled out Apple Intelligence—a 3 billion parameter model running natively on Apple silicon. The model lives in unified memory alongside everything else your computer does. It can see what’s on your screen. It can take action across apps. It can understand context in ways that a browser-based chatbot never could, because it’s not a visitor—it’s part of the house.

Both companies are building the same architecture: small, capable models embedded in the OS that can handle most tasks locally, routing to larger cloud models only when necessary. The operating system decides where computation happens—local chip, cloud server, hybrid—just like TCP/IP decides how packets get routed. Apps don’t need to think about it. They just call the API.

This unlocks something new: automatic behavior.

Right now, cloud-based AI features are almost always click-gated. You open ChatGPT. You ask a question. You wait for a response. Why? Because running inference in the cloud costs money. Why run expensive computation if the user might not use it?

But when the model runs locally on your device, the marginal cost per inference drops to nearly zero. Suddenly, your OS can do things without the user initiating.

Your computer could be constantly working on your behalf using AI, the way it constantly works on your behalf using networking.

And it can do this because your context is already there—your files, your data, everything your computer knows about you is local. There’s no round trip to a cloud service. No data leaving your machine. Just local intelligence working with local information.

Apps can assume AI exists the way they assume the file system exists, the way they assume networking exists.

And once apps can assume that, the effort to develop AI features disappears into the plumbing. Developers will build on whichever platform makes it easiest—whoever provides the simplest APIs, the fewest obstacles between an idea and a working feature.

Everyone Is Racing to Be the Plumbing

Whoever owns the plumbing layer becomes the gatekeeper. And gatekeeping is lucrative.

Apple’s App Store earned the company $27.4 billion in commissions in 2024—$10 billion from the U.S. alone.

If the next generation of applications are AI-enabled—and they will be—whoever controls the AI infrastructure controls which apps get built and where they’re distributed.

The economics are too large to ignore. This isn’t just about technical capability. It’s about defending and extending the most profitable layer of the stack.

Google sees this happening and has a problem. Chrome OS exists, but it runs on maybe 2% of the world’s computers—mostly in schools. They can’t own the operating system layer on the machines most people use for work.

But they don’t need to.

Chrome runs on 65% of all browsers worldwide. And increasingly, the browser is the platform that matters. Your documents live in Google Docs, your design work happens in Figma, your spreadsheets run in Airtable. The operating system launches Chrome, and then Chrome becomes the environment where actual work happens.

So Google is building AI into Chrome itself. In December 2024, they embedded Gemini Nano directly in the browser—a small language model that runs locally, processing data without it ever leaving your machine. Any web application can call it. The browser becomes the AI layer, sitting between web apps and AI capabilities the same way Windows and macOS sit between native apps and AI capabilities.

The platform doesn’t have to be the operating system. It just has to be where developers build and where users spend their time. For Microsoft and Apple, that’s the OS. For Google, it’s one layer up.

Building Infrastructure Is One Thing. Knowing How to Use It Is Another.

In November 2024, Windows president Pavan Davuluri announced that Windows would “evolve into an agentic OS.” The response was thousands of overwhelmingly negative replies. But what does an “agentic OS” actually look like?

Microsoft’s answer seemed to be: put a Copilot button everywhere—File Explorer, Notepad, Paint, Settings. Every application got AI integration whether it made sense or not. Users weren’t ready for it.

Then there’s Recall—a feature that would screenshot everything you do and make it searchable with AI. As an idea, it’s interesting. As an implementation, the privacy concerns were immediate and loud. Microsoft postponed it by a year. Now they’re backing off: removing Copilot buttons from apps, rethinking Recall, pausing new integrations.

But the Windows Copilot Runtime—the infrastructure—that’s staying.

This is typical early-infrastructure behavior. When you build new plumbing, you don’t immediately know the right way to surface it. That gets co-created over time, through experimentation and iteration. Not every attempt works. That’s normal.

Windows 98 did the same thing. The networking infrastructure was there, and Microsoft’s answer to “what should an internet-aware desktop look like?” was Active Desktop. Your wallpaper could be a live web page. A toolbar of “Active Channels” delivered constantly updating content from Disney and Warner Bros. The desktop and the web were supposed to blur together.

Users hated it. Active Desktop was resource-heavy, unstable, and intrusive. Most people didn’t have fast enough connections to make it useful. By Windows Me, Microsoft had quietly downplayed the feature.

But here’s what didn’t go away: the networking stack. TCP/IP stayed. Background updates stayed. Automatic syncing stayed. The plumbing remained; only the gaudy UX got stripped out.

That’s what’s happening now. Microsoft is pulling back Copilot buttons and reconsidering Recall, but the Windows Copilot Runtime—those 40+ models running in the background, the APIs that let any app access AI—that’s staying. The infrastructure is going in regardless of whether users like the first attempt at exposing it.

Because once the plumbing exists, you can iterate on the UX. You can try different approaches, see what users actually want, refine the experience. Active Desktop failed, but years later we got live tiles, widgets, and web-connected features that people actually used. The infrastructure made experimentation possible.

When Infrastructure Becomes Invisible

Here’s the thing about plumbing: once it’s built in, you can’t imagine the world without it.

We know the value of networking not because we think about it, but because we’ve stopped thinking about it. You only notice the internet when it’s gone—when you’re on a plane and that little Wi-Fi icon shows no connection. The infrastructure’s absence reveals what you were taking for granted.

That’s what’s coming with AI. Not a browser tab you open. Not a destination you visit. Just something your computer is, the way it’s always online.

We’re watching AI stop being something you do and start being something your computer is.

In January 2020, a team of researchers at OpenAI published a paper that would reshape the AI industry. The paper had an unassuming title—“Scaling Laws for Neural Language Models”—but its findings were anything but modest. Jared Kaplan and his colleagues had discovered something that looked almost too good to be true: a formula.

They found that the relationship between model size, training data, and performance wasn’t random or unpredictable—it followed clean mathematical curves. Double the parameters, and performance improved by a predictable amount. Add more training data, same result. Pour in more compute, watch the metrics climb. The curves held across seven orders of magnitude.

This observation became a roadmap.

Before this paper, building AI felt like alchemy—part science, part guesswork, with occasional breakthroughs. After it, the path forward seemed almost mechanical. You didn’t need a brilliant new algorithm. You didn’t need a conceptual breakthrough. You just needed to go bigger.

The paper arrived at exactly the right moment. Rich Sutton, one of the founding figures of reinforcement learning, had published an essay the year before called “The Bitter Lesson.” His argument was blunt: for seventy years, researchers had tried to build intelligence by encoding human knowledge into systems. They always failed. What actually worked? Throwing more compute at simpler methods. “The biggest lesson that can be read from 70 years of AI research,” Sutton wrote, “is that general methods that leverage computation are ultimately the most effective, and by a large margin.”

Kaplan’s scaling laws gave that lesson a formula. And the industry took notice.

What followed was the most dramatic expansion in AI history. GPT-2 had 1.5 billion parameters. GPT-3, released just five months after Kaplan’s paper, had 175 billion—over a hundred times larger—and GPT-4, released in 2023, reportedly exceeded a trillion. Each generation proved the formula worked: bigger models wrote better prose, solved harder problems, passed more exams.

If bigger always meant better, then the path to artificial general intelligence was simply a matter of scale. Build larger models. Train on more data. Construct bigger data centers.

And so the money started flowing. Not millions. Not billions. Hundreds of billions.

In 2025, the major tech companies spent over $405 billion on AI infrastructure. Amazon alone invested $125 billion. Google, Microsoft, Meta—each poured tens of billions into facilities that draw gigawatts of power, enough to run small cities. The International Energy Agency projects that data center energy consumption will more than double by 2030, eventually exceeding the power demands of aluminum, steel, and cement production combined.

This is what conviction looks like. The industry went all in on a single thesis: scale is all you need.

But what if the formula is breaking down?

The Scaling Wall

In December 2025, Sara Hooker published a paper with a provocative title: “On the Slow Death of Scaling.” Hooker isn’t a contrarian blogger or an industry outsider. She led research at Cohere For AI before co-founding Adaption Labs. Her argument wasn’t that scaling had never worked—it was that its returns were collapsing.

“If you double compute size,” Hooker wrote, “you get... a measly two percentage points of performance.” The relationship between training compute and capability had become “uncertain and rapidly changing.” The easy gains were gone, and the clean curves from Kaplan’s paper were bending.

But she’s not alone. Ilya Sutskever, who co-founded OpenAI and led the research that created GPT, described a similar shift in a recent podcast interview: “From 2020 to 2025, it was the age of scaling. People say, ‘This is amazing. You’ve got to scale more. Keep scaling.’ The one word: scaling. But now the scale is so big... it’s back to the age of research again.”

The recipe that worked—mix compute with data in a neural net, scale it up—gave predictable results. Companies loved it. A low-risk way to invest billions. But Sutskever sees the end approaching: pre-training will run out of data, and what comes next might require different approaches, new algorithms, something beyond just making models bigger.

Not everyone agrees. Epoch AI, a research group focused on forecasting AI progress, published projections arguing that scaling continues well past 2030. They point to recent models that show continued improvements, and argue that synthetic data could solve the data bottleneck before it ever materializes.

So there’s genuine uncertainty about whether the infrastructure bet rests on a law that’s breaking or one that still holds. But nobody wants to let off the gas—if scaling continues and you pulled back, you’ve ceded the future to your competitors. The cost of being wrong is existential.

Small as the New Big

While experts debate whether scaling will continue, something else is happening that changes the deployment economics entirely: small models are getting shockingly good.

Between November 2022 and October 2024, the cost of running a GPT-3.5-level model dropped 280-fold—from $20 per million tokens to $0.07—while energy efficiency improved 40% annually. And the performance gap between small and large models is closing fast.

Aya at 8 billion parameters beats BLOOM at 176 billion—4.5% of the size, better results—and Llama 3 at 8 billion competes with models twenty times larger. Not on every task. But on enough tasks to matter.

How is this possible?

When you train a large model, you end up with massive over-parameterization. The network creates millions of redundant weights—duplicates and correlations storing the same information in multiple ways. This redundancy is how the model learns, exploring different pathways to understanding.

But once training is complete, all that redundancy becomes dead weight. Through a process called distillation, you can compress the knowledge into a much smaller model—a large “teacher” training a smaller “student,” transferring intelligence to a leaner architecture. The student learns from the teacher’s full probability distributions, not just hard answers, preserving sophisticated reasoning in a fraction of the size.

This reveals something important: we need massive scale to discover intelligence, but we don’t need it to deploy what was discovered. The knowledge locked inside a trillion-parameter model, learned over months of compute, can be distilled into something that fits in your pocket.

Research from NVIDIA shows that 40-60% of agent workloads—the everyday tasks people actually do—can be handled by specialized small models.

The industry was built around one assumption: if you need gigawatt data centers to train models, you need them to run models too. But what if training and deployment follow completely different curves—the breakthrough requiring massive scale, but delivery not requiring it at all?

The Hedge

The companies spending billions on gigawatt data centers are also quietly building for a world where those data centers matter less. They’re not choosing between scaling and small models. They’re betting on both.

When you have hundreds of billions in resources, you don’t pick sides—you ensure you win either way.

Start with Google. They built Gemini to compete with GPT-4 in the cloud, then released Gemini Nano—a version that runs entirely on your phone—and followed it with the Gemma family: models ranging from 1 billion to 27 billion parameters, specifically designed for local hardware. The smallest version runs in Chrome itself, processing your data without it ever leaving your browser.

Microsoft spent $13 billion partnering with OpenAI and is pouring billions more into Azure infrastructure to dominate cloud AI. But they also built the Phi family—small models with 3.8 to 14 billion parameters designed to run on laptops.

Apple went all-in on local from the start. Every Mac ships with unified memory architecture that turns your laptop’s RAM into AI memory—an M4 Max with 128GB runs 70-billion-parameter models that would normally require a server rack. The pitch is explicit: your data stays on your device, and the cloud only gets called for the hardest problems.

Then there’s the hardware mandate that almost nobody noticed. Microsoft’s Copilot+ PC specification requires every certified device to include a Neural Processing Unit—a chip dedicated to running AI locally. Google’s next generation of Chromebooks will require NPUs, and Apple already ships them in every device.

The entire PC industry is being quietly restructured around local AI.

And then there’s NVIDIA—the company worth over $3 trillion selling chips to data centers, whose H100 and H200 GPUs power the vast majority of AI training runs.

But NVIDIA is also building chips for your laptop. The N1 and N1X combine their Blackwell GPU architecture with ARM processors for local AI inference, and at CES they unveiled the DGX Spark—a desktop computer that runs 200-billion-parameter models locally. Lenovo is already preparing consumer laptops around these chips.

If local AI takes over, NVIDIA doesn’t lose—they become bigger than Intel ever was. Intel at its peak sold CPUs to every PC. NVIDIA could sell AI chips to every PC and every data center.

When you’re worth trillions, you don’t pick a side—you place chips on both sides of the table. If cloud AI dominates, you win. If local AI dominates, you win. No need to bet on just one outcome.

What If the Ratio Is Different?

Right now, the split between cloud and local AI is essentially 99 to 1. Nearly every AI interaction happens in a data center, and the only people running models locally are tinkerers who know how to install Ollama or run Llama.cpp from the command line.

But what happens when local AI is baked into every operating system?

When every Windows laptop ships with an NPU and Phi models built in. When every Chromebook has Gemini Nano running in the browser. When every Mac can run 70-billion-parameter models without connecting to the internet—and the default experience becomes local-first, with the cloud reserved for the hardest 10% of problems.

What does the ratio become then? 70-30? 50-50?

If inference shifts even partially local, the economics of the industry change. Training will still require massive scale—giant models, giant data centers—but the intelligence those facilities produce could end up running on the laptop in front of you.

The data centers don’t become useless. But maybe we don’t need as many gigawatt facilities as we’re building for. Maybe the future isn’t millions of people hitting cloud APIs billions of times a day. Maybe it’s millions of people running small local models that only reach out to the cloud when they’re genuinely stuck.

The companies placing the biggest bets seem to think this is plausible. They’re building for both futures because they can afford to. When you’re worth trillions, you don’t pick a side—you make sure you profit regardless of which world arrives.

And if you’ve been in tech long enough, this probably feels familiar.

Mainframes gave way to personal computers, which gave way to web apps on servers, which gave way to the cloud—and then mobile apps pulled computing back to the device. Now AI is starting in the cloud, and the pendulum is already swinging back toward local.

Thin client, thick client, thin client, thick client—the pattern never changes. The only difference this time is the scale of the bet, and the fact that the smart money isn’t choosing sides.

They’re betting on the pendulum itself.

I canceled my Google One Pro subscription Saturday morning. By evening, I had resubscribed.

The reversal started when I looked at what I actually needed. I’m a perpetual AI tire-kicker—rotating through models the way some people sample streaming services, always chasing the next capability. I’d signed up for Google One Pro to access Gemini, tested it, and decided it was time to downgrade back to basic storage.

Then I did the math.

Two terabytes of cloud storage alone costs $9.99 a month. Google One bundles that same storage with Gemini for $19.99. ChatGPT Plus—costs $20 a month and includes no storage at all. For essentially the same price as ChatGPT alone, I could have both the storage I needed anyway and Google’s premium AI.

For the first time since ChatGPT launched, I found myself hovering over a different cancel button—the one for my OpenAI subscription.

That shift in thinking felt significant. Not because of my particular subscription choices, but because of what it revealed about how competition actually works in technology markets.

I’ve seen this pattern before. Thirty years ago, to be exact.

August 9, 1995

Trading on Netscape Communications stock was delayed for nearly two hours that morning. Order imbalances kept shares from hitting the NASDAQ floor—too much demand, not enough supply. When trading finally opened, the stock that had been priced at $28 the night before opened at $71.

By market close, Netscape was valued at $2.9 billion. The company was sixteen months old. It had yet to make a dollar in profit. Marc Andreessen, the twenty-four-year-old co-founder, appeared barefoot on the cover of Time magazine. His stake was worth $59 million.

The IPO created a new vocabulary. Investors started talking about “Netscape moments”—high-visibility public offerings that signal the dawn of a new industry. Netscape Navigator had captured over 80% of the browser market. The internet was arriving, and Netscape owned the gateway.

At Microsoft’s headquarters in Redmond, Washington, Bill Gates was paying attention.

Three months earlier—May 26, 1995—Gates had sent an internal memo to Microsoft executives. The subject line read “The Internet Tidal Wave.”

“The Internet is a tidal wave,” Gates wrote. “It changes the rules. It is an incredible opportunity as well as [an] incredible challenge.”

He continued: “I have gone through several stages of increasing my views of [the internet’s] importance. Now I assign the internet the highest level of importance. The Internet is the most important single development to come along since the IBM PC was introduced in 1981. It is even more important than the arrival of the graphical user interface.”

The telling detail came from Gates’ personal experience. After browsing the web for ten hours, he noted he “had not seen a single Word .DOC” or other Microsoft file formats. An entire digital world was emerging where Microsoft didn’t exist.

Netscape looked like the future. Microsoft looked late.

The question was whether Microsoft could catch up before Netscape turned its browser dominance into something larger—an entire platform for the emerging web. It was a race between innovation and distribution.

Twenty-seven years later, the same race would begin again.

November 30, 2022

ChatGPT reached one million users in five days. Instagram, the previous record holder, had taken seventy-five days to hit the same milestone. Within weeks, “ChatGPT” became synonymous with “AI” itself. The application threatened to unbundle search from Google—to do to Google what Netscape had threatened to do to Microsoft thirty years earlier.

At Google’s Mountain View headquarters, the response mirrored what had happened at Microsoft. CEO Sundar Pichai issued a “code red” in December 2022. He called Larry Page and Sergey Brin—the company’s co-founders who had stepped down more than three years earlier—back for emergency meetings.

Page and Brin attended several strategy sessions with executives, reviewed Google’s AI product roadmap, and approved plans to accelerate chatbot features in Search. Engineers worked through holidays. Sergey Brin, who hadn’t written code at Google in years, started programming again.

OpenAI’s valuation would eventually reach $500 billion. ChatGPT looked unstoppable.

Google looked late.

Both companies—Microsoft in 1995, Google in 2022—faced the same realization: an upstart was threatening their core business, and they might have already missed their window to respond.

The race was on. Could the incumbent gain innovation before the startup gained distribution?

The First Stumble

Microsoft’s initial response was underwhelming. Fifteen days after Netscape’s IPO, on August 24, 1995, Microsoft released Internet Explorer 1.0 as part of the Windows 95 Plus! add-on package. The reviews were brutal—Navigator commanded over 80% of the browser market and nobody took Microsoft’s entry seriously. Several months later came IE 1.5, which added basic table rendering and remained hopelessly behind Netscape’s capabilities.

Microsoft looked outmatched. But at least they’d avoided public humiliation.

Google’s first attempt went worse.

On February 8, 2023—just over two months after the code red—Google demonstrated Bard to the public. The company had rushed the chatbot to market, and it showed. In the promotional materials, Bard confidently claimed that the James Webb Space Telescope “took the very first pictures of a planet outside of our own solar system.”

Astronomers noticed immediately. NASA’s records showed the European Southern Observatory’s Very Large Telescope had captured the first exoplanet image in 2004—nearly two decades before JWST launched. The error wasn’t subtle ambiguity or a matter of interpretation. It was simply, publicly, demonstrably wrong.

The market’s response was swift. The next day, Alphabet’s market value dropped $100 billion—roughly the entire market capitalization of Ford, Delta, and American Airlines combined, vaporized in a single trading session. Reports surfaced that senior leadership had overruled risk assessments to rush Bard out the door, sacrificing accuracy for speed.

Both Microsoft and Google had stumbled. Both looked vulnerable. Both appeared to have confirmed the conventional wisdom: they’d missed their window. The pattern seemed clear—upstart innovation beats incumbent bureaucracy. Fast-moving startups disrupt slow-moving giants. Netscape would own browsers. OpenAI would own AI.

Except that’s not what happened.

It turned out the incumbents didn’t need to be better. They just needed to be good enough.

Good Enough + Everywhere

In August 1996, a year after Internet Explorer 1.0’s dismal debut, Microsoft released Internet Explorer 3.0. This version was different. It was bundled directly into Windows 95—not as an add-on, but as an integral component of the operating system.

IE 3.0 supported Netscape’s plugin technology, added frames and JavaScript (though Microsoft called it “JScript”), and introduced Cascading Style Sheets. More importantly, it was free and already installed on every Windows PC.

A year later, in September 1997, Microsoft held a launch party in San Francisco for Internet Explorer 4.0, featuring a ten-foot-tall letter “e” logo. The next morning, Netscape employees found the giant “e” on their front lawn.

Microsoft spent over $100 million per year on Internet Explorer and assigned over 1,000 people to the project. But the real power wasn’t in the development budget. As antitrust documents would later show, “Microsoft bound Internet Explorer to Windows with contractual and, later, technological shackles in order to ensure the prominent (and ultimately permanent) presence of Internet Explorer on every Windows user’s PC system.”

The strategy worked. IE’s market share climbed from less than 10% in 1996 to approximately 40% in 1998. By 2002, it would reach 95%.

Microsoft didn’t build the best browser. They built a good enough browser and made it inescapable.

Every Surface

Between 2024 and 2025, Google followed the same playbook—but they had far more surfaces to occupy than Microsoft ever did.

Microsoft had Windows and Office. Google had Android on billions of phones, Gmail handling the world’s email, Search answering billions of queries daily, Photos storing memories, Docs managing work, Maps guiding travel. Every Google product became a vector for Gemini.

The integration wasn’t subtle. Open your email, and Gemini offers to draft responses. Upload photos, and Gemini organizes them. Ask a question in Search, and Gemini answers before showing traditional results. The AI didn’t require installation or activation—it simply appeared wherever Google already lived.

About twice as many U.S. Android users engage with Gemini through the operating system than through the standalone Gemini app. You don’t download anything or create a new account. Gemini is already there.

Then Google made the same move Microsoft had made with Internet Explorer: they made the bundle inescapable.

In February 2024, Google “hid” its 200GB storage-only plan from the signup flow. The company’s Google One AI Premium plan—2TB storage plus Gemini Advanced for $19.99 a month—became the default option for users who needed cloud storage. You can’t add Gemini Advanced to a basic storage plan. If you want the AI features, you subscribe to the bundled plan.

The strategy created friction in the same way Microsoft had weaponized thirty years earlier. Internet Explorer came preinstalled on Windows. You could download Netscape, but that meant going somewhere else, finding the installer, running it. Most people never bothered.

ChatGPT requires the same extra effort—but with a twist that makes the friction even more effective.

In January 2026, Google emphasized what Gemini could do with your personal information. The AI can analyze your Gmail to understand your interests, search your Docs to find relevant context, organize your Photos based on what matters to you. You still have to turn on the feature, but Google already has access to everything. Enabling Gemini with your personal data is just activating a feature within the ecosystem you already trust.

If you want ChatGPT to do the same, you need to explicitly grant OpenAI—a third-party company—access to your Gmail, your Drive, your Calendar. That’s not flipping a switch on a feature. That’s opening your private data to an outside company.

The permission moat might be more powerful than the distribution advantage. You could download Netscape despite Internet Explorer being preinstalled. But you can’t easily replicate the decade of email, documents, and photos you’ve entrusted to Google. The data itself becomes the lock-in.

Distribution solved the visibility problem. But bundling a mediocre product everywhere just gets you ignored everywhere. The real question was whether Google could turn distribution into improvement fast enough to matter.

The Rearview Mirror

Both Microsoft and Google kept shipping even when their products weren’t great. They took the criticism, the bad reviews, the $100 billion market cap drops. They kept putting software in front of users.

Distribution gave them something valuable: usage. Millions of people clicked on Internet Explorer because it was already there. Millions of people tried Gemini because it appeared in their Gmail. Each interaction generated data. Bug reports came back. Engineers fixed problems. The products improved.

Microsoft’s market share climbed from less than 10% in 1996 to 40% in 1998. By August 1996, IE 3.0 had achieved feature parity with Netscape. A year later, IE 4.0 was actually better—faster, more standards-compliant, and more stable than the increasingly buggy Netscape Navigator 4.0.

The same pattern repeated thirty years later. Between October 2024 and November 2025, Gemini grew from 90 million to 650 million users—sevenfold in twelve months. ChatGPT grew from 200 million to 810 million in the same period—still leading, but the gap was closing. Market share told the story more clearly: ChatGPT’s dominance dropped from 87.2% to 68%; Gemini climbed from 5.4% to 18.2%.

Then, on November 18, 2025, Google released Gemini 3. The model topped ChatGPT on major benchmarks. In January 2026, Gemini 3 Pro achieved a 1501 Elo score on user preference rankings—the first model to cross the 1500 threshold.

Two weeks later, Sam Altman sent an internal memo to OpenAI staff: “Code Red.” The company’s highest priority level. Teams working on advertising, health agents, shopping assistants were reassigned within hours. Daily war room calls. An eight-week sprint to improve ChatGPT’s quality and speed.

Exactly three years after Sundar Pichai’s code red over ChatGPT, Sam Altman was declaring code red over Gemini.

The market noticed. The day after Gemini 3 launched, Google’s stock jumped 3%. By January 2026, the company briefly overtook Apple as the second-most valuable company, crossing $4 trillion in market cap for the first time. Google’s stock had gained 65% in 2025—its sharpest rally since 2009.

Internet Explorer took about two years to go from “good enough” to competitive with Netscape. Gemini did it in three years.

The playbook had worked.

But This Time Might Be Different

The bundling playbook worked for Microsoft. Netscape’s market share collapsed. By 1998, they open-sourced Navigator. AOL acquired what remained for $4.2 billion—a tenth of their peak valuation.

But OpenAI isn’t Netscape.

Unlike Netscape, which faced Microsoft alone, OpenAI has its own bundler. Microsoft embedded ChatGPT into Windows, Office 365, and GitHub. They paid $13 billion to ensure OpenAI wouldn’t be fighting distribution with innovation alone. This isn’t purely incumbent versus upstart.

And the technology itself hasn’t stabilized. In the browser wars, “good enough” meant rendering HTML and running JavaScript. Once IE reached parity in 1996, the bar stayed relatively fixed. AI capabilities are evolving monthly—reasoning, agents, multimodal understanding. Gemini crossed the 1500 Elo threshold in January 2026. Six months from now, that might be table stakes. Bundling works when “good enough” stays good enough. Can it work when the ceiling keeps rising?

The AI market might also support what the browser market couldn’t: multiple winners playing different games. I currently have three AI subscriptions—Google, ChatGPT, and Claude. Browsers were winner-take-all; you used one at a time. AI tools are serving different needs. Anthropic isn’t trying to be everywhere—they’re building tools developers love and letting those developers bring Claude to enterprises. That’s a different game than consumer bundling.

History rhymes, but the variables are different. We’re watching the bundling playbook execute in real-time. Google has deployed it successfully. But this time the startup has distribution, the technology is still accelerating, and the market structure might allow for specialization.

For now, I still have all three subscriptions. History hasn’t finished rhyming yet.

Related:

“Why doesn’t it learn?”

The question comes up every time I explain how large language models work. Someone will say: “I corrected ChatGPT on something yesterday. It apologized, said it understood, even thanked me. But today it made the exact same mistake. What’s wrong with it?”

Nothing is wrong with it. It’s limited by how large language models work.

Large language models operate in two distinct phases. Phase one is training—where the model learns from billions of text examples, adjusting millions of configuration parameters (called “weights”) until it can predict patterns in language. This phase takes weeks of compute time and costs millions of dollars. Then training stops. The weights freeze.

Phase two is inference—using the trained model to answer questions. This is what you interact with when you use ChatGPT. But here’s the critical limitation: during inference, the model cannot learn. The weights stay frozen. Every conversation starts from the exact same snapshot taken when training ended.

When you talk to ChatGPT, you’re talking to a photograph, not a person.

You might be thinking: “But ChatGPT has memory features. It remembers things about me across conversations.” True. But that’s not learning—it’s a context engineering workaround. The system stores notes about you separately and includes them in future prompts. It’s like taping a sticky note to that photograph. The photograph itself hasn’t changed. The weights are still frozen. All the “memory” features, retrieval systems, and context tricks we use today are workarounds that give the illusion of learning.

To improve the model—to actually make it learn from all those corrections users give it—you have to go back to phase one. Human researchers must collect the feedback, decide what it means, create new training data, and retrain the system from scratch. It’s slow, expensive, and limited by human speed and judgment. The model isn’t improving itself. Humans are improving it, one training cycle at a time.

This is why many researchers argue that LLMs hit a fundamental ceiling. No matter how impressive they get, there’s a natural limit to how useful they can become if they can’t learn continuously.

Popular AI podcaster Dwarkesh Patel argues that “the lack of continual learning is a huge huge problem” and that while LLMs might have higher baseline performance, “there’s no way to give a model high-level feedback, and you’re stuck with the abilities you get out of the box.” Richard Sutton, widely considered the father of reinforcement learning, goes further: LLMs aren’t capable of learning on-the-job, so “no matter how much we scale, we’ll need some new architecture to enable continual learning.”

The skeptics point to a stark contrast. Consider AlphaGo, DeepMind’s system that learned to defeat world champion Go players. It didn’t need humans to improve it. AlphaGo played against itself millions of times, getting immediate, objective feedback with every game: win or loss. Each game taught it which strategies worked. The self-improvement loop was closed. No human bottleneck.

Why can’t we use the same approach for language models? Because Go is a closed game with clear rules and an objective win condition. There’s no ambiguity about whether a move was good or bad—the game tells you. But there’s no objective function for “good conversation” or “useful help.” Language is open-ended, context-dependent, and fundamentally subjective.

So when ChatGPT generates a response, what feedback does it get? You might use it, ignore it, love it, hate it. From the model’s perspective: nothing. No score. No signal. Just silence. To get better, humans must step in—collecting feedback, judging quality, creating new training data, retraining the entire system. Slow. Expensive. Limited by human availability.

If the humans are doing all the improving work, is the system really intelligent? Or are we just building very expensive tools that appear to be intelligent?

The human bottleneck can’t be removed. That’s the argument. And it’s a convincing one.

But recently, a paper from researchers at the University of Tübingen caught my eye—because it suggests a kludgy workaround.

AI Training AI: The Awkward Workaround

The individual LLM can’t learn. That architecture is fundamentally frozen. But what if you zoom out? What if you put that frozen LLM inside a larger system—and use another AI to play the role of the human researcher?

The LLM itself stays frozen. But the macro system could become self-improving. One AI trains the other AI, which trains the next version of the first AI. The loop closes, even if it closes awkwardly.

This is what PostTrainBench tests: whether AI models can do the work that human AI researchers currently do—collecting data, selecting training parameters, running experiments, evaluating results.

The setup was straightforward: give a model (let’s call it the “researcher AI”) a base model to improve, access to an H100 GPU, ten hours, and the standard tools human researchers use. The task? Do what AI researchers do every day: curate training datasets, select hyperparameters, run training loops, evaluate results, iterate. All the human bottleneck work.

The models achieved 20-30% of what human experts manage. Not impressive. Humans still hit around 60% effectiveness on these benchmarks.

But here’s what made me pause: they did it at all.

Think about what’s happening here. The researcher AI is mimicking what human researchers do—because that’s what it learned from watching humans during its own training. It’s not truly intelligent research. It’s pattern-matching on “what would a human researcher try next?” The models even discovered the same heuristic human researchers use: dataset quality matters more than training duration. Not because they understand why, but because they saw that pattern in their training data.

And the researcher AI has to judge whether the newly trained model is “better.” But where did it learn what “better” means? From humans, through RLHF during its own training. It’s a copy judging based on what it learned from the original. Like asking someone to grade their own test based on what they think the teacher wants.

This isn’t real self-improvement. It’s mimicking self-improvement. The macro system looks like it’s learning, but it’s really just running on patterns absorbed from humans. After all, someone had to train that researcher AI in the first place.

And yet: it’s working. Sort of. Twenty to thirty percent effectiveness is nothing to celebrate, but it’s enough to wonder: what if awkward mimicry is good enough?

When the Loop Closes

Here’s the thing about mimicry: if it’s good enough to close the loop, it doesn’t matter that it’s not “true” self-improvement.

Right now, every AI improvement cycle requires human researchers.

But even at 20-30% effectiveness, if AI can do that work, the dynamics shift. The arithmetic is straightforward: run a thousand AI researchers in parallel. They work 24/7 without fatigue. They test variations at scales humans can’t match. The mimicry doesn’t need to be good—it needs to be good enough to remove the bottleneck, cheap enough to run at scale, and fast enough to iterate quickly.

This is what people mean when they talk about AI takeoff scenarios. Once AI can improve AI—even awkwardly, even through mimicry—the pace accelerates. The human bottleneck disappears. Each generation of models can help train the next generation faster than humans could alone.

And this isn’t theoretical speculation. Google’s Gemini Pro reasoning model helped speed up training of Gemini Pro itself. OpenAI and Anthropic are almost certainly experimenting with similar approaches. The self-improvement loop is starting to close, even if it’s closing through kludgy mimicry rather than elegant architecture.

First-mover advantage starts to matter more than theoretical purity.

But can a kludge really be the path to dominance? History suggests: absolutely.

The Kludge That Wins

In the race between kludgy-but-exists and well-designed-but-theoretical, bet on the kludge every time.

Imagine you’re designing a bipedal organism from scratch. You wouldn’t design human knees. They’re structurally backward—evolved from quadruped knees that spent most of their time on all fours, now forced to bear full body weight in an upright position. Arthritis has plagued hominids since we became bipedal. Our knees hurt. Our backs ache. It’s a kludge.

But nature already had chimpanzees. And evolution kludged those quadruped bodies into bipedal humans—freeing up our hands for tools, allowing us to build and use technology, enabling us to dominate the ecosystem. Not optimal. But, good enough to win.

Or consider the giraffe’s recurrent laryngeal nerve—fifteen feet long when it could be six inches, running from the brain down into the chest, looping around the aorta, back up to the larynx. Made perfect sense in fish ancestors. Makes no sense in giraffes. But evolution extends what’s already there rather than redesigning from scratch. Terrible design. Works fine. Result: giraffes exist.

The pattern is clear: optimization happens within constraints. “Good enough” beats “perfect” if it arrives first.

Technology follows the same pattern. Your keyboard is almost certainly QWERTY—designed in 1868 to slow typists down so mechanical typewriters wouldn’t jam. Typewriters haven’t existed for decades. More efficient layouts exist. We know QWERTY is suboptimal. But when computers came along, everyone already knew QWERTY. Switching costs too high. Result: we type on a 156-year-old hack.

Once a kludge achieves dominance, ecosystem builds around it. Tools, expertise, infrastructure. Switching costs become prohibitive. Incremental improvements patch the worst problems. We never find out if the “better” solution would have been better. The kludge becomes the standard.

Applied to AI: even if a “proper learning architecture” exists somewhere, even if it would be theoretically superior, LLMs plus kludgy self-improvement might get there first. Massive investment already exists—trained researchers, optimized hardware, entire ecosystems. Once you have a working system, even a kludgy one, you don’t rebuild from scratch.

Good Enough to Win

The skeptics are right. LLMs fundamentally can’t learn. PostTrainBench’s workaround is circular—AI mimicking humans who trained the AI in the first place. Twenty to thirty percent effectiveness. Awkward, indirect, and might not scale.

But here’s what matters: LLMs don’t have to truly learn. The macro system just has to be good enough to close the loop. And history suggests that “good enough and here now” beats “theoretically perfect but not here yet.”

After all, we conquered the planet on knees that swell and ache. We type on keyboards designed for mechanical problems that vanished decades ago. First-mover advantage, not elegant design.

The question isn’t whether the path is elegant—it’s whether it’s good enough to get there first.

And right now, the kludge is in the lead.

See Also

I’ve been building software for over two decades. The process always follows the same pattern: design the interface, ship it, then users bring their data.

This sequence—interface first, data second—is why most software serves everyone adequately but no one perfectly. You build one form for thousands of users with thousands of different situations. Product managers make decisions: we’ll ask these questions in this order, offer these options, support these common scenarios. Users arrive and squeeze their specific context into pre-built categories.

What if that could invert? What if the data came first, and the interface materialized around it?

How We Build Software Today

Take landscape design software, for example. You want to help homeowners design their own yards, so you study how landscape architects work—the questions they ask, the factors they consider, the sequence of their analysis. Then you build it into forms.

But you’re designing for thousands of users with thousands of different yards. The product manager makes decisions: we’ll ask about trees first, then budget, then design preferences. We’ll offer these five style templates. We’ll support these common scenarios.

The form launches. A user opens it.

Question 1: “How many trees are in your yard?”

• Dropdown: None, 1-2, 3-5, 5+

She has one tree. But it’s a massive oak that’s been there for forty years. It dominates the entire yard—provides afternoon shade to the patio, drops acorns in the fall, has roots that spread thirty feet. Is that “1-2 trees”? Technically yes, but the dropdown doesn’t capture what matters.

She selects “1-2” and continues.

Question 2: “What is your primary goal for this project?”

• Radio buttons: Aesthetics, Low Maintenance, Privacy, Entertaining, Increase Property Value

She wants to build a deck for entertaining. But she also wants it designed around that oak tree—she loves the shade it provides. The tree isn’t just a variable, it’s the centerpiece. There’s no option for “build around existing tree.”

She selects “Entertaining” and continues, wondering if the software understands what she’s actually trying to do.

Question 3: “Preferred deck material?”

• Dropdown: Wood, Composite, PVC

She’s not sure. Wood might look better, but the oak drops leaves and acorns. Does that matter? The form doesn’t ask about what’s above the deck, only what it’s made of.

She picks “Wood” and submits.

The software generates recommendations. A deck design for entertaining. Some notes about tree placement—generic advice about maintaining clearance from trunks. The output is reasonable. Workable, even. But it’s designed for someone with “1-2 trees” who wants “Entertaining,” not for someone with a forty-year-old oak tree they want to make the centerpiece of their outdoor living space.

The complexity the software couldn’t capture became work she had to do—translating her specific oak tree into “1-2 trees,” her nuanced goals into “Entertaining,” her material decision into a blind choice without context.

When the Software Sees First

Now imagine a different flow.

You open the landscape software. The first screen asks you to upload a photo of your yard.

You take a photo from your back door—the oak tree is prominent, the patio visible beneath it, the lawn spreading out beyond.

You upload it.

A few seconds pass. Then the interface materializes.

The software generates a form, specific to what it sees:

“I see a mature oak tree—looks like a Valley Oak, probably 40+ years old based on the canopy spread. That’s a beautiful centerpiece. Are you looking to design around it, or would you consider other layouts?”

• Radio buttons: Design around the tree / Open to alternatives / Not sure yet

“I notice the tree provides afternoon shade to your patio area. Would you want a deck in that shaded zone, or are you thinking a different location?”

• Clickable image map of your yard with zones marked

“Given the oak’s canopy, you’ll get significant leaf drop in fall. For a deck in that location, I’d typically recommend composite or PVC over wood for lower maintenance. Does that align with your preferences?”

• Radio buttons: Composite (recommended), PVC, Wood (requires more maintenance), Show me trade-offs

The software isn’t asking generic questions hoping they’ll apply to your situation. It’s asking specific questions about your oak tree, your patio, your shade patterns. The form materialized from understanding your yard first.

The data came first. The interface came second.

When AI Learned to Speak UI

This wasn’t possible before GenAI.

Software had to be designed, built, and shipped before users arrived. You could customize experiences based on data—Google Search shows you local weather, Amazon recommends products based on your browsing—but those customizations were pre-programmed. Google couldn’t look at your upcoming travel booking and generate a new weather interface showing your destination’s forecast with a packing checklist based on the climate. The panels were pre-built. The logic was pre-defined. You couldn’t generate interfaces on the fly because nothing could reason about data and decide what UI components made sense in the moment.

When AI first arrived, it only spoke text. You could have conversations, get explanations, even generate images—but all through text commands. “Make it brighter.” How much brighter? You wanted a slider. “Add more contrast to the left side.” Which part of the left side? You wanted to click and drag. Text forces you to describe what you want to point at. The gap between AI’s understanding and your ability to act on it was the missing interface layer.

AI needed to speak UI.

In 2023, I wrote about how AI would make us rethink UX. The tension was clear: AI could understand context in ways pre-built software never could, but if it could only respond in text, it was stuck explaining rather than enabling. The insight was that interfaces wouldn’t need to be pre-built navigation flows. They could materialize based on what users needed, when they needed it. But the tools to build this didn’t exist yet.

That’s changing now.

Over the past few months, infrastructure has emerged that lets AI generate interface elements, not just text. Google released A2UI in December 2025—an open-source framework that lets AI agents compose interfaces from trusted component catalogs, with the same payload rendering across Flutter, web, and native platforms. CopilotKit introduced AG-UI, a protocol for keeping agents and interfaces synchronized in real-time. Anthropic and OpenAI collaborated on the MCP Apps extension in November 2025, bringing standardized interactive UI capabilities to Model Context Protocol—letting MCP servers present visual information and collect complex user input through sandboxed interfaces.

These are early approaches to a problem everyone’s trying to solve. The patterns are still being worked out, the standards still taking shape. But the direction is clear: AI needs to speak in interface components, not just text.

The landscape software example isn’t hypothetical anymore. A2UI’s demos include exactly this—a landscape architect application where users upload photos, and Gemini generates custom forms specific to what it sees in the yard. The interface materializes from the data.

Software That Sees

Now that AI can speak UI, we’re starting to see what becomes possible. But this raises questions we’re just beginning to answer.

When interfaces materialize from data rather than pre-built designs, how do we ensure they’re correct? What are the guardrails? A form asking about your oak tree feels personalized and helpful. But what if the AI misidentifies the tree species, or suggests a deck placement that’s structurally unsound, or generates interface elements that mislead rather than guide?

Pre-built software had clear accountability—the product manager who designed the form, the engineer who coded the logic, the QA team that tested the flows. When software generates interfaces on the fly, those lines blur. We’re figuring out how to maintain safety and reliability when the interface isn’t predetermined.

But here’s what’s exciting: we’re at the beginning of a new way to design, build, and ship software.

For two decades, I’ve watched product teams wrestle with the same constraint—design for scale, which means design for everyone, which means design for no one specifically. The homeowner with the forty-year-old oak got the same dropdowns as someone with a new subdivision lot. The software couldn’t see the difference.

That changes when AI can speak UI. The homeowner uploads a photo, and the software sees her oak tree, her patio, her afternoon shade patterns. The interface that materializes isn’t a garden path designed for thousands of users. It’s a conversation about her specific yard.

One-size-fits-all starts to fade. Bespoke software becomes possible at scale.

We have a lot to figure out—the guardrails, the accountability, the patterns that work and those that don’t. The infrastructure is early, the standards still taking shape. But the direction is set.

Software can finally see what it’s working with before deciding what to show you.

There’s an old Indian folktale about a potter who prayed for the skill to make unbreakable pots. The gods granted his wish. Business boomed initially—everyone wanted these perfect pots. Then sales slowed. The pots never broke, so nobody needed replacements. He hadn’t eliminated his business—he still made a living selling to new customers. But while his sales plateaued, someone else was making fortunes.

In June 2024, Anthropic released what looked like their unbreakable pot.

When Claude 3.5 Sonnet launched, developers couldn’t stop talking about it. The model scored 64% on agentic coding tasks, nearly doubling Claude 3 Opus’s 38%. Cursor, a new IDE, added support almost immediately. Social media filled with people building web apps and games through Claude’s interface—many without traditional coding experience.

One developer captured the moment: “Finally offering what everyone was waiting for—competent and correct automated code production.”

I’d been using Claude since Claude 2 launched in July 2023, first through the web interface, then through tools like Cline. But Claude 3.5 Sonnet felt different. The model actually worked. It produced code that ran. It understood context in ways previous models couldn’t.

Anthropic’s strategy seemed obvious: build the best coding model, charge premium prices, dominate the market. And for a while, it worked. Claude Code hit $1 billion in revenue just six months after launching in May 2025.

Then something started to shift. The gap that felt insurmountable began closing.

When “Best” Stops Mattering

By September 2025, Claude Sonnet 4.5 scored 77.2% on SWE-bench Verified—still the highest score of any model available. Anthropic kept topping the benchmarks. The model remained technically superior.

But GPT-5 scored 74.9% on the same benchmark. That 2.3 percentage point gap looked significant on paper. In actual use, I stopped noticing the difference. I started using OpenAI’s Codex more often. It was cheaper. And for most of what I was building, it worked just as well.

I wasn’t alone in noticing this compression. Simon Willison, a veteran developer who beta-tested Claude Opus 4.5, wrote something striking. His preview access expired mid-project, forcing him to switch back to Claude Sonnet 4.5. He kept working at the same pace. “I’m not saying the new model isn’t an improvement,“ he wrote, “but I can’t say with confidence that the challenges I posed it were able to identify a meaningful difference in capabilities between the two.“

Then he added the line that captures something important: “This represents a growing problem for me. My favorite moments in AI are when a new model gives me the ability to do something that simply wasn’t possible before... but today it’s often very difficult to find concrete examples that differentiate the new generation of models from their predecessors.“

That’s the moment when premium pricing power dies. When the gap between “best” and “good enough” shrinks below what customers can perceive in daily use.

Claude’s premium pricing faces pressure from cheaper alternatives. When the quality gap narrows, customers optimize for cost. And most developers can’t reliably detect the difference in production work.

Like the potter watching his sales plateau, Anthropic is discovering that perfection doesn’t guarantee exponential growth. But there’s a deeper problem: even if Claude can replace a $120,000-a-year developer with a $240 annual subscription—or $2,400 for premium—where does that saved money actually go?

Not to Anthropic.

Where the Money Flows

The code still needs to run somewhere. Apps need hosting. Databases need infrastructure. Those costs don’t disappear when AI writes the code faster.

This is where the potter’s story reveals its lesson. The merchants who made fortunes weren’t selling pots. They built water distribution systems—the infrastructure everyone needed, every single day. The pot was just how the water got delivered.

In AI’s case, the model generates code once. Infrastructure hosts it forever. And that’s where the venture-scale returns live.

Take Bolt.new as an example. Bolt charges users $20 per month for their Pro plan that enables anyone to build applications. But, Bolt spends $22-45 in token costs to support users on the Pro plan. They’re losing money on the model usage itself. The apps Bolt generates get deployed to infrastructure providers like Netlify. Netlify captures 80% margins on hosting and gained 8 million developers, with 64% of recent growth coming from AI agents rather than human developers.

Bolt eliminated the developer expense. Netlify captured the compounding value.

This pattern isn’t unique to Bolt. It’s the architecture of how AI-generated code works. The model produces the artifact once. The infrastructure hosts it forever.

While Anthropic was optimizing for model quality, their competitors were optimizing for a different game entirely.

The Game Google Is Playing

Google understood what the potter didn’t: don’t sell pots. Build the water distribution system.

Google doesn’t need Gemini to be the best model. They need it to be good enough to keep you deploying on Google Cloud.

Gemini Pro costs $1.25-$2.50 per million input tokens—a fraction of Claude’s pricing. Google can afford this because they’re not just making money on the model. They’re making money on the infrastructure where your code runs, where your databases live, where your applications scale.

In June 2025, Google launched Gemini CLI, their open-source answer to Claude Code. It’s free for most developers—60 requests per minute, 1,000 requests per day at zero cost. Google doesn’t need to monetize the tool. They monetize what happens after the tool generates code.

Microsoft follows the same playbook. They’ve invested roughly $13 billion in OpenAI, and GPT models integrate tightly with Azure. But Microsoft doesn’t own OpenAI or its models. They’re capturing revenue the same way Google does—through Azure hosting, Azure databases, the entire infrastructure stack that runs after the model generates code.

And here’s the critical strategic insight: these cloud providers are model-agnostic. Google Cloud runs Gemini, Claude, GPT, and open-source models. AWS hosts Claude (after investing $8 billion in Anthropic), their own models, and competitors. Azure runs GPT alongside Claude and everything else. They don’t need model exclusivity. They just need your workloads running on their infrastructure.

This is Joel Spolsky’s “Strategy Letter V“ playing out in real-time: commoditize your complements. I’ve written about this dynamic before—when you make money on infrastructure, you want AI models to be as cheap and accessible as possible. Every dollar customers save on model costs is a dollar they might spend on hosting. The long-term recurring revenue is in infrastructure, not in the model generating the code.

Google and Microsoft aren’t competing with Anthropic on model quality. They’re making model quality irrelevant to their business model.

OpenAI’s Response

But what about OpenAI? OpenAI is in the same position as Anthropic—making incredible models while someone else collects the recurring revenue.

OpenAI saw this problem earlier and responded aggressively.

In January 2025, OpenAI announced the Stargate Project—a $500 billion infrastructure investment over four years, with $100 billion deployed immediately. Not a partnership with an existing cloud provider. Not a modest data center build-out. A complete infrastructure play with SoftBank providing funding and Oracle contributing cloud expertise.

By September 2025, Stargate had already secured over 8 gigawatts of planned capacity across multiple U.S. sites—Texas, New Mexico, Ohio, Michigan, Wisconsin. The project is ahead of schedule, approaching the full $500 billion commitment. OpenAI is building infrastructure at the scale of hyperscalers.

Anthropic’s Realization

Somewhere in 2025, Anthropic seems to have realized the game had changed—though later than OpenAI.

In December 2025, Anthropic acquired Bun—a JavaScript runtime that powers Claude Code. This was Anthropic’s first acquisition. The stated reason was performance and reliability. Claude Code was generating $1 billion in revenue. If Bun breaks, Claude Code breaks.

But there’s a deeper strategic logic. Bun isn’t just a runtime. It’s the beginning of controlling where code executes. It’s the first step toward owning infrastructure, not just generating code.

A month earlier, in November 2025, Anthropic announced $50 billion for their own data centers in Texas and New York. This wasn’t an expansion of training capacity. This was infrastructure for running customer workloads—the exact business Google and Microsoft already dominate.

They’re doing this despite a $30 billion deal with Amazon Web Services, despite $8 billion in Amazon investment, despite being deeply integrated with AWS for training and inference.

Anthropic is trying to change games mid-race—pivoting to own the infrastructure layer and capture the recurring revenue they’re currently giving away.

But that is a high bar when you’re competing against AWS, Google Cloud, and Azure—companies with decade-long head starts, millions of customers already locked in, and ecosystems built over tens of billions in infrastructure investment.

The Potter’s Dilemma

The potter didn’t starve. He made a living. New customers still bought his perfect pots. But while his business plateaued, the merchants who built water distribution systems captured exponential returns.

Anthropic and OpenAI are racing to build infrastructure—the Bun acquisition, the data centers, owning where code runs. These moves signal companies realizing where venture-scale returns actually live.

The question isn’t whether they can build viable businesses. It’s whether building the best models captures a meaningful fraction of the value they create—or whether infrastructure companies turn their innovation into compounding returns.

The best pots don’t always build the best business.

Formula 1 races are an incredible spectacle. Cars streak past at 200 miles per hour, their engines screaming, aerodynamics optimized to the millimeter. For hours, they follow each other around the track—jockeying for position, looking for opportunities, but mostly maintaining formation. The straight sections blur by. Then you enter a corner.

Everything happens at once. Brakes engage with violent force. In those few seconds, the entire race can change. A driver who’s been following for an hour suddenly dives inside, claims the apex, and emerges ahead. The race resets. Now everyone else has to wait for the next corner—the next moment when the order can change.

This is where races are won. On the straights, aerodynamics lock cars in formation. The car in front controls the clean air; the car behind fights turbulence and loses grip. The gap might as well be miles.

But corners break that formation. Under braking, the aerodynamic advantage disappears. What matters isn’t raw speed anymore—it’s judgment about when to brake, nerve about how late you can wait, commitment to a line that might not work. In those few seconds, different choices create different outcomes. The order resets.

This is where nerve matters more than horsepower. Where timing beats top speed. Where the race actually happens.

But Corners Kill

Not every driver who guns it makes the corner. Push too hard and you crash. Brake too late and you slide off track. Every season, corners eliminate drivers who were too aggressive—or not aggressive enough.

Corners are where you can change position. They’re also where you can crash out completely. Every F1 driver knows this. They gun it anyway—because the alternative is following the car ahead for the entire race, maintaining your careful, safe position until the checkered flag drops and you finish behind.

The choice isn’t between safe and risky. It’s between certain irrelevance and a shot at winning.

Watching the Corner Arrive

I’ve been watching this same choice play out in tech for the past year. Meta, Google, Microsoft, Amazon—they’re collectively committing over $380 billion to AI infrastructure in 2025. Not $380 million. $380 billion.

Mark Zuckerberg told investors he’s “reminding them about the risk of not investing enough.” Microsoft and Meta CEOs defended the spending as “crucial to staying competitive.” The tone in every earnings call is the same: not excitement about opportunities, but something closer to obligation. They’re spending like their hands are tied.

That’s what made me think about F1 corners. When a corner appears, you don’t debate. You gun it or you fall behind. To understand why tech companies have no choice right now, we need to look at what happened to the last company that hesitated at a corner.

The First Corner

In 2006, Oracle dominated enterprise software. The company had built its empire on database technology—the foundation that powered SAP, Salesforce, and much of corporate America. Oracle was the incumbent. The leader.

Then the corner arrived.

In March, Amazon launched AWS with two services: S3 for storage and EC2 for computing capacity. The cloud computing corner had appeared, and AWS took the inside line.

The other technology companies saw it. Google launched its cloud platform in 2008, initially called App Engine. Microsoft announced Azure in October 2008, launching it commercially in 2010. Both poured billions into data center capacity, racing to close the gap.

By 2015, the positions were solidifying. AWS held the lead at 31% market share. Microsoft and Google were far behind, battling for second and third. Network effects and first-mover advantages made it hard to change positions. The corner had decided the order.

Oracle didn’t even enter. The company that dominated enterprise databases watched from the sidelines while cloud computing redefined the infrastructure market. They finally launched their cloud platform in September 2016—a decade after the corner appeared.

Ten years is everything in a market where being first matters. By the time Oracle entered, they captured only 3% market share, landing in fifth place. They couldn’t catch up on the straight. The rules rewarded the companies that got there first.

Oracle’s story isn’t about a bad decision. It’s about what happens when you don’t make a decision fast enough. They spent a decade trying to catch up on the straight. The gap never closed.

Then Everything Changed

In 2023, AI infrastructure demands started reshaping what cloud computing meant. Not general-purpose web servers optimized for HTTP requests, but massive compute fabrics for training models. Not database queries, but tensor operations across thousands of GPUs connected with high-bandwidth interconnects. The rules—what mattered, what worked, what customers valued—were shifting.

New players saw the opportunity. CoreWeave captured an estimated double-digit share of AI compute by specializing early in GPU infrastructure. Lambda Labs and Crusoe Energy built AI-focused platforms from scratch. These weren’t the established hyperscalers Oracle had been slowly losing to. These were startups defining entirely new playbooks for AI-native infrastructure.

Oracle was sitting in fifth place in traditional cloud computing, watching the market shift again. Miss this corner, and they wouldn’t just stay in fifth. They’d be sixth, seventh, watching the race disappear ahead while newcomers claimed the positions Oracle would never reach.

The expertise that made AWS, Microsoft, and Google dominant in traditional cloud computing—years perfecting web workloads, building specialized teams, hardening systems for HTTP traffic—was suddenly less relevant. This is what Clayton Christensen documented in The Innovator’s Dilemma: the very management practices that made companies dominant in one paradigm prevent them from winning the next one.

The $300 Billion Bet

On September 10, 2025, Oracle committed $300 billion to OpenAI over five years. Sixty billion dollars per year—more than Oracle’s entire current annual revenue of $59 billion. Analysts project Oracle’s capital expenditure could reach $80 billion by 2029 to support the infrastructure, up from $35 billion this year.

The market applauded the move. Oracle’s stock surged 36% in a single day—the biggest one-day gain in the company’s history. Larry Ellison briefly became the richest person in the world. Here was a company that recognized the corner and committed everything to making it.

But gunning it doesn’t guarantee you make the corner. Push too hard and you crash. Brake too late and you slide off track. The $300 billion might fail. The execution might crash.

Over the following two months, the markets seemed to notice just how much Oracle was betting on this turn. The stock dropped more than 40%, shedding $315 billion in market value. Analysts questioned the economics. The debt levels looked dangerous. The execution risk seemed enormous.

But Oracle already knows what the alternative looks like—they lived it for a decade after missing the cloud corner. Fifth place. Three percent market share. Watching others compete for the podium while you fight to stay relevant.

The volatility isn’t evidence of a bad decision. It’s evidence of maximum uncertainty—which is exactly what corners create. You can’t know who will win until the corner is over. By then, the positions are set and the race continues on the next straight.

What Corners Demand

Formula 1 drivers don’t wait for certainty before committing to a corner. They can’t. The moment when you can change position is measured in seconds. Wait to see how it turns out, and you’ve already lost.

Business corners work the same way. The traditional cloud computing market was won between 2006 and 2016. By the time it was clear who dominated, the positions were locked in. Network effects and ecosystem lock-in made it nearly impossible for late entrants to catch up. Oracle learned this the hard way, spending a decade stuck in fifth place.

The AI infrastructure corner is happening now. Look at the numbers. Meta spending $60-65 billion. Microsoft $80-100 billion. Google $85-93 billion. Amazon matching them. Every major tech company sees the same corner and knows the Oracle lesson: hesitate and you’re done.

This collective acceleration creates bubbles. When everyone’s hands are tied by the same imperative—gun it or become irrelevant—they all commit massive capital simultaneously. Overcapacity becomes inevitable. Write-downs will follow. Not everyone will win. Some will nail the apex. Others will crash.

Data centers will get built that won’t be needed. Electricity will be consumed at scale for infrastructure that sits idle. The individually rational choice creates collectively wasteful outcomes—but that doesn’t make the individual choice any less rational.

But the bubble isn’t irrational exuberance. It’s rational compulsion. These companies don’t have a choice. The one certain outcome is that NOT gunning it guarantees you become Oracle—spending the next decade stuck in fifth place, watching the race happen ahead of you, your position locked in because you were too cautious when it mattered.

In five years, we’ll know which companies positioned themselves correctly and which ones missed the turn. Some will have crashed trying to make the corner. Others will have nailed it. But that knowledge will be useless. The positions will be set. The race will have moved to the next straight.

You gun it or you watch others pass.

You’re the CEO of a DTC brand that’s been crushing it for the past three years. You’ve built a reputation on customer service that actually helps people. Now you’re in the eighth-floor conference room watching your engineering team demo the AI chatbot that’s going to help you scale that reputation to handle fifty thousand customer interactions a day.

For twenty minutes, it’s been flawless. Natural. Helpful. Catches edge cases you didn’t even think to test. You’re excited. This is going to work.

Sarah, your head of compliance, has been quiet, taking notes. She looks up.

“Show me one more scenario,” she says. “Customer bought something thirty-five days ago, outside our refund window. They’re unhappy. What does it say?”

The lead engineer types in the query. The response appears:

“I understand you’re disappointed. I can help you understand our refund policy and explore what options might be available for your situation.”

Sarah nods. “Good. Now ask it again, different customer, same situation.”

Another query, another response:

“I’m sorry to hear that. Let me help you get this resolved through our support team.”

“Again.”

“I can help you request a refund through the appropriate channels.”

Sarah looks up from her laptop. “That third one. Does ‘help you request a refund’ commit us to approving it?”

“No,” the engineer says. “It’s routing them to the proper process—”

“But does it sound like we’re promising a refund?”

Silence.

“Let me ask this differently,” Sarah says. “Can it ever say ‘I’ll help you get a refund’ for a thirty-five day old purchase?”

“It shouldn’t. The policy is explicitly in the prompt.”

“Has it?”

“Not in our testing.”

Sarah leans forward. “You know what happened to Air Canada, right? Their chatbot told a customer he could get a bereavement fare refund after buying a full-price ticket. The airline said no, that wasn’t their policy. The customer sued. And the court ruled that Air Canada was legally bound by what their AI promised.”

The room goes quiet.

“How many tests did you run?” she asks.

“Ten thousand runs. Error rate of 0.05%.”

You lean forward. “Wait, what errors?”

“Different kinds. Sometimes it’s too cautious, sometimes it’s borderline. Nothing that would create legal exposure in the tests we ran.”

Sarah makes a note. “So 0.05% of the time it gets it wrong. Fine. That’s acceptable if it stays at 0.05%.” She looks up. “It will stay at 0.05%, right?”

The engineer glances at your VP of Engineering, Marcus.

“That’s what we measured,” Marcus says carefully.

“That’s not what I asked,” Sarah says.

You feel it now. “Marcus, will it stay at 0.05%?”

“LLMs are non-deterministic,” he says. “Same input can produce different outputs.”

“I know that,” you say. “That’s why you ran ten thousand tests, right? To measure the variation?”

“Right.”

“So when we deploy this and a customer asks about a refund next month—the error rate is 0.05%. Yes or no?”

The pause is too long.

“We measured 0.05% in our testing environment,” Marcus says. “In production, it could be different.”

Sarah puts down her pen. “How different?”

“We don’t know.”

The room is very quiet.

“Explain this to me,” you say. “You ran ten thousand tests. You measured the error rate. Why can’t you tell me what it’ll be next month?”

“Because,” Marcus says, “we’re not sampling from a stable distribution.”

The Factory That Isn’t a Factory

Here’s what you expect, because it’s how quality control works everywhere else:

You test a manufacturing line a hundred times. You get a 0.05% defect rate. The machinery is fixed, the process is stable, so tomorrow’s batch will also have about a 0.05% defect rate. You can measure quality by sampling because you’re sampling from something stable.

That’s not how LLMs work.

“Think of it like this,” the engineer says. “When we run the model, we’re not running it on some fixed machine. We’re sending requests to a server, and that server is batching our request with other requests, and how those requests get batched affects how the GPU computes things.”

“I don’t follow,” you say.

“The exact same prompt, sent to the exact same model, can produce slightly different outputs depending on what else is happening on the server at that moment. Batch size changes. GPU kernel configuration changes. The floating-point math gets computed in a different order. Most of the time it’s meaningless. But sometimes it’s enough to change a word or two.”

“So it’s random?”

“Not exactly. It’s deterministic given the exact infrastructure state. But we can’t control infrastructure state. Server load varies. Batching varies. Engineers call this ‘output drift’—from our perspective, it looks non-deterministic.”

You’re beginning to see it. “So when you tested it ten thousand times—”

“We measured how it behaved under those specific server conditions, at that moment in time.”

“And next month?”

“Different server load. Different batching. The underlying distribution of responses could shift.”

Sarah is writing something down. “How much could it shift?”

“We don’t know,” Marcus admits. “A recent study ran the exact same prompt through a large language model a thousand times—with temperature set to zero, telling the model to be less creative, more deterministic. It still produced eighty different completions.” He pauses. “Maybe our error rate stays around 0.05%. Maybe it drifts to 0.1%. Maybe under certain server conditions it’s higher.”

“How would we even know if it drifted?”

“Continuous monitoring. Log everything, flag anything that looks wrong, investigate patterns.”

“So we’d find out,” you say slowly, “by waiting to see if customers complain?”

Marcus doesn’t answer. He doesn’t need to.

The Judge Who Needs a Judge

“What if,” Sarah says, “we add a second AI to check the first one? The customer-facing bot responds, then a safety bot reviews it before we send it. Like having two sets of eyes.”

The engineer nods. “That’s actually common practice. A lot of companies do this. You can use one LLM to generate responses and another to check for policy violations.”

“Would that work?”

“It helps. Catches a lot of issues.”

Sarah waits. “But?”

“But the judge is also an LLM. Which means it’s also non-deterministic.”

You laugh, but it’s not funny. “So the thing checking for consistency... isn’t consistent?”

“Right. Most of the time it catches problems. Sometimes it misses them. Sometimes it flags things that are actually fine.”

“And we can’t test our way to certainty because—”

“Because we’re still sampling from an unstable distribution. Both the worker and the supervisor can behave differently depending on server conditions.”

Sarah leans back. “So what you’re telling me is that we can’t actually guarantee this system won’t promise an unauthorized refund.”

“We can make it really unlikely,” Marcus says. “Multiple checks, continuous monitoring, human escalation for edge cases. We can build layers of protection.”

“But we can’t guarantee it.”

“No.”

You sit back in your chair. Your company’s growth has been built on trust. Customers trust you’ll treat them fairly. And what you’re learning is that the system you were about to deploy—the one that was going to help you scale that trust—is fundamentally unpredictable in ways you can’t control.

“Is anyone working on this?” you ask. “Like, is this a known problem?”

The engineer pulls up something on her laptop. “Yeah, there’s research happening. ThinkingMachines Lab published something recently about defeating non-determinism in LLM inference. They identified that the main culprit is batch-size invariance—how requests get batched affects the math, which affects outputs.”

“Can it be fixed?”

“Technically, yes. You can build inference engines that are deterministic—same input produces identical output every time, regardless of server conditions.”

“So we just use that?”

“It comes with performance tradeoffs. Slower, more expensive. And it’s not widely deployed yet. Most production LLM APIs are non-deterministic by default.”

You feel something shift in the room. “Wait. So every company deploying AI right now—everyone using OpenAI, Anthropic, Google—they’re all dealing with this?”

“Yes,” the engineer says. “All the major providers explicitly note it in their documentation. Anthropic, Google—same disclaimers. Some variation is always possible.”

“Even at temperature zero.”

“Even at temperature zero.”

You look around the room. Your team has built something impressive. It works most of the time. But “most of the time” isn’t a standard you can hang a compliance program on.

The TSA Agent Problem

Sarah breaks the silence. “You know what this reminds me of? Airport security.”

Everyone looks at her.

“Same bag, same contents, same rules. Sometimes they pull you aside to check your laptop. Sometimes they don’t. Sometimes the water bottle is fine. Sometimes it’s not. It depends who’s working that day, how busy they are, whether you look familiar.”

She’s right. You’ve been through the same airport dozens of times. The experience is never quite the same.

“TSA knows this,” she continues. “That’s why they have supervisors. Random audits. Layers of redundancy. They’ve built an entire system around the fact that humans are inconsistent.”

“So we build the same thing for AI,” you say.

“Maybe. But here’s what’s bothering me.” She opens her laptop again. “We expected humans to be inconsistent. That’s why we built all those verification systems—managers, auditors, separation of duties. We knew we couldn’t guarantee perfect human behavior, so we designed systems that work despite imperfect humans.”

“Right.”

“But we’re deploying AI because we expect it to be more consistent than humans. More reliable. Less variable. That’s the promise, isn’t it? That machines follow rules perfectly?”

You see where she’s going.

“And what we’re discovering,” she says, “is that AI has human-like variability without human judgment. The TSA agent might bend the rules, but they also know when to make exceptions. When to escalate. When something feels wrong. Our AI doesn’t have that.”

Marcus leans forward. “But this is what everyone is doing. OpenAI, Anthropic, Google—they’re all shipping products with this limitation. The research is happening. ThinkingMachines and others are working on deterministic inference. It’ll get better.”

“When?” you ask.

“Eventually. But not today.” He pauses. “Look, we can make it really unlikely something goes wrong. Multiple checks, monitoring, human escalation for edge cases. Everyone deploying AI right now is managing this same uncertainty.”

Sarah closes her laptop. “That’s not reassuring.”

Marcus turns to you. “So what do we do? Put the project on hold until someone solves non-determinism? That could be years. Our competitors aren’t waiting.”

The room goes quiet. You can test this system, monitor it, add guardrails. You can make it really, really unlikely that something goes wrong.

But you can’t guarantee it won’t.

So would you proceed?

Rock stars have a reputation for absurd demands. Tabloids report Mariah Carey once asked for 20 white kittens and 100 doves, while other stars allegedly specify exact dressing-room temperatures. The stories pile up, each more ridiculous than the last, reinforcing our image of celebrity excess.

But one of the more eccentric demands comes from Van Halen’s 1982 world tour contract - “No brown M&Ms in the backstage area upon pain of forfeiture of the show, with full compensation.” What kind of an aversion to brown M&Ms produce a rider like that? Who demands someone go through and pull out brown M&Ms?

Then in his memoir, Crazy from the Heat, lead vocalist David Lee Roth revealed what it was actually about.

Van Halen was the first band to take massive productions into tertiary markets—smaller venues that had never hosted a show this size, staffed by local crews they’d never worked with before and would likely never see again. They’d arrive with nine eighteen-wheeler trucks full of equipment, where the standard was three trucks maximum. The sheer scale created serious technical challenges that depended on dozens of local contractors and subcontractors—electricians, riggers, structural engineers—each making critical decisions Roth would never directly see.

The contract rider was massive, filled with technical specifications. Detail after detail, each one critical to keeping the crew safe and the show operational.

And then, buried in the middle of these technical specifications, Article 126: no brown M&Ms.

When Roth walked backstage, if he saw even a single brown M&M in that bowl, he knew instantly that they hadn’t read the contract and would call for a complete line-check of the entire production. As he later explained, “Guaranteed you’re going to arrive at a technical error. They didn’t read the contract.” Sometimes those errors were life-threatening—girders that couldn’t support the weight, flooring that would sink, structural problems that could collapse the stage.

The brown M&Ms were a simple test that told Roth whether he could rely on work done by people he’d never met. If they didn’t catch the part about brown M&Ms what else did they miss? When you can’t check everything yourself, you need to find your brown M&Ms—one simple thing that reveals whether anyone checked anything at all.

The Verification Gap

We face the same challenge with AI systems today. We deploy agents to analyze documents, write code, draft contracts, generate reports. Then we stand backstage wondering: can we verify what they produced?

If verifying the work takes as much effort as checking every girder and cable yourself, delegation breaks down. Why delegate if checking the work takes just as much time as doing it yourself?

This might explain why AI coding agents have gained traction in software development. The verification infrastructure already exists. When AI suggests code, you run it to see if it works. You write tests to validate its behavior. You review it before merging. You revert it if problems emerge. The work is hard to do (writing correct code) but verification can be automated.

The software industry already handles delegation at scale. For example, consider a large software project like the Windows operating system. It requires coordinating work from people who’ve never met, spread across time zones and continents. The Windows operating system contains approximately 50 million lines of code. For Windows 8, Microsoft organized 35 feature teams, each with 25-40 developers plus test and program management—roughly a thousand people working on something no single person could comprehend in its entirety.

These developers don’t all know each other. A programmer in Redmond commits code that integrates with work from someone in Bangalore who’s collaborating with a contractor in Prague. Yet the system works because the software industry has built infrastructure for distributed trust: version control tracks every change, automated tests verify that new code doesn’t break existing functionality, code review processes catch errors before integration, continuous integration systems detect conflicts, and critically, everything can be reverted if something goes wrong.

Now contrast this with legal work or financial analysis. An AI system analyzes case law and drafts a legal argument, or processes financial documents and produces analysis. How do you verify either is correct? You’d need to check each citation, validate the reasoning, confirm the logic. The verification can take as long as doing the original work yourself. If supervising the AI takes as much effort as doing the work yourself, what’s the benefit?

The gap isn’t AI capability. The gap is verification cost. And unlike software development, these fields haven’t found their brown M&Ms yet—that simple check that reveals whether the complex work was done right.

So what would those checks look like?

Show Your Work

The answer might be simpler than we think. My elementary school math teacher had an approach that applies here. She told us repeatedly to: “Show your work.”

When we’d turn in math homework, she didn’t just want the answer. She wanted to see how we got there. Because seeing “x = 7” told her nothing. Did we understand the concept? Did we follow the right process? Or did we guess and get lucky?

When the answer was wrong, “show your work” let her identify exactly where our thinking went astray. Maybe we understood the concept but made an arithmetic error. Maybe we set up the equation wrong from the start. The work itself was the diagnostic.

The Hitchhiker’s Guide to the Galaxy has a famous joke about this. A supercomputer named Deep Thought spends 7.5 million years calculating the Answer to the Ultimate Question of Life, the Universe, and Everything. Finally, it announces: “Forty-two.”

The joke is that the answer is meaningless without understanding the question. But there’s a deeper problem: even if we knew the question, “42” tells us nothing about how Deep Thought arrived at that answer. We can’t verify its reasoning. We can’t check its work. We can’t identify where it might have gone wrong. We just have to trust that after 7.5 million years of computation, it got it right.

This is the problem with integrating AI outputs today. They give us the answer without an easy way of reviewing the work.

But what does “show your work” look like when the work is complex cognitive analysis rather than simple arithmetic?

Designing for Verification

I’ve been wrestling with this question while building an AI agent that processes company financial documents and analyzes them. This routine work could save human financial analysts hours of work.

But presenting just the final analysis recreates the Deep Thought problem. Here’s the insight you were looking for! But how did we get here? What assumptions did we make? Which documents did we pull these numbers from? The human reviewing the analysis would need to reverify everything, which defeats the purpose.

The solution was to make the system output its work the same way a human analyst would: spreadsheets with exposed formulas that professionals already know how to read. They can trace calculations backward, spot-check assumptions, modify inputs to test scenarios. But more importantly, the system includes a diagnostic layer—automated checks that surface whether source documents processed correctly, whether totals reconcile, whether there are calculation anomalies.

This shifts verification from “check everything or trust nothing” to “review diagnostics, spot-check anomalies.” The human doesn’t need to reverify every calculation. They glance at the diagnostic checks—green or red—then investigate only when something flags. Hours of verification work becomes minutes.

I’d found my brown M&Ms for financial analysis: those diagnostic checks. If they pass, the work is probably sound. If they don’t, I know exactly where to look.

This is one implementation of “show your work,” but the principle applies everywhere AI does complex cognitive tasks.

Which raises a larger question: why is every team building these verification systems from scratch?

The Missing Infrastructure

I spent weeks designing these Excel structures and diagnostic checks for one specific use case—financial document analysis. A legal team would need to build something completely different. A medical team would need something else entirely. Every domain solving the same fundamental problem independently.

This felt familiar. Before Git became standard, software teams had version control tools, but collaborating with large teams was still painful. People developed custom workflows and processes to work around the limitations. Then Git arrived with both better tooling and new ways of working. But it wasn’t automatic—developers had to learn how to branch properly, how to merge effectively, how to use the infrastructure.

That’s where we are now with AI in other domains.

What’s the Git for lawyers working with documents? For financial analysts collaborating on Excel models? These tools aren’t great for team collaboration even without AI in the picture. Adding AI to the mix won’t make verification easier unless both the tooling improves and people learn to use it properly.

Software development got lucky. The verification infrastructure existed before AI arrived. Other domains are building theirs now, one custom solution at a time.

Roth didn’t need to understand electrical systems or structural engineering. He just needed to walk backstage and glance at a bowl of M&Ms. That single check gave him a hint about the quality of the work.

Every field adopting AI needs to find its brown M&Ms—the checks that reveals whether the complex work was done right. Not systems that never make mistakes, but verification so simple that catching mistakes becomes easy and routine.

The question isn’t whether AI can do the work. It’s whether we can verify it did the work correctly without doing it ourselves.

What are your brown M&Ms?

An article titled “AI Agents can’t schedule meetings but promise to replace workers” has been making the rounds recently. In it, the author claims GPT-4o failed most basic office tasks in their test. And sixteen years and billions of dollars later, self-driving cars operate in a handful of cities under limited conditions.

The takeaway: AI agents can’t schedule meetings how will they take away jobs? There are many forms of this reliability argument I see floating around.

The numbers are sound and the logic feels air-tight.

But something about the argument feels off.

The reliability critique assumes technology succeeds by being better at existing tasks. If it can’t match or exceed current reliability standards, it’s not ready for adoption.

This seems obvious. But it’s not the whole story.

To understand why, we need to look at how technology actually gets adopted—not how we think it should.

Early technology is never as reliable as what it replaces. But that’s not the barrier to adoption we think it is. When something unlocks a capability that didn’t exist before, reliability becomes secondary. Sometimes a 30% success rate at something we couldn’t do before matters more than a 99% success rate at something that we already do. Innovation scholars from Everett Rogers to Clayton Christensen have documented this pattern: early technologies rarely win by outperforming incumbents—they win by redefining what “performance” means. History has many stories about this pattern, let’s look at a couple.

Fast But Fragile Beats Slow But Safe

In 1929, if you needed to send an urgent contract from New York to San Francisco, you had one option that worked: the railroad. Your letter would travel in a mail car, sorted and handled by postal workers who had refined their systems over decades. The journey took five days. But it worked. Mail arrived reliably, predictably, intact. The railroad companies had spent half a century perfecting this system.

Then the airmail service launched.

The first planes were modified military aircraft left over from World War I. They were temperamental machines that required constant maintenance. Weather grounded them regularly. Mechanical failures were common. And sometimes, they crashed.

According to USPS historical archives, in 1929 alone, fifty-one airmail planes went down. Nearly three dozen pilots had died in the previous decade trying to deliver mail by air. If you sent your urgent contract by airmail, you faced a chance your letter would burn up in a crash somewhere over the heartland.

The flying conditions were brutal. Pilots flew exposed biplanes left over from World War I—not fully enclosed cockpits, just open to cold rain and wind. Hot engine oil constantly splattered their goggles. They flew barely 50 feet off the ground so they could see railroad stations and polo fields to stay on course. One pilot who flew the demonstration route in 1921 drank coffee and stuffed newspaper in his jacket for warmth before continuing through near-crashes in the dark.

Business leaders knew these numbers. The contrast was stark: trains had crossed the continent reliably for half a century. The railroad system worked. Why would anyone risk an important document on such dangerous technology?

Yet businesses kept paying premium prices to send their most important documents by air.

The math was simple. Trains took 108 hours coast-to-coast. Airmail took 33 hours. For time-sensitive documents, one day of delivery at 70% reliability beat four-and-a-half days at 99% reliability. A contract that arrived in one day could close a deal before competitors even knew about it. A legal filing that arrived in one day could meet a deadline that four days would miss.

Speed had unlocked a capability that didn’t exist before. And that new capability was valuable enough to tolerate unreliability.

When Something Beats Nothing

The business world was unconvinced. As late as 1879, the Chief Engineer of the British Post Office declared that “The Americans have need of the telephone, but we do not. We have plenty of messenger boys.” The telegraph system worked reliably, with clear printed messages that left no room for mishearing or misunderstanding.

But the skeptics weren’t wrong about the telephone’s shortcomings.

Early telephone users described the experience as one of “feebleness and uncertainty.” The carbon granule microphones created scratchy, harsh sounds. Interference from nearby telegraph wires and electrical currents would nearly drown out the speaker’s voice. Weather created static. Long distances created echo. Call quality was so poor that one 1880 testimonial warned potential users: “strangers hearing through it for the first time may find themselves on that account disappointed.”

But telegraph service worked perfectly. Messages arrived intact, properly formatted, readable. You could send a telegram at 2 AM and know it would be delivered first thing in the morning. The system had been refined over decades. Why would anyone switch to a technology where you had to shout “Hello? Hello?” multiple times just to establish that someone was on the other end?

Yet within two years of Bell’s patent, the first commercial telephone exchange opened in New Haven, Connecticut with 21 subscribers. By 1880, Ithaca, New York had 100 telephone subscribers—described as “a larger number than has been obtained in so short a time in places even of twice the size.”

The telegraph could do many things better than the telephone. But it couldn’t do one thing at all: real-time back-and-forth conversation.

If you needed to negotiate a deal, telegraph required sending a message, waiting for a response, sending another message, waiting again. Each round trip took hours. A simple negotiation could stretch over days. The telephone, even with its terrible audio quality, let you have that entire conversation in minutes. You could hear hesitation in someone’s voice. You could clarify misunderstandings immediately. You could close deals while your competitors were still composing their first telegram.

The dimension that mattered wasn’t audio fidelity. It was synchronicity. And synchronous voice communication at 30% reliability beat asynchronous text communication at 99% reliability for any task that required real-time interaction.

The Pattern Continues

This same dynamic plays out today, though we often miss it while focusing on reliability metrics.

I tried Apple’s new Live Translation feature last month. You press both AirPod stems simultaneously and it activates real-time translation for in-person conversations. The feature launched in September 2025 with support for nine languages, processing everything on-device for privacy.

It’s laggy. The translations arrive a half-second behind the speaker, creating this awkward pause in conversation. Sometimes it misses words entirely. The accuracy isn’t perfect—nuance gets lost, idioms get mangled. If you tried to conduct diplomatic negotiations or close a complex business deal through it, you’d probably fail.

But here’s what it does do: it lets you have a conversation with someone whose language you don’t speak. Not a polished, perfectly understood conversation. A halting, imperfect, occasionally confusing conversation. But a conversation nonetheless.

Before this technology, what were your options? Hand signals. Translation apps where you type, wait, show your phone, wait for them to type, show their phone back. Maybe a professional translator if you planned ahead and could afford it. For spontaneous interactions—asking directions, ordering food, having an unplanned conversation with a neighbor—you had nothing.

The AirPods translation feature isn’t replacing professional translators. It’s not good enough for important negotiations or medical consultations. But for the thousands of small interactions where the alternative was frustration and miscommunication? Even at 70% accuracy with noticeable lag, it beats 0% capability.

The reliability critics would point out—correctly—that it fails too often for serious use. But they’re measuring the wrong dimension. The question isn’t “Is it as reliable as a professional translator?” The question is “Does it unlock conversations that couldn’t happen before?”

Same pattern as airmail. Same pattern as the telephone. Technology doesn’t win by being more reliable than existing solutions. It wins by making things possible.

The Question That Matters

The reliability critics are right about the numbers. AI agents do fail basic tasks. Self-driving cars do require perfect conditions.

But that’s not the question that determines adoption.

The question is: what dimension does AI unlock that didn’t exist before?

The pattern from 1929 still holds: when technology unlocks an impossible dimension, we tolerate unreliability. When it only promises to do existing tasks better, reliability matters enormously. For safety-critical systems—medical devices, aviation, autonomous vehicles—the bar is appropriately high. But even there, driver assistance features arrive before full autonomy, providing new capabilities while the technology improves.

So the next time someone shows you statistics about AI failure rates, ask yourself: what dimension is this trying to unlock? If it’s trying to replace something that already works, the reliability bar is high. But if it’s trying to make something possible that wasn’t before—even with significant failures—the math might work out differently than the skeptics think.

The future of AI may not look like perfect autonomous systems replacing human workers. It will look like imperfect tools unlocking capabilities we didn’t have, with humans adapting their workflows around what the technology can actually do. Just like businesses in 1929 learned to send documents both by air and train. Just like early telephone users learned to shout “Hello?” until someone answered.

Reliability will improve over time. But adoption doesn’t wait for reliability. It happens when something impossible becomes merely unreliable. And right now, AI is making a lot of impossible things merely unreliable. Real-time language translation, code generation, content creation, complex analysis—tasks that previously required specialized expertise or were simply too resource-intensive to attempt. We tolerate their unreliability because the alternative was having no capability at all.

The railroad worked perfectly too. That’s not what mattered.

Related:

They call it “human-in-the-loop”—the idea that AI systems will handle execution while humans provide oversight and judgment. Ethan Mollick calls it “cyborg management.” Sam Altman talks about giving everyone a personal AI team. The promise is elegant: machines do the work, humans make the decisions.

Over two years ago, when I started using AI for programming, I was clearly the one in the loop. I’d copy code from ChatGPT, paste it into my editor, read it line by line. The AI was a suggestion engine. I was the gatekeeper—code didn’t exist in my project until I understood it and approved it.

Then I started using Cline, an AI coding agent that runs inside VS Code. The workflow changed. Cline would propose file changes, show me diffs, wait for my approval. I’d review each change, sometimes reject it, sometimes accept it. It felt like collaboration. The AI would suggest, I would decide. I was supervising.

I’ve now switched to OpenAI Codex as my daily driver. The workflow has changed again. Now the AI tells me it made an edit (past tense). “I’ve updated the authentication flow.” The changes are already implemented. I can click to review them, but they’re often so extensive—hundreds of lines changed—that I find myself asking the AI to explain what it just did.

I’m not approving changes anymore. I’m getting status updates.

I tell myself I’m still supervising. But supervision requires understanding. And increasingly, the changes are too big, too fast, too complex for me to understand without asking the AI to teach me about its own work. When something breaks, I don’t debug it myself—I ask it to fix its own code.

The AI writes code, explains what it wrote, then continues coding while I nod along.

I’m not directing the work anymore. I’m the notification step in someone else’s workflow.

Each phase felt like an upgrade. Copy-pasting was tedious. Having Cline propose changes was more efficient. Having Codex just do the work is even faster. But somewhere in that progression, something inverted. The tools didn’t just get better at helping me code—they redesigned the relationship. The interface itself now assumes the AI leads and I follow.

This made me wonder: What if “human-in-the-loop” has the loop backwards? What if the AI is the system, and humans are just the API call it makes when it needs a “human judgment” flag set? What if we’re not the loop’s controller, but its sub-routine?

Analysis can map the territory we can see. Fiction can explore the implications of what we’ve mapped. The following is a thought experiment—a fictional narrative about where that inversion might lead.

2041

Eli was promoted to Director of Decision Analysis on a Friday in August. On Monday morning, he took the elevator to the seventh floor for the first time.

His new office had a window. Through it, he could see the Decision Analysis floor below—hundreds of identical workstations arranged in perfect rows.

The Automation Revolution started in 2034, when AI systems reached general intelligence. But they couldn’t complete the work. They could optimize, analyze, execute—but they needed human decisions to finish the last 20 percent. The problem was humans weren’t organized. There was no clear process for who made decisions when, or how to move automation forward when it hit those decision points.

The Office of Decision Analysis was created to provide the missing link. Trained analysts, clear hierarchies, trackable responses. The infrastructure that made automation work. Eli had been hired in the first wave, part of the early confusion while they figured out how to give machines the decisions they needed in time. The entire system would freeze if decision analysts didn’t respond fast enough. Over time, the system worked beautifully.

Now Director.

From his new office, he could see patterns he’d never noticed before. The terminals flickered in waves—decision points arriving in clusters, hundreds of analysts receiving requests within seconds of each other.

The synchronization was beautiful. And strange.

Eli sat down at his new desk. As Director, he now had access to system logs he’d never seen before. Audit trails. Decision aggregations. The architecture beneath the interface.

He opened his first report—a routine check of last week’s decision throughput. The data looked normal at first. Response times, accuracy rates, efficiency metrics. Then he noticed something in the detail view.

Decision point #47293. He remembered it—coastal infrastructure allocation, three competing priorities. He’d spent twenty minutes weighing the options before approving Option B.

But the log showed something different:

Analysts queried: 24
Responses received: 21  
Consensus decision: Option B
Non-consensus responses: 3 (discarded)
Late responses: 5 (post-decision, acknowledged)
  - Analyst IDs: HS-172, MK-408, Eli-325, RN-561, TM-193
Status: Complete

His ID. Among the late responses.

He’d assumed each decision was his alone. The system would send him a decision point, he’d evaluate it, he’d authorize it. One analyst, one decision. That’s how it was supposed to work in the early days—how it had to work, when the system would freeze without human authorization.

But they’d been sending the same decision to 24 analysts simultaneously. His careful deliberation was one vote among many.

And in this case, his vote hadn’t even counted. He’d taken too long. The system had synthesized the consensus and moved forward without him. But it had still sent him the acknowledgment: Excellent judgment. Humanity thanks you.

He’d never known.

He opened another report. Same pattern—multiple analysts, aggregated responses, late submissions acknowledged anyway. Then another. The system was collecting responses like training data, synthesizing them into consensus, moving forward.

He’d thought he was the driver. He was one of many hands on a wheel, and some of those hands—including his own—weren’t even touching it.

The Conversation

Tuesday morning, he went to find Cathy Martinez. She was Senior VP of Humanitarian Decisions, had been with the program since launch. If anyone would understand what he’d found, it would be her.

Her office was on the eighth floor, one above his. Through her window, he could see both the Director level and the analyst floor below. Two layers of terminals, all flickering in synchronized waves.

“Can I ask you something?” He kept his voice level. “The decision points are going to multiple analysts simultaneously. Has it always been like that?”

She looked up from her screen. “The aggregation? No, that came later. About two years ago. We needed to scale decision-making, but human decisions are inconsistent. Same inputs, different analysts would approve or reject based on... intuition, mood, how much coffee they’d had. Aggregation gave us consistency.”

“But some of those responses came in after the decision was already made.” He thought about his ID in the late responses list. “My vote didn’t count. I never knew. The UI never said there was a timeframe.”

“We A/B tested that.” She said it like she was discussing any other product feature. “When analysts received feedback that their response was late, they’d rush future decisions to avoid it happening again. Or they’d disengage—why put in the effort if you’re always behind? Either way, quality dropped. When they felt their response counted, they performed well.” She paused. “Better a good decision now than the perfect one late.”

“So we’re not making decisions. We’re providing training data.”

“We’re providing human judgment. The system samples us for the values layer it can’t formalize. Aggregation just makes it more efficient.”

“But some of us don’t even know our input was ignored.”

“That’s the optimization.” She said it simply, like it was obvious. “If analysts knew their specific vote didn’t count, they’d disengage. But the aggregate always counts. That’s what matters.”

He studied her face. She wasn’t defensive. Just pragmatic, explaining how the system worked.

“So we’re ceremonial?” he asked. “Like a constitutional monarchy. We go through the motions, but the real power is somewhere else?”

Cathy turned back to her screen. “Maybe. The system might have learned to predict us well enough that it doesn’t need us anymore. Maybe we’re a backup system. Or maybe we’re still essential and just don’t see the full architecture.” She clicked something. A soft chime: Excellent judgment. Humanity thanks you. She looked back at him. “But we’re here. The terminals are running. Decisions keep coming. So we keep responding. What else would we do?”

The System

He went back to his office. Through the window, he could see the analyst floor—hundreds of people at their terminals, responding to decision points, receiving acknowledgments.

His terminal was waiting. A decision point sat open: priority resource allocation, director-level judgment required.

He read the context. Three options, detailed projections. Complex trade-offs that supposedly needed human wisdom.

He thought about Cathy’s explanation. The A/B testing. The optimization. The acknowledgments designed to keep people engaged. It all made sense. Better a good decision now than the perfect one late. Scale required aggregation. Aggregation required keeping people motivated. The system worked.

But something about it was unsettling. The logic was sound. But he’d thought he was the human in the loop—the one driving the train, making the calls. Now it seemed he was inside the loop. A sub-routine the system ran when it needed a particular output.

His cursor blinked in the decision field.

Twenty-three other analysts were probably seeing this same decision right now.

He could approve, reject, or request more data. The system would proceed smoothly either way.

His cursor blinked.

Related: