The demo is not the product

The AI demos are getting very good, very fast, and I find that both exciting and destabilizing.

There is a particular energy in a room when a capability crosses from interesting to obviously something. People start rearranging roadmaps in their heads. The technology invites imagination, and impatience right behind it. I understand the impatience. If a model can hold a natural conversation, reason across context, and handle a task that used to take brittle logic, it is hard not to want the future this quarter.

But I keep coming back to the distance between a demo and a product.

A demo has a prepared path. A product has users.

A demo runs in good conditions. A product runs on old phones, in noisy rooms, on weak networks, against messy accounts and unclear intent and people in a hurry. A demo can recover by starting over. A product has state. For assistant work this is sharper than usual, because the user often does not want an answer — they want something done. Set the alarm. Send the message. Control the device. Keep the thread when they move from the watch to the phone. Do it fast enough to feel local, private enough to trust, and recover cleanly when the action fails. The model can be brilliant and the product can still disappoint.

So the work I care about is not only making the capability better. It is deciding where the capability belongs, what system wraps it, what holds it to a contract, how failures surface, and how the person stays in control. On-device matters because latency and privacy are not implementation details. Server fulfillment matters because the user asked for something to happen, and it has to happen. The handoff between phone and cloud matters because no user should have to understand our stack.

I’m optimistic for a different reason. The capability is finally real enough that product judgment matters more, not less. The model opens the door. The product still has to decide which rooms are safe to walk into.