Prompts that say “make it punchy” or “edit like a pro” keep producing the same machine-flavored output. The fix one Redditor found isn’t a better-worded prompt. It’s a running list of reasons. Most people respond to a bad output by rewriting the prompt. This approach responds by writing down why the output was bad, and it works faster.
The key idea
u/ustype was using an agent to edit talking-head videos. The first versions were technically correct and obviously made by a machine. The cuts landed where the transcript said they should, the captions were present, and the pacing was fine on paper. Yet anyone watching could tell no human had touched it. Sharper instructions didn’t change that.
What did change it: every time they rejected an output, they wrote one rule in this format:
Rule: the failure it prevents.
The second half is what makes it work. The rule tells the model what to do. The failure clause tells it why, and that is the part that lets it generalize.
The contrast: old way vs. new way
The old way: You write a long prompt full of style adjectives. The output misses. You add more adjectives. “Punchy” becomes “very punchy.” Then it becomes “punchy but natural, like a human editor with great taste.” Nothing sticks, because adjectives don’t tell the model what went wrong. They only describe a feeling you had, and the model has to guess which part of the output caused it.
The new way: You treat each rejection as a data point. You write down the specific rule and the specific failure it prevents. The prompt stays short, and the knowledge lives in a growing file instead.
Why does the failure clause matter? Without it, the model reads your rule as a style preference. When another instruction pulls the other way, it trades the rule away. With the reason attached, the model can reason about edge cases instead of following the rule blindly. If a rule says “never do X because it causes Y,” the model can also avoid Z when Z would cause the same Y, even though you never mentioned Z.
Here are three real rules from the post:
- 🎬 Captions start 0.08s after the word onset, so the word is heard before it’s read. Early captions read as broken sync even when they’re only slightly off.
- 🖼️ Never continuously scale a detailed screenshot across a whole beat. Every frame gets resampled at a slightly different size, and the image looks like it’s vibrating.
- ✂️ Anchor cut edges on silence, not on word onsets. ASR onsets land on the consonant, so cutting there clips the attack.
Notice what each one does. None says “make it better.” Each names a concrete mistake and the mechanism behind it. A model can apply that to situations you never listed. The screenshot rule, for example, also tells the agent to be careful with zooming on charts, code snippets, or any other fine-detail image, because the same resampling problem applies.
How to build your own rules file
- Run the task and reject the output. Don’t fix it silently. Notice exactly what felt wrong, and ask yourself what you would point at if someone stood next to you and asked “what bothers you here?”
- Name the failure. “Looked robotic” is too vague. “The image vibrated because it was resampled every frame” is something you can write a rule against. If you can’t find the mechanism, write down the symptom you observed. A rough reason still beats no reason, and you can sharpen it later.
- Write one line in the format: Rule: the failure it prevents. One rejection, one rule. Resist the urge to bundle three lessons into one sentence, because short rules are easier for the model to apply and easier for you to delete later.
- Keep the rules in a file the agent reads before every run. The original author also keeps a separate taste file where corrections get saved, and the agent reads it before every edit. Put the file at a fixed path so you never have to remember to paste it in.
- Repeat. Each rejection makes the next output better, and the file keeps that knowledge so you don’t have to re-explain it. Every few weeks, skim the file, merge duplicates, and remove any rule whose failure no longer shows up.
This isn’t only for video. The post’s author points out it works as a template for any domain where “good” is hard to define: writing, design, code review, anything where your taste is the real spec. A writer might log “Never open with a question, because readers have seen it a hundred times and skim past.” A code reviewer might log “Flag functions that swallow exceptions, because the bug surfaces three layers away and costs hours to trace.”
Why this is faster than prompt tweaking
Prompt tweaking is guesswork. You change wording and hope. A rejection log is evidence. Every line came from a real miss, so every line earns its place. Over time the file becomes more valuable than the prompt, because the prompt describes what you want while the file records what actually went wrong. It also survives model upgrades and tool changes. Swap in a new model next month and your hard-won lessons come along, while a finely tuned prompt often has to be rebuilt from scratch.
Try it this week
Pick one recurring task you give an AI. Next time you reject an output, write the rule and its failure clause before you re-prompt. After five or six rejections, you’ll have a file that does more than any rewrite of your instructions.
Want to see the format in a real project? The original author open-sourced theirs at https://github.com/ranahaani/i-hate-editing, and the rules/ folder is the part worth reading.
Have you found that a list of reasons beats a better-worded prompt? Tell me what your first rule would be!
Frequently Asked Questions
Q: Why does the “failure it prevents” part matter so much?
A bare rule like “captions start late” reads as a style preference, and the model will trade it away when another instruction pulls the other way. Tying the rule to a concrete failure, like captions that look out of sync even when they’re only slightly off, gives the model something to reason against. One commenter found the same thing with writing edits: a rule like “don’t open every paragraph with a transition word” only stuck once they wrote down that the transitions were the tell giving the draft away.
Q: Should each rule describe the mistake or the fix?
One commenter suggests writing each rule as the mistake rather than the instruction. They’ve found the model responds better to a framing like “this looks wrong because…” than to “do it this way.” Naming the failure also makes it easier to spot the same mistake in a situation the rule never mentioned.
Q: Can this approach work outside video editing?
Yes. The author built the rules folder as a template for any domain where “good” is hard to define, and one commenter applied the same idea to editing written drafts. The key is to save each correction as a rule with its failure attached, so the agent reads it before every edit. Start with the corrections you make most often, since those are the ones worth writing down first.
Every time I rejected an AI edit I wrote down the reason. That file ended up doing more than the prompt
by u/ustype in PromptEngineering