Code is getting cheaper. A wrong decision is not.
Ask an AI builder for a dashboard because your team keeps missing approvals. A few minutes later, a dashboard appears. It has filters, charts and a reassuring progress bar. The approvals are still late.
Nothing crashed. The code did what it was asked to do. That is what makes the result dangerous: it is a convincing answer to the wrong question.
We have become very good at celebrating the speed of software creation. A prompt goes in, an interface comes out, and the demonstration ends before anyone asks whether the interface was needed. The inconvenient truth is that people often know what hurts at work long before they know what would fix it.
People arrive with problems, not specifications
The familiar AI app demo starts with an unusually articulate customer. They know the user roles, the data model, the workflow and even the colour of the buttons. Their prompt reads suspiciously like a product requirements document written by someone who has spent years building software.
Real life is not so considerate.
An employee says, “I need a system to track requests.” A manager wants “better reporting.” A shop owner asks for “an app to manage everything.” Those are starting points, not requirements, and each quietly smuggles in an assumption about the solution.
A request tracker will not fix an approval process in which nobody has the authority to make a decision. Better reporting will not correct information that was never captured accurately. A beautiful management app will not make a confused process any less confused.
This is hardly a new insight. The United Kingdom Government Design Principles explicitly warn that what people ask for is not always what they need. Its Service Standard says to design around user needs rather than a preferred technology, including AI.
The arrival of instant software does not make that advice obsolete. It makes ignoring it much easier.
The question that changed what I wanted to build
I came to this problem through something decidedly unglamorous: a conversation with my wife about her work. She wanted a tool to make part of her day easier. She could explain what was frustrating, but she did not arrive with a finished description of the software that would solve it.
I could have treated her first request as a specification and started building. Instead, the conversation kept returning to what was actually happening in her work and what she was trying to change. That gap between describing a frustration and defining a useful solution stayed with me.
It also changed how I think about access to software. Removing the need to write code is valuable. Removing the need to understand code while still requiring a person to think like a product manager is a much smaller revolution than it first appears.
That conversation eventually led me to start Senforma. We are developing an AI software platform that begins with structured questions about the user’s problem, goals and constraints before moving toward a custom software solution. The aim is to make the discovery process accessible to someone who has never written a product brief, not simply to make the programming step faster.
This is a company preparing for launch, not a claim of proven outcomes at scale. Nor is it an argument that other app builders never ask questions. The distinction we are trying to build around is what those questions can actually change, including the possibility that the user’s first request points to the wrong solution.
Questions are not an annoying delay
There is an industry temptation to treat questions as friction. If a user has to answer six of them before seeing a screen, perhaps the product has failed to deliver its magic trick.
But a good question is not a loading screen. It is an intervention that can prevent a bad decision.
Consider a user who asks for automatic reminders when a task is overdue. The obvious next step is to ask how often the reminder should be sent. The more useful first question might be why the task is overdue and who can unblock it.
If the problem is unclear ownership, reminders create more notifications and no more accountability. If an exception requires a second approval, the solution may need a decision rule rather than another alert. If the task is unnecessary, automating it merely preserves waste at a higher speed.
The difference lies in what the question is allowed to change. A superficial clarification polishes the requested feature. Genuine discovery can challenge the feature itself.
That is consistent with the ISO requirements engineering standard, which treats requirements work as a process of eliciting, analysing and validating needs rather than merely collecting a list of desired functions. The discipline existed long before anyone could generate an interface with a sentence.
The problem with a machine that always agrees
An assistant that immediately produces something attractive is easy to like. It is also easy to trust too much.
Imagine a user requesting a customer portal because clients repeatedly ask for updates. A portal might be the answer. But perhaps status updates are delayed because the underlying information is entered only once a week, or because the team has no agreed definition of “complete.”
Neither problem disappears when customers get a login page. The application simply offers a more elegant window into the same disorder.
The danger is not that AI asks no questions. Some tools already ask plenty. The danger is mistaking the presence of a question for evidence that the right uncertainty has been resolved.
Research points to the difficulty. In a January 2026 evaluation of two AI interview tools, Nielsen Norman Group found that the systems were useful for structured input but tended to stick to scripts rather than pursue unexpected insights. That was a small study of research interviews, not a verdict on AI app builders, but it illustrates why asking a question and conducting discovery are not interchangeable.
A genuinely useful system needs to recognise contradictions, revisit assumptions and sometimes say, “You may be solving the wrong problem.” It must also know when to leave a decision to the human being who understands the context and bears the consequences.
The best outcome might be no new app
Here is a test that makes most product demonstrations uncomfortable: can the system reach the conclusion that nothing needs to be built?
Suppose a team wants a new application for allocating work. After a careful discussion, it becomes clear that the issue is an unwritten responsibility rule, not a missing interface. The fastest software would be the wrong software. A clarified policy, perhaps supported by a small automation, may do more good.
Google’s People and AI Guidebook makes a similar point about finding a real user problem and asking whether AI uniquely adds value. Sometimes a simpler rule is preferable to an intelligent system.
That principle should not threaten people building AI products. It should make their products more trustworthy. A tool that can only recommend its own existence is not a great adviser.
A better test than how fast the screen appears
If we want to judge the next generation of application builders seriously, we should stop giving them perfect prompts.
Give them an unclear business problem instead. Let the user change their mind halfway through. Include a contradiction between what one employee wants and what another employee is authorised to do. Add an exception that occurs rarely but matters enormously when it does.
Then ask different questions. Did the system identify the hidden decision? Did it distinguish a fact from an assumption? Could it explain why it proposed a particular workflow?
Did it give the user a chance to correct the understanding before turning that understanding into software?
Finally, ask whether the resulting solution improves the actual process. A successful build is evidence that software was generated, not evidence that the original problem was solved.
The NIST AI Risk Management Framework playbook puts intended purpose, context, assumptions and limitations at the centre of understanding an AI system. That discipline matters just as much when AI is deciding what to create as when it is deciding what to say.
We have moved the bottleneck, not abolished it
Cheap code is a remarkable development. It may let more people create tools that previously required budgets, specialists and months of negotiation. That is worth celebrating without pretending every new application is progress.
The harder question is who helps a person understand their need before the software makes it permanent. In traditional projects, much of that work fell to business analysts, designers and experienced developers. Making those conversations disappear does not make the underlying decisions disappear.
We should want AI systems that make the questions more accessible, not systems that pretend the questions were never necessary.
If a machine can build almost anything I ask for, its most valuable response may occasionally be: “Why do you need that?”
From an unclear problem to early access
That is the question at the heart of Senforma. We are building a guided route from a problem described in everyday language, through requirements discovery, toward software designed for the actual need. We are currently preparing for launch and inviting people who want to explore this approach to join the Senforma early access waitlist.
About the author: Harel Uzan is the founder of Senforma, an AI software startup focused on structured needs discovery before software creation.
