The Most Useful AI Feature Might Be a Better Question
A lot of AI builders are getting better at answering prompts.
But I’m starting to think the more interesting capability is asking better questions before the build starts.
Imagine typing:
Build me a booking app.
The obvious response is to start generating screens.
But there are a few questions that probably matter more first:
Who is booking?
Who is accepting the booking?
Does someone need to pay?
Is availability fixed or dynamic?
Does the business have one staff member or ten?
What actually needs to exist in version one?
Those answers can completely change what should be built.
And that’s the part I find more interesting.
The question isn’t only:
“How fast can AI build this?”
It’s also:
“Can AI help me avoid building the wrong version?”
Faster building can create a different problem
When implementation gets cheaper, adding more starts to feel harmless.
Need notifications?
Add them.
Team accounts?
Sure.
Analytics?
Why not.
A mobile version?
Maybe that too.
The problem is that a bigger first version doesn’t always give you better answers.
Sometimes it gives you more noise.
If ten things are happening at once, it becomes much harder to understand what users actually care about.
That’s why I think AI builders may need to become better at reducing scope, not just expanding it.
Sometimes a good AI should interrupt you
This is something we’ve been thinking about at built.new.
I’m involved with the project, so I’m obviously close to the problem.
But the part I’m more interested in isn’t how much the AI can generate.
It’s whether it can help narrow the idea before building the wrong version.
Who is this actually for?
What problem are we solving first?
What belongs in version one?
What can wait?
What are we trying to learn from the first real users?
Those questions aren’t as flashy as generating five screens in 30 seconds.
But they can completely change the quality of what gets built.
I’d rather have an AI ask me one annoying question now than help me build five unnecessary screens faster.
A booking app is a good example
Let’s say someone wants to build a booking product.
The first instinct might be to generate:
- user accounts
- staff accounts
- payments
- notifications
- loyalty points
- analytics
- reviews
- referrals
- subscriptions
- admin dashboards
All of those might eventually make sense.
But maybe version one only needs:
- availability
- booking
- confirmation
That smaller version gives you a cleaner question:
Will people actually use this flow?
If the answer is yes, great.
Now you have a reason to add the next thing.
If the answer is no, you learned before spending time polishing features nobody needed.
AI should probably help with judgment, not just execution
For a while, the benchmark for AI builders has mostly been output.
How fast can it generate?
How many screens?
How many integrations?
How much code?
Those things matter.
But I think there’s another benchmark that might become more important:
How much unnecessary product did the tool help you avoid building?
That’s harder to show in a demo.
But for someone actually trying to build a useful product, it might matter more.
The future of AI app building probably shouldn’t only be:
“Tell me what you want and I’ll build it.”
It could also be:
“Before we build that, do you actually need it yet?”
And I think that’s a much more interesting direction.
When you use an AI coding or app-building tool, would you rather have it simply follow instructions, or occasionally push back and ask better questions?

Top comments (0)