Folding Is the Only Sure Way to Lose

The AI paradox

Anyone running an engineering organization right now can see a gap opening up: AI is making code easier to produce, but generating code, finishing engineering work, and creating business value are moving at different speeds.

A recent NBER study of more than 500,000 GitHub developers estimated that, across generations of AI coding tools, commits rose roughly 240% while releases rose about 30%. The data is observational, and neither a commit nor a release tells you whether a customer got more value. But it's real evidence that more code isn't turning into proportionately more shipped work.

Overestimating the short term, underestimating the long term

In 1987, Robert Solow observed that you could see the computer age everywhere but in the productivity statistics. He was describing a puzzle in the data, not declaring that computers would never pay off. Today's gap is the same kind of puzzle, and it deserves the same attention.

Roy Amara put it best: we overestimate a technology's effect in the short run and underestimate it in the long run. Both errors come from the same place, forecasting from the early part of the curve.

Disruptive technologies rarely move in a straight line, so forecasts go wrong in one of two ways: you underinvest because the early gains look modest, or you commit hard to an arrangement that's about to change. Those two mistakes don't cost the same, though. Overcommit and you pay to rebuild some of what you built; wait and you lose the years of learning that tell you what to build at all. The real question is how much to commit at each stage of a technology's life.

Four phases of disruptive tech evolution

There's a pattern in how many technologies evolve. They show up as toys, get inserted into familiar workflows, open room for ways of working that weren't practical before, and eventually some of those approaches harden into the standard. I think of these as four phases, and they work like the betting rounds in a hand of hold'em: each one deals you more cards, and you get to decide again how much to put in.

Folding a bad hand is good poker; leaving the table altogether means you stop learning while the other players keep playing.

The toy phase ("the pre-flop")

Some technologies arrive looking like toys: hobbyist PCs, iBeer on the first iPhone, Will Smith eating spaghetti. Chris Dixon's point was that the next big thing often starts this way because its early capabilities don't satisfy people using established products, even as it improves along a path that eventually does.

The skeuomorphic phase ("the flop")

When a new capability arrives, we put it to work inside the system we already understand. In interface design, the term skeuomorphism refers to when we mimic a physical object in a digital form. Think about the Apple Notes app made to look like a yellow legal pad, or a voice recorder using images of a physical microphone. Here I'm using the term more broadly, for a new technology operating inside the assumptions of the old workflow - so think more about "workflow skeuomorphism".

For example, Paul David described how 19th-century factories ran on steam engines turning a drive shaft through the building, with belts carrying power to each machine. When electric motors arrived, owners often kept the shafts, the belts, and the layout, using motors to drive groups of machines. Putting smaller motors on individual machines made it possible to redesign the factory floor around the work instead of the power source. Electrification brought productivity gains along the way; it also made a different kind of factory possible.

The same model applies to how the early web put brochures and directories online, or the first generation of mobile squeezed websites onto small screens with "m-dot" sites.

The Cambrian explosion ("the turn")

Once we start working with the grain of the new capability rather than fitting it into the old system, we get what Jeff Bezos called a Cambrian explosion. In a 1999 interview, he compared the internet to the Cambrian era, when nearly every form of life got tried: the fastest burst of new species the planet had seen, and also the highest rate of extinction. Most of the experiments die, and a few of the survivors define what comes next.

Think about the evolution of mobile phones before the iPhone. Nokia, Motorola, Samsung, and everyone else threw every form factor at the wall: candy bars, flip phones, sliders, swivels, QWERTY slabs, and a Nokia that doubled as a game controller. Every one of those designs was a real product with real customers, and the industry had a confident view of where the category was going...and it was wrong.

One of my business school professors, Rebecca Henderson, along with Kim Clark showed why incumbents struggle here: when the change is in how familiar components connect, an organization's knowledge and routines are tuned to the old arrangement. So this phase too can often be misleading, because the frontier is still a set of experiments run with the tools and constraints of the moment.

The dominant design ("the river")

Eventually some experiments become the thing the ecosystem shifts toward. William Abernathy and James Utterback described how a dominant design emerges from a period of variation, and how, once it does, companies shift their effort toward improving production, cost, and distribution within the accepted form. Phones are the example: after the iPhone, the cacophony of form factors converged into the touchscreen slab, and manufacturers converged on a familiar shape while apps and business models kept changing on top of it.

This is the river: more cards are on the table, and you have a clearer view of where to place a bigger bet. But outside a poker game, no one tells you when the river has been dealt. You have to build judgment along the way and increase your commitment as the evidence warrants.

Where AI is now

Most enterprise AI use sits squarely in the skeuomorphic phase; or in poker terms, we're looking at the flop. We summarize meetings, draft documents, write code, and make support workflows more efficient. Those are worthwhile, and they leave us with the same artifacts, handoffs, and metrics we had before. The commits-versus-releases gap is an example of how you see that in the data: a stronger motor turning the same shaft.

Meanwhile, the Cambrian explosion has already started at the edges, where teams are trying different arrangements: agents working in the background, interfaces generated around a task, people supervising systems rather than performing each step. Some of those will become ordinary. Others will turn out to be elaborate workarounds for limitations that disappear with the next model.

It's hard to know what the dominant design will be at this stage. But AI is going to be everywhere, and the teams that learn to use it well will have an advantage over the ones that don't. You can't develop that judgment from the sidelines; you have to use the technology, see where it works and where it fails, and carry what you learn into the next hand. A modest gain inside today's workflow says little about the ceiling, and an impressive demo doesn't mean it'll become the standard.

Right about what comes next, wrong about where it ends

I learned this back when we were building our startup, Visible Measures. Around 2006, we moved away from treating processing as a separate cluster of servers per customer, and became early adopters of Hadoop. This allowed us to build a massively scalable "big data" processing engine in a shared computing architecture, which changed operating costs by an order of magnitude. We were a generation ahead of our competitors.

But at the time, we still needed to build that system in our own managed data centers, tying up capital, just as Amazon was introducing EC2. The cloud was visible, but it was young, and we were a venture-backed company selling to enterprises whose auditors needed to trust our infrastructure. Building our core system on a service that new would have been a bet-the-company decision. The future was visible before it was safe to stand on.

I can't say waiting would have been better. We might have saved capital; we might also have delayed the product, the customers, and everything we learned by running a real system. What stays with me is that we were right to play the hand; we'd already moved past the old architecture. Where we went wrong was the size of the bet: we went all-in on a layer that was about to move. We had a clear view of one part of the future and a much blurrier view of another.

The same thing will happen with AI. A team can be right to build around agents and still invest heavily in orchestration, review, or infrastructure that has to be rebuilt as models and costs change. Some of that work will last. Some will have a shorter life than anyone planned for.

The K-shape of delay

Not putting in your ante, or waiting for the dominant design, is the one strategy I’m sure loses. Teams putting AI to work learn where it helps, where it breaks, and how to build around it. The gap can open into a K: their judgment improves with use, while the teams waiting miss the experience that would tell them what to do next.

Talent. The best builders want to work where the real work is happening. Leaders can attract strong people who help them ship faster and draw others in. Teams that wait can lose people quietly, one Slack DM at a time, until the people left can’t build what the roadmap promises.

Data. AI-native products generate signals from prompts, corrections, and abandoned sessions. When teams use that feedback to improve the product, it can earn more usage and produce more signal. Fall behind and you’re missing the evidence that shapes what comes next.

Customer lock-in. When a competitor’s AI has eighteen months of context on a customer’s workflows, edge cases, and preferences, ripping it out can feel like an amputation. The longer the system is embedded in the work, the harder it can be to win that customer back, even with a better product.

These forces can feed one another: strong talent builds a product that generates useful feedback; a better product earns more usage and becomes harder to replace. None of that happens on its own, but a team that puts it together can pull further ahead.

How to build when the ground keeps moving

So what do you do? How do you stay at the table and pay your ante each hand, while not losing everything? Here are five things you can do (or your agent can summarize).

1. Anchor on the ideal experience

If the technology keeps moving, you need something that doesn’t. The customer’s ideal experience is the closest thing to a fixed point. A rider wants to get where they’re going without thinking about it; a support customer wants the problem never to happen; an engineer wants the idea in production. Those outcomes hold even as the models, interfaces, and workflows underneath them churn.

I wrote about this in Design for the Ideal, Then Negotiate Reality: define the ideal experience first, then challenge each constraint before designing around it. The skeuomorphic phase is what you get when you pre-concede to the old workflow, treating the summary, the PRD, or the ticket queue as givens instead of compromises someone made for a world with fewer capabilities.

Commit hard to the outcome; hold the implementation loosely.

2. Live at the frontier

You can’t build for a future you’ve only read about. You have to use the technology yourself, including the parts that are unreliable, awkward, or disappointing. Think of it as the ante: the price of being dealt in at all, and the cheapest bet you’ll make.

In the late 1990s I was at Microsoft working on Money, and we knew the internet was going to change the world desktop software had been built for. One way to understand it was to participate: buy things online when people were still wary of it, and buy clothes rather than just books. We learned far more by living it than we ever could have from consultants, user research, or Wired.

For AI, that means being a heavy personal user. Put the claims to work: where does the tool help, where does it fail, and which workaround did you need last month that you don’t need today? You can’t delegate fluency; someone else’s summary won’t give you the same judgment.

Make that learning visible across the organization, too. An engineer building an agent, a designer testing a new interface, and an operator resolving a customer problem will hit different constraints. Give them a way to compare notes and you build a picture no one person could assemble alone.

3. Contain it, don't ban it

The frontier usually shows up before anyone invites it. People are already running agents in personal accounts and one-off scripts, with access nobody formally granted, the same way employees once carried PCs into the office and built spreadsheets IT never saw. It’s messy, and it’s also a signal about where the value is; the people doing it know what needs to be done and found a faster way to do it.

Ban it and it goes underground, along with the enthusiasm you’ll need later. Ignore it and you end up with work nobody can see or audit. Give it somewhere legitimate to happen: bounded permissions, sandboxed environments, synthetic data where the workflow is sensitive, a record of what each agent touched, and clear safeguards for the people affected. Contain it enough that you can see it and trust it, and leave it loose enough that the people closest to the work keep building.

4. Send out scouts

Personal use gives you a feel for the technology. You also need teams with the people, tools, and authority to test it against real problems.

Carve out a lab, or a small set of teams, that can work beyond the workflows the company is ready to standardize. Give them a customer problem worth solving and enough access to do meaningful work. Their job is to expose assumptions, find failure modes, and show the rest of the organization what’s become possible, not to produce a slide deck about someday.

Scouts need a path to real use inside those same guardrails. If every experiment waits for a complete enterprise architecture, the organization atrophies while the technology keeps moving.

5. Know when to go all-in

A promising experiment and a system the business depends on deserve different levels of engineering. Build enough to learn, then raise the investment as you see repeat value and understand the risks.

I’ve written about this as paramedics, ER teams, and surgeons. The paramedics work close to the problem and look for signal; the ER stabilizes approaches that show repeat value; the surgeons build the dependable systems the business runs on. A healthy organization plays all three at once, like a player working several tables, because its problems don’t carry the same level of certainty.

Underinvest and you ride the shallow line. Harden a frontier experiment too early and you climb fast, then flatten against the constraints you built in. A redesign often dips first, while you pay for new processes and skills, then bends upward. For the first stretch the hardened system wins every quarterly review, which is exactly when the redesign gets defunded.

The outcome and safeguards (privacy, accountability, the ability to investigate failures) can be durable while the model, orchestration framework, and interface stay provisional. Be deliberate about which choices you harden into contracts, architecture, and process.

Write down the assumptions behind big commitments, decide when you’ll revisit them, and give someone the authority to act when the evidence changes. Flexibility has a cost, and sometimes the right call is to accept lock-in for speed or reliability. Make that trade with your eyes open.

Stay at the table

Just as you can’t see the other players’ hands when you place a bet, you won’t get a clean signal of where a new technology will end up before you have to decide how much to put in. Some of what we build now will last longer than we expect; some will be obsolete by the time you finish reading this.

So place the bet anyway. Anchor on the ideal, live in the technology, contain the experiments, and send out scouts. Pay attention to what worked, what didn’t, and what changed; the more you learn from the hands you play, the better your sense of which bets to fold, which to keep playing, and when it’s time to go all-in.