Letting AI Make the First Guess

We were designing an agent-driven creation flow — the kind where a user describes an idea and an agent builds something concrete from it. The most natural design was obvious: agent asks questions first, learns what the user wants, then generates.

This felt right. We were listening carefully before acting, not guessing and then forcing the user to undo our mistakes.

But when we built it and put it in front of real users, I noticed something that took a while to understand: some users, after answering three or four questions, would stop. Not because the questions were bad. And then they'd say something like — "Can you just go ahead and build something? I'll tell you if it's wrong."

We tried cutting the questions from five to three. The same thing kept happening. Which told me the problem wasn't the count.

Here's what I eventually understood: when we designed the "ask first, then generate" flow, we were handing the user a job — a job that, in a traditional design process, belongs to the designer.

A designer's job, before a project starts, is to take a vague, outcome-oriented wish and translate it into a series of specific, process-oriented decisions.

A user might want "something that helps me track how much I spend each day." That's an outcome — what they feel when they imagine it: convenient, clear at a glance, no math required. But if the agent starts asking, it asks things like: "Does this need to connect to a bank API? Should data be stored locally or in a database? Do you need multi-user support?"

Every one of these is a legitimate question. A real product does need to make these calls. But for the user, each question requires a jump — from "I want something that feels easy and clear" to "how should this thing's internal architecture work?" That's not one step of complexity. That's a different mode of thinking entirely, and it's one that takes professional training to do fluently.

Users can answer these questions. They might even go look things up. But the answering itself is a burden: they're doing something they shouldn't have to do, just to keep the conversation going. Cutting the question count didn't fix this because the underlying problem wasn't quantity. Even with three questions, users still had to do "translate a vague feeling into a set of specific, internally consistent decisions" — which is exactly as hard as the designer's job. We didn't reduce the cognitive load. We put it on installment.

When I understood this, the question changed from "what should we ask?" to "who should do the translating?"

These two positions look similar — both involve the user giving input — but they ask for very different mental operations. "What do you want?" requires abstract-to-concrete translation: creative work. "Is this right?" requires concrete-to-concrete comparison: evaluation.

Evaluation is something almost everyone can do naturally. We do it constantly, without training — "this doesn't feel right," "this is pretty close," "this part is wrong." Translating abstract desire into specific decisions is a skill most people have never needed to develop.

There's a hesitation I had about this approach. Using the agent's assumptions to fill what the user hasn't said yet — isn't that overstepping? Deciding for the user before they've had a say?

I've landed on a different way of thinking about it.

If a designer prepares a rough concept sketch before a client meeting — even if half of it is guesswork about what the client might like — that sketch is not considered presumptuous. It's considered useful. It gives the client something to point at. And "pointing at a thing and saying what's wrong" is much easier than "describing something that doesn't exist yet."

The assumption's purpose isn't to replace the user's decision. It's to lower the cost of expressing an opinion. Instead of having to conjure an image from nothing, the user starts with an image already in front of them. Placeholder details and guessed choices create the conditions for clear feedback — because vague artifacts give users something specific to push against.

One important note: this approach fits creative, iterable tasks — generating an initial draft, producing a first design pass — where "wrong" means "let's adjust," not "serious damage done." For high-stakes, irreversible decisions, you should stop and ask rather than assume. These aren't in conflict — they apply to different kinds of tasks.

"Generate first" is not always the right default. There's a clear case where "ask first" is the better approach.

When the user is an expert, asking first respects their expertise — it lets them direct efficiently, without the detour of reviewing a draft they'd immediately discard. These users don't need a starting artifact; they need their instructions followed.

The reversal is designed for a different situation: users who have a relatively clear internal image but for whom language is lossy — translating that image into words loses detail or distorts it. A concrete artifact is lossless — they see exactly what they're judging, with no translation step. Most users of a general product sit in this second camp. Which means the default should probably be built around their experience.

What I've come to believe is this: a well-designed agent-driven flow should do the designer's work first — translate the user's vague intention into something concrete and specific, even imperfectly, even with obvious placeholders — and then give users the job they're actually good at: looking at a specific thing and telling you what's wrong.

This isn't "ask fewer questions." It's rethinking which kind of thinking should fall on which side of the collaboration. The harder thinking — translating from abstract to concrete — belongs to the system. The user's job is to judge something real.

That's not a small UX optimization. It's a reorientation of where the work lives in a human-agent creative flow.