The workflow that most AI sound generation tutorials describe is a single pass: write a prompt, generate a result, accept it or discard it. That is not how sound design works, and it is not how the tools are actually best used. A prompt is not a command. It is a working document that you edit in place until the output matches what the game needs.
The difference matters because restarting from scratch is expensive. Every new prompt is a new generation, and every generation is a new set of variables. If you change three things at once and the result is worse, you do not know which change caused it. If you change one thing and the result is better, you have learned something you can reuse on the next sound.
This article is about the iteration model. It covers the structure of a working prompt, the specific changes that are worth making and the ones that usually are not, and the patterns that produce usable game audio in fewer passes. The prompt-writing guide covers the initial construction of a prompt; this article is about what happens after the first generation comes back.
Why does a one-shot prompt produce a sound you cannot fix?
A one-shot prompt forces you to describe the entire sound in a single description, and then accept whatever the model interprets from that description. The problem is that you usually do not know which part of the description is doing the work.
A prompt like “short metallic impact, sharp attack, no tail, sci-fi UI” contains at least four distinct instructions. If the result is too bright, you do not know whether it is the “metallic” or the “sci-fi” or the “sharp attack” that is pushing the brightness. If the result is too long, you do not know whether “short” is being overridden by “impact” or “metallic.”
The fix is to treat the first generation as a draft, not a verdict. The prompt that produced the draft is the starting point for the next generation, and the changes you make to it are the experiment. The output tells you whether the experiment worked.
This is not a new idea. The InstructFX2FX research on audio effect refinement describes the same problem in a different context: a single instruction freezes the result, while real mixing unfolds in layers, with each adjustment building on the last[citation:1]. The parallel to sound generation is direct. A prompt that is revised in place is a conversation with the model. A prompt that is discarded and rewritten is a series of disconnected commands.
What does a working prompt actually look like?
A working prompt is not longer than a one-shot prompt. It is structured differently. Instead of describing the entire sound in a single sentence, it separates the sound into the components that the model treats as independent variables.
The components that are worth separating are the ones that the model can change without affecting the others. For sound effects, the useful components are usually:
| Component | What it controls | Change it when |
|---|---|---|
| Source | The object or material making the sound | The sound is the wrong material |
| Action | What is happening to the source | The sound feels static or wrong for the event |
| Character | Brightness, weight, harshness | The sound is too sharp, too dull, too heavy |
| Duration | How long it lasts | The sound is too long or too short for the game |
| Environment | Room character, distance | The sound feels too close or too distant |
The Adobe Firefly prompting guide makes a related point: the prompt should describe what the sound actually sounds like, not the scene around it, and the generator is designed to produce one sound per prompt[citation:3][citation:6]. That single-sound constraint is what makes the component separation useful. If you are trying to generate a complex soundscape in one prompt, you cannot isolate the components. If you are generating one sound at a time, you can.
A working prompt for a sci-fi UI click, written in component form, might look like this:
Source: metallic
Action: single tap
Character: bright, clean, no distortion
Duration: 40 ms
Environment: dry, closeThis is not a prompt you paste as-is. It is a mental structure. The actual prompt is a single sentence or a comma-separated list, but the components tell you what to change when the result is wrong.
What changes are worth making, and what should you leave alone?
Not every prompt revision is a productive one. Some changes affect the output in predictable ways; others introduce noise that makes the next iteration harder to interpret.
The changes that are usually productive are the ones that move one component at a time. If the sound is too bright, change the character description and leave the source and action alone. If the sound is too long, change the duration and leave the character alone. The output tells you whether the change did what you expected.
The changes that are usually unproductive are the ones that rewrite the entire prompt. If you replace “metallic, bright, single tap” with “robotic, futuristic, UI beep,” you have changed the source, the character and the action all at once. If the result is better, you do not know why. If it is worse, you do not know which change caused it.
The other unproductive change is adding more description when the result is already close. If the sound is 80 percent right, adding three more adjectives usually does not push it to 90 percent. It pushes it into a different space, and you lose the 80 percent you had. The beginner AI guide covers the initial prompt construction; the iteration phase is where the discipline matters more.
The useful rule of thumb is that a change to one component should be small enough that you can describe it in one word. “Brighter” is a change. “More metallic, shorter, and add some grit” is three changes, and the result will not tell you which one mattered.
How do you handle a result that is close but not quite right?
The close-but-wrong result is the most common outcome of a first generation, and it is also the one where the iteration model saves the most time. The instinct is to regenerate with a slightly modified prompt and hope. The better approach is to identify which component is off and change only that one.
If the sound is the right character but too long, the duration is the problem. Shorten it and regenerate. If the sound is the right length but too sharp, the character is the problem. Soften it and regenerate. If the sound is the right character and length but feels like the wrong material, the source is the problem. Change the source and regenerate.
The reason this works is that the model treats the components as partially independent. A change to the duration does not usually change the character. A change to the character does not usually change the source. The model is not a database lookup; it is a generative system, and it responds to the specificity of the change.
The InstructFX2FX research describes a related pattern from the audio effects side: a large language model sets the rough direction, and a perceptual optimizer refines the parameters step by step without losing the progress already made[citation:1][citation:16]. The sound-generation equivalent is that the working prompt sets the direction, and each revision refines one component without resetting the others.
When should you start a new prompt instead of editing the current one?
Editing is the better default, but it is not always the right choice. There are specific cases where the current prompt has drifted too far from the target, and continuing to edit it produces a series of increasingly distant variations.
The first case is when the source is wrong. If you are trying to generate a wooden footstep and the prompt keeps producing metallic footsteps, changing the character description will not fix the source. The prompt needs to be rebuilt around the correct source.
The second case is when the component model has broken down. If you have changed the character five times and the sound has moved in a direction you did not expect, the prompt is no longer telling you what the model is responding to. A new prompt with a clearer component structure is faster than untangling the old one.
The third case is when the sound is not the problem. If the generated sound is correct but the game context makes it feel wrong, no amount of prompt iteration will fix it. The fix is in the mix, the timing or the event selection, not in the generation. The prototyping workflow guide covers the context side; the iteration phase is about the sound itself.
The useful test is to ask whether the current prompt is still describing the target sound. If it is, edit it. If it is describing a different sound that has drifted away from the target, rebuild it.
What does an iteration session actually look like in practice?
A typical session for a single game sound effect, using the component model, takes fewer generations than a session that rewrites the prompt each time. The sequence is predictable.
- First generation. Write the component structure as a single prompt. Generate. Listen.
- Identify the dominant problem. Is it the source, the character, the duration or the environment? Pick the one that is most wrong.
- Change one component. Make a small change to that component. Regenerate. Listen.
- Check the other components. If the change fixed the problem and did not break anything else, keep it. If it broke something, undo it and try a different change.
- Repeat. Most sounds converge in three to six generations. Sounds that take more than ten are usually being edited past the point where the prompt is still describing the target.
The session is not a search for the perfect prompt. It is a process of elimination. Each generation tells you something about what the model is responding to, and the next generation tests that understanding.
The AI vs traditional sound design comparison covers the cases where this iteration model is not the right approach at all. A sound that needs layered structure or precise parameter control is usually faster to build with a synthesizer than to iterate through a prompt. The iteration model is for sounds that are single-source, short and character-driven.
Why does the working prompt need to be saved?
The iteration session produces two things: the final sound and the prompt that produced it. The prompt is the more valuable of the two, because it is what allows the sound to be regenerated, varied or adapted later.
A saved prompt with the component structure intact can be used as a template for a related sound. A footstep prompt can be adapted into a landing prompt by changing the action and the duration. A UI click prompt can be adapted into a UI toggle prompt by changing the character. The component structure is what makes the adaptation fast.
The hybrid AI and manual audio pipeline guide covers the asset management side of this. The iteration session produces the sound; the pipeline is what keeps the prompt and the sound together so that the next revision does not start from zero.
A prompt that is edited in place is a prompt that can be reused. A prompt that is rewritten from scratch every time is a prompt that is thrown away. The difference in efficiency is not in the tool. It is in whether the designer treats the prompt as a document or as a command.
Generate a Reference Sound to Iterate From
Open the SfxMaker generator and create a short sound effect with a clear character. Use it as the comparison point for the AI generation: the AI sound should have a similar source and duration, even if the character is different. The reference is what tells you which component of the prompt is off.
Open SfxMaker Generator →