The prototype is the spec.

I land in a familiar meeting. The product direction is already settled, everyone agrees on what we are building, and the only real question left is the one nobody can answer from a slide: how should this thing actually feel to use? So the request comes, the way it always comes. Write the spec.

Here is the belief I keep running into, and it is a reasonable one: a specification is how a team agrees on what to build. You write down the intended behavior, everyone signs off, engineering builds to the document. Clean, orderly, accountable.

Does it work? Sometimes. But a written spec has a quiet problem. It describes the behavior you want, in prose, and prose loses fidelity every time it changes hands. The designer means one thing, the words say a second thing, the engineer reads a third thing, and three weeks later you are all in a room arguing about a sentence instead of looking at the product. The document was supposed to remove ambiguity, and instead it stored it.

On Companion this was going to hurt more than usual, because Companion is an AI assistant living inside the BigCommerce merchant admin, and you cannot describe the feel of a conversational interface in a paragraph. You have to use it. A model that answers in 300 milliseconds feels like magic, and the same model answering in three seconds feels broken, and no spec on earth captures that difference. So we did not write one.

We built the answer instead. A working prototype, the assistant live in the admin, handling real queries, exposing the exact interaction the engineers would go on to implement. The document did not describe the behavior. The prototype was the behavior.

A few things made that possible, and they are worth stealing

1. No dedicated backend. The prototype ran against the platform's existing REST and GraphQL APIs, with the language model orchestrating those calls rather than a shiny new service standing behind it. That one decision kept the whole thing honest about production surface area, and it kept iteration cheap. Cheap enough that we could change the interaction every single day, which, it turns out, is the only way you actually find how the product should behave.
2. The model as the search the platform never had. The merchant admin is deep, oh boy is it deep, and the settings that matter are the ones you visit twice a year and can never find the second time. So we used the model as the retrieval layer the platform was always missing: you say what you want in plain language, and it resolves to the right screen, the right record, the right number. A five-step chore collapses into one stated intent.
3. The prototype became the reference. When it was time to build for real, engineering did not build to a document that approximated the product. They built to the product. No reinterpretation, no lost fidelity, no meeting about what a sentence meant.

None of this means specs are useless. If the open question is scope, or compliance, or what the system must never do, write it down, please, write all of it down. But when the open question is interaction quality, and more and more these days it is, a document can only promise you an answer while a prototype hands you one. The cost of building the real thing early has collapsed, and the old instinct to describe first and build later has not caught up to that yet.