The Prompt-to-Edit Workflow (What to Fix in Post)

TL;DR: Not every flaw in an AI-generated clip is a prompt problem. Colour, pacing, trims, stabilisation, audio, and text overlays are almost always cheaper and more reliable to fix in an editor than by re-rolling the generation. Subject, composition, camera move, and lighting direction are prompt problems; no edit invents a shot that was never generated.

What Actually Belongs in the Edit, Not the Prompt?

Six things, and all of them are ordinary editing work that has nothing to do with AI. The common thread: every one of them can be handled by subtracting from or rearranging footage that already exists, which is exactly what an editor is built to do.

Colour. A cast, a flat grade, or a mismatch between two clips pulled from two different generations (or two different vendors, if you're mixing a Veo shot with a Kling shot in the same sequence) is a five-minute fix in any editor with a scopes panel. Re-rolling an entire generation to chase a colour value is a paid attempt spent solving a problem your NLE already solves for free, and it risks changing the one thing you didn't want touched: the subject, the framing, the lighting that was already right.

Pacing, once the clip exists. This is the one worth pausing on, because pacing genuinely is something you can ask for up front. Google's own video generation prompt guide documents a "Temporal elements" section with a "Pacing" sub-heading, giving "slow-motion", "fast-paced action", and "time-lapse" as example phrases you write directly into the prompt (read September 3, 2026). That's real prompt vocabulary, not a parameter, and it works before you generate. Once a clip already exists at the wrong pace, though, a re-roll risks changing the subject, the framing, or the lighting along with the speed, because you're not editing the existing generation, you're asking for a new one. Retiming the footage you already have in an editor keeps everything else intact, and it costs nothing beyond the time it takes to drag a speed handle.

Trims. Cutting a clip down, or cutting between two clips, is what an editor is for. Nobody should be re-rolling a whole generation because the last two seconds ran long, or because the shot needs to start half a second later to land on a beat. That's a timeline decision, not a generation decision, and it's true regardless of which vendor produced the source clip.

Stabilisation. A shaky or drifting shot is a stabilisation pass, the same as it would be on footage from a real camera on a real gimbal that had a bad day. Several editors ship a one-click stabiliser that handles this better than hoping a second generation comes out steadier than the first. More on why below, because one vendor's "camera lock" parameter is not the safety net it looks like.

Audio. Music, sound effects, and dialogue timing are mixing and sound-design work, full stop. Some current video models generate native audio alongside the picture and some don't, and that split matters for what you're starting with (our AI video sound design piece covers what each vendor actually documents there), but either way a proper mix pass, levels, ducking, a music bed that doesn't fight the dialogue, happens in an editor. No prompt phrasing replaces a sound mixer's ears.

Text overlays. Captions, lower thirds, and on-screen text belong in post, not in the generation. Rendering text as a baked-in part of a generated frame is a genuinely hard problem for current image and video models, so treating on-screen text as a separate layer you add afterward sidesteps that failure mode entirely instead of fighting it across three or four expensive re-rolls hoping the letters land legibly this time.

What's Actually a Prompt Problem?

Four things, and none of them are fixable after generation, because each one is information the model either put into every frame or never generated in the first place:

Subject. If the model drew the wrong thing, the wrong number of people, the wrong product, the wrong species of dog, an edit can crop around it or grade it, but it cannot turn the wrong subject into the right one. That's a rewrite-and-re-roll problem every time, and no amount of colour work changes what's actually in frame.

Composition. Framing, blocking, and where things sit in the shot come from the prompt (or a reference image, on models that accept one). A crop can trim a composition down to a smaller piece of what's already there; it can't invent a composition, a different angle, a different arrangement of subject and background, that was never generated. If the shot is composed wrong, the fix lives in the next attempt at the prompt, not in the timeline.

Camera move. A dolly when you wanted a static shot, or a pan in the wrong direction, is baked into every single frame the model rendered, because camera motion in a generated clip isn't a separate track you can disable. It's part of the pixels. There's no post-production fix for a camera move you didn't ask for, short of a full rebuild from a different prompt, and stabilisation software won't help either, since the clip isn't shaky, it's deliberately moving in the wrong direction on purpose. Getting the language right the first time matters more here than almost anywhere else in the prompt; our camera movement vocabulary reference exists specifically so this is a rewrite you get right on the first attempt, not the third.

Lighting direction. Where the light falls, and from which direction, is set at generation time and is part of the same baked-in problem as camera move. Grading can shift colour temperature and contrast after the fact; it can't relocate a light source that was rendered on the wrong side of the subject, because the shadows, highlights, and falloff were all computed against a light that isn't where you wanted it.

The dividing line is simple once you say it out loud: an edit can subtract from or rearrange what was generated. It cannot add information the generation never produced. That's the whole test, and it holds regardless of which vendor you're generating on.

Where the Line Gets Blurry: Fields That Look Like Parameters but Aren't

A few vendors publish something that reads like a real, reliable control. Checked against each vendor's own documentation, most of them are closer to prompt wording wearing a parameter's clothes.

Kling generates at a fixed frame rate, and there's no field to change it. Its 3.0 Omni documentation states the output "is based on 24fps to 60fps (the frame rate for generating videos is 24fps)" (read September 3, 2026), which describes an uploaded reference video's acceptable range, not the output. The output is 24fps, full stop, with no request parameter anywhere in the endpoint that touches frame rate. Read quickly, the 24 to 60 range looks like it might mean you can ask for a smoother 60fps clip; read closely, the parenthetical settles it, and the output is fixed regardless of anything in your request. Any speed change on Kling footage, faster or slower, is a post-production frame-rate conversion built on top of a fixed 24fps source, not a setting you can pass at generation time.

Seedance's camera_fixed is the most candid vendor admission in this whole space. It's a real boolean field, defaulting to false, but BytePlus's own docs describe what setting it to true does: it will "append the fixed camera instruction to the user's prompt, but the actual result is not guaranteed" (read September 3, 2026). Read that sentence again. The vendor's own reference documentation is telling you, in writing, that its camera-lock field doesn't lock anything, it just adds a sentence to your prompt and hopes. That's the honest answer to why a "locked" shot can still drift: the field never promised otherwise. If a shot needs to be genuinely stable for a cut, don't spend a second generation hoping camera_fixed behaves differently the second time. Stabilise the footage you already have; it's the only step in this chain that actually guarantees the result.

Neither of these is a criticism of the vendors. Kling's fixed frame rate is a reasonable engineering choice, and BytePlus documenting camera_fixed as unreliable rather than overselling it is more candor than most fields in this space get. The point is narrower: read what a field actually promises before you build a workflow that assumes it promises more.

Why Is Reframing for a Different Placement Usually a Post Job?

Because aspect ratio is one of the few things most vendors actually do treat as a real parameter, and that cuts against you when the option you need isn't on the list.

Veo 3.1's aspectRatio field accepts exactly two values: "16:9" (the default) and "9:16" (read September 3, 2026). There's no third option, and no prompt phrasing that adds one; the field is a strict enum on the request, not a description you can write your way around. If your placement needs a square crop for a social grid or a 4:5 frame for a feed post, that reframe happens after generation, by cropping or outpainting in an editor, because the generation itself was never going to produce it.

Kling draws the enum differently, and this is exactly why checking per vendor matters instead of assuming a shared answer. Kling's settings.aspect_ratio field accepts 16:9, 9:16, and 1:1 (read September 3, 2026), so a square placement that's a forced post-production crop on Veo is a native generation option on Kling. Neither vendor is more "correct." They simply enforce different lists, and the only way to know which list you're working against is to read that vendor's own request schema before you commit a shoot to a specific placement.

This is worth checking before you shoot, not after. A vendor's aspect-ratio options are usually published on the same page as the rest of its request schema, and it takes thirty seconds to confirm whether your target placement is even possible to generate natively before you commit a budget to a shoot that assumed it was.

What Does This Look Like on One Actual Clip?

An illustration, not a measurement, to make the split concrete: say a generation comes back with a product shot that's well composed and correctly lit, but the camera drifts slightly to the left over the ten seconds, the colour reads a touch warm next to the rest of the sequence, and the clip runs two seconds longer than the cut needs.

That's one prompt problem and two edit problems in the same generation, and they don't get the same fix. The drift is a camera-move problem: it was baked into the motion the model rendered, so no stabiliser truly removes deliberate movement the way it removes an accidental shake, and if the brief called for a locked shot, the honest fix is a rewrite specifying a static camera and a re-roll. The warm colour and the two extra seconds are both edit problems: a grade pulls the temperature into line with the rest of the sequence, and a trim removes the two seconds nobody needed, and neither one touches the footage that was already right.

Spending a re-roll on the colour or the trim wastes a generation on something an editor fixes in under a minute. Spending an editing pass trying to remove camera drift that was never accidental in the first place wastes the opposite way: time spent fighting footage that needed a different prompt, not a different tool.

What Does the Actual Handoff Look Like?

A short checklist, in the order it actually pays off, before you decide whether the next move is a re-roll or a timeline:

Before re-rolling, check:
1. Is the problem subject, composition, camera move, or lighting direction?
   -> Yes: rewrite the prompt and re-roll.
   -> No: it's an edit. Don't spend a generation on it.

2. Is a "parameter" you're relying on actually a request field,
   or prompt wording the vendor documents as unreliable?
   -> Check the vendor's own docs before you trust it twice.

3. Does the fix only remove or rearrange what's already there
   (trim, grade, retime, stabilise, mix, caption)?
   -> That's an edit. It stays an edit no matter how many times
      you're tempted to re-roll instead.

Structured, field-aware prompts make the left side of this checklist shorter to begin with. If you're generating on Veo and want camera, lighting, and composition specified precisely enough that you're not guessing after the fact, our JSON video prompt templates for Veo 3 are built for exactly that handoff: get the prompt-side variables right once, so the only work left after generation is the honest editing kind. And if you're weighing whether a re-roll is even worth the money against a quick fix in post, our companion piece on what a usable clip actually costs runs the arithmetic on exactly that trade-off.