The useful question is not “Can we?”
A quick output can leave a longer task unfinished. Its usefulness becomes clearer through the work needed to reach a result someone can use.
Imagine a tool that writes a report in seconds. Before anyone can share it, they have to check every line against the source material. The tool has made writing faster. It may have made finishing a report slower.
Producing a familiar account and verifying an unfamiliar one are different kinds of work. The second can require reconstructing the reasoning that produced the result. A demonstration ending at the generated document leaves that effort to happen somewhere offscreen.
Where the task ends
This is a problem of where we draw the task. A team may define the job as producing text. The person using the product may define it as sending a report they can stand behind. The gap includes checking, correcting, moving information between systems and explaining the result to someone else.
An improvement to one step matters through its effect on that larger sequence. But speed is not the only relevant outcome. The tool might help someone produce a report they could not previously complete, or improve its quality enough to justify more review. Comparing times without comparing the finished work can be as misleading as timing only the generated output.
First establish what a usable result means for this task. Then compare the current method and the proposed one through to that result. Include preparation, corrections, verification and transfer into the next part of the person's work. Notice which steps require scarce expertise: a process that saves routine typing while adding specialist review has changed the kind of capacity it needs.
The cost of changing methods
Switching adds costs too. A person with a dependable workaround already knows its limits. A new tool asks them to learn where it can be trusted and how to recover from mistakes. A useful comparison distinguishes the temporary cost of learning from work the new method will require on every use. Otherwise a promising tool can be rejected too early, or a burdensome one defended forever as unfamiliar.
The business also takes on continuing work: support, maintenance and explanations of the tool's limits. Cheaper development can make more ideas feasible without making all those obligations worthwhile. The adoption case and the operating case both need an answer.
The report written in seconds still has its appeal. We are curious about what that speed could make possible, including work someone could not do before. But the moment we would want to understand is the one when they are ready to send it. By then, the promise of the demonstration has met the rest of their work.