"Let's start building and see what emerges" is a reasonable approach for some types of creative work. For AI assistant projects, it's one of the most reliable ways to waste time and budget.
Here's why — and what to do instead.
The problem with emergent scope
AI assistants are not self-defining. They need to be told what they know, what they can do, what they should say when they don't know the answer, and how they should behave in every scenario they're likely to encounter.
When scope is undefined at the start, each of these decisions gets made during the build — often inconsistently, often without the client's awareness. The result is a system that's a collection of unplanned decisions, held together by assumptions that were never discussed.
When the client uses it for the first time, they encounter all of these decisions at once — and most of them weren't what they had in mind.
What "figuring it out" actually costs
Undefined scope creates rework. Every time a decision made during the build turns out to be wrong, something has to be rebuilt. In AI assistant projects, where the decisions compound, rework is expensive and slow.
It also creates friction between the client and the builder. When scope wasn't defined upfront, disagreements about what was "supposed to happen" become impossible to resolve — because nothing was supposed to happen.
What clear scope looks like
Before building anything, we define: what the assistant knows, what it can do, how it handles uncertainty, what success looks like.
This takes time upfront. It saves multiples of that time during and after the build. And it gives both sides something to point to when questions arise: the blueprint, agreed before anything was built.
"We'll figure it out as we go" is a way of deferring decisions, not a way of making better ones. We've never seen it produce a better outcome than planning. We have seen it produce a lot of expensive confusion.