You have typed 'make it punchy' into an AI more times than you want to admit, and the output still comes back flat, machine-flavored, untouched by anything human. So you pile on adjectives: 'punchy' becomes 'very punchy,' then 'punchy but natural, like a human editor with great taste,' and nothing sticks. The problem was never your wording.

The person behind this hit the same wall while using an agent to edit talking-head videos, where cuts landed on the transcript, captions showed up, and the pacing read fine on paper. Anyone watching could still tell no machine understood what mattered. So the creator tried something other than a sharper prompt: a running list of reasons, one line per rejected output.

Here is why I find this worth your time: instead of rewriting instructions, the author logged failures, turning every bad result into a single rule paired with the specific failure it prevents. That second half is the entire trick, because it lets the model reason about mistakes you never listed. It works for writing, design, code review, anything where your taste is the real spec.

In partnership with

The agentic era needs a different CRM. That’s Attio.

Teams like Parallel, Turbopuffer, and Wordsmith are already setting the pace on Attio. Get an always-on revenue engine, with agents and workflows that build pipeline, chase every buying signal, and move deals forward with your team. Whether you're working in your browser, inbox, or favorite agent, connect to your customer data in real-time through Attio's web app, MCP, API, and SDK.

The old way versus the new way

The old way treats every miss as a wording problem. You reach for stronger adjectives and hope the model reads the feeling you had. It never does.

The new way treats each rejection as a data point: you write down the specific rule and the specific failure that rule prevents. The prompt stays short. The hard-won knowledge lives in a growing file instead of bloating your instructions with guesses.

Why the failure clause does the heavy lifting

Strip the reason off a rule and the model reads it as a style preference. When another instruction pulls the other way, it trades your rule away without blinking. Attach the failure, and the model finally has something to reason against.

Here is the mechanism that sold me: if a rule says never do X because it causes Y, the model can also avoid Z when Z would trigger the same Y. You never mentioned Z. It generalizes on its own, which is exactly what a pile of adjectives can never do.

Three rules that show the pattern

The contributor shared a few from the real project. Captions start 0.08 seconds after the word onset, so the word is heard before it is read, because early captions read as broken sync even when the gap is tiny.

Another: never scale a detailed screenshot across a whole beat, because every frame resamples at a different size and the image looks like it is vibrating. A third anchors cut edges on silence rather than word onsets, since speech-recognition onsets land on the consonant and cutting there clips the attack.

Notice what none of them say: 'make it better.' Each names a concrete mistake and the physics behind it. That screenshot rule also covers zooming on charts and code snippets, because the same resampling problem applies, and the model works that out without being told.

Unify Your Teams and Tech Stack With HubSpot

Connect your customer data, teams, and tools without the hassle of complex integrations or lengthy setups. One easy platform gives marketing, sales, and service teams a unified customer view and the tools to turn it into growth.

Why HubSpot and what's new
• Generate leads and automate marketing with Marketing Hub
• Build your pipeline and close more deals with Sales Hub
• Scale customer support and drive retention with Service Hub
• Keep customer data clean, connected, and actionable with one, unified platform

Join 306,000+ in over 135 countries using HubSpot to grow their businesses.

See what a more connected approach to growth can do for you and your team. Get setup quickly and start checking off your hardest tasks.

*Ad

How to build your own file

Run the task and reject the output, but do not just fix it and move on. Ask what you would point at if someone stood beside you and said 'what bothers you here?' Name the failure, not the vibe.

'Looked robotic' is useless. 'The image vibrated because it resampled every frame' is something you can write a rule against. If you cannot find the mechanism, log the symptom you saw and sharpen it later, because a rough reason still beats no reason.

Then write one line: the rule, then the failure it prevents. One rejection, one rule, never three lessons bundled into a sentence, since short rules are easier to apply and easier to delete. Keep the file at a fixed path the agent reads before every run.

Naming the failure is a muscle, and it only shows up after a few dozen reps on real outputs. 3 Minute AI gives you those reps in three-minute lessons, each ending with a task you run in a built-in chat lab. Daily lessons and two full courses are free.

Why a log beats endless prompt tweaking

Prompt tweaking is guesswork: you change wording and pray. A rejection log is evidence, because every line came from a real miss and earns its place. I think that distinction is the whole ballgame.

The file also outlives your tools. Swap in a new model next month and your lessons ride along, while a hand-tuned prompt often has to be rebuilt from scratch. A writer might log 'never open with a question, because readers have seen it a hundred times and skim past,' and a reviewer might flag functions that swallow exceptions, because the bug surfaces three layers away and costs hours to trace.

Your first rule, tonight

Open a blank file today, write down the last AI output you rejected, and turn it into one short rule plus the exact failure that rule prevents.

Grab the three example rules and the step-by-step file setup in the full breakdown.

Worth 10 minutes if you keep rewriting the same prompt and watching the model make the same mistake anyway.

Hit reply and tell us why.