sarah wilson

Full-stack developer focused on shipping delightful products.

Building an AI video interface looks straightforward at first: give the user a prompt field, a few generation settings, and a button.

The harder problem appears after the first generation.

Users rarely create one video and leave. They change the prompt, switch an image, adjust the duration, try another camera instruction, compare two results, and sometimes return to an earlier version.

That means an AI video product isn't really a single-generation interface.

It's an iteration interface.

While working around MiniMax H3 Max, I've been thinking about how faster video generation changes that product-design problem. When generation becomes quicker, the UI should stop treating every output as a finished asset and make experimentation easier instead.

The Basic Flow Is Too Simple

The obvious implementation looks like this:

```text
Prompt
↓
Generate
↓
Video
`

That works for a demo.

For repeated use, the actual flow is closer to:

```text
Prompt v1
↓
Generate
↓
Review
↓
Change camera instruction
↓
Prompt v2
↓
Generate
↓
Compare
↓
Change motion
↓
Prompt v3
↓
Generate
`

Once you look at the workflow this way, several product requirements become more obvious.

Keep the Generation State

A generated video should not exist without context.

At minimum, I want to associate each result with something like:

```ts
type VideoGeneration = {
id: string;
prompt: string;
inputType: "text" | "image" | "reference";
duration: number;
resolution: string;
createdAt: string;
parentId?: string;
status: "processing" | "completed" | "failed";
};
`

parentId is particularly useful.

Instead of treating every generation as an unrelated asset, it lets us represent revisions:

```text
generation_001
│
├── generation_002
│ └── generation_004
│
└── generation_003
`

Now the interface can answer a basic question:

Which result did this version come from?

Don't Overwrite the Previous Prompt

A common UI mistake is replacing the current prompt every time the user makes an edit.

That destroys useful history.

If a creator changes:

```diff

• Camera follows the car.

+ Camera tracks alongside the car at a low angle.
`

and the new result is worse, they should be able to see what changed.

For an iteration-heavy workflow, prompt history is not just an undo feature. It is part of the generation metadata.

Comparison Matters More as Generation Gets Faster

When generations are slow, users naturally spend more time preparing each attempt.

Faster generation changes that behavior.

Instead of asking:

> How can I make this prompt perfect?

the user can ask:

> What happens if I change only the camera instruction?

That makes side-by-side comparison increasingly useful.

A simple comparison state could be:

```ts
type Comparison = {
leftGenerationId: string;
rightGenerationId: string;
};
`

The UI can then show:

```text
Version 07 Version 08

[ video ] [ video ]

Camera: tracking Camera: static
Duration: 5s Duration: 5s

Prompt diff:

• tracking shot

+ locked camera
`

This is much more useful than forcing users to remember which downloaded MP4 came from which prompt.

Failed Generations Are Still Data

Another useful lesson is not to discard failures immediately.

A failed request can tell us:

* how often generations fail;
* which settings were involved;
* whether a particular input caused repeated problems;
* how long the request took before failing.

So I prefer keeping failure metadata even when there is no usable video:

```json
{
"generationId": "gen_1042",
"status": "failed",
"duration": 5,
"resolution": "768p",
"elapsedMs": 2810,
"errorType": "generation_failed"
}
`

Obviously, logs should be designed with privacy and retention in mind. There is rarely a good reason to dump every user prompt or uploaded asset into permanent application logs.

Speed Changes UX, Not Just Infrastructure

Performance discussions around generative video often focus on inference time.

From a product perspective, I'm more interested in what happens after latency becomes low enough that users generate repeatedly.

The interface then needs to support:

* version history;
* quick retries;
* prompt differences;
* result comparison;
* reference tracking;
* failure states;
* deliberate deletion.

Without these features, faster generation can simply produce a faster-growing Downloads folder.

With them, it becomes a structured iteration loop.

The Output Is More Than an MP4

The biggest design change for me is thinking of a generation as a record rather than a video file.

A useful generation object contains:

```text
input
+
prompt
+
settings
+
result
+
relationship to previous versions
`

The video is only one part of that record.

This approach makes the system easier to debug, makes experiments easier to reproduce, and gives users a clearer history of how they reached a useful result.

As AI video generation gets faster, I expect this distinction to matter more.

The interesting product question won't simply be:

How quickly can we generate a video?

It will be:

How quickly can a user understand the result, make one meaningful change, and test the next version?