Builders make bad judges of their own work. A chef never scores the dish right off the pan, and a model that just finished a deck has the same bias. It’s still proud of every slide it wrote two minutes ago.
That’s the logic behind a workflow trick the original poster, u/Lazy-Entrance446, shared in r/PromptEngineering. The post sits at three upvotes, which undersells how useful the idea actually is.
The poster builds decks in Gamma, then refuses to edit them in the same chat that produced them. Instead, a second, completely blank context gets opened, one that has never seen the original notes or the reasoning behind any slide. That fresh context gets one job: find the three weakest slides, the vaguest claim, and anything that sounds made up. No politeness allowed.
Key Idea
Here’s the part worth stealing: separate producing from approving. A context that wrote something will defend it, every single time. Ask the same chat to review its own deck and you get the reasoning it already committed to, just repackaged as a critique. A blank pass carries no loyalty to the original choices, so it catches filler the first draft was genuinely proud of.
I like this because it’s cheap to copy and it doesn’t need a new tool. It just needs a second window and a willingness to be told your deck is weaker than you thought.
This isn’t really about decks either. Any AI output that comes with reasoning attached, a pitch, a script, a piece of code, gets defended by the context that produced it. The reasoning is already baked in, so the model leans on it instead of looking at the output fresh.
The Old Way vs The New Way
The old way: generate a deck, stay in the same chat, and ask “how does this look?” The model agrees with itself, politely. Nothing meaningfully improves because the same reasoning is grading the same reasoning, and it has every incentive to call its own work solid.
🔑 The new way, per this contributor’s workflow: finish the deck completely, then switch contexts before any review starts. The second pass has no memory of your notes, no stake in the slide choices, and no reason to be nice about any of it.
That gap, zero investment against full investment, is exactly where the useful criticism lives. This innovator’s version runs on a presentation generator, but the same trick applies to an outline, a cold email, or a block of code.
Practical Steps
Here’s how to run the cold critique pass yourself:
- Finish the output first. Don’t review mid-build. Let the first pass fully commit to its choices before anything gets judged.
- Open a brand new chat. Don’t paste your original notes, outline, or reasoning into it. The less it knows about why a slide exists, the harder it will be on that slide.
- Give it one narrow job. Something like: “Find the three weakest slides, the single vaguest claim, and anything that sounds invented. Don’t be polite about it.”
- Push back on every flag before touching the deck. Only fix what survives the argument. That step filters out complaints that are really just nitpicking.
One commenter, u/minimanishtic, flagged a real risk here: a cold pass can overcorrect and invent problems that were never actually there. Nuance and the right context still matter, even on a blank-slate review. Their suggested fix lines up with the author’s own rule: push back on every flag, and only act on the ones that hold up.
Another reply, from u/Echo_Tech_Labs, backs the core move directly. A fresh context gives a genuinely more independent read than asking the same chat that built the thing to grade itself.
The original poster asked the thread if anyone had found a way to make this cheaper than basically doing the work twice. Fair question! There’s no free lunch on token cost, and a second full pass does add time. But the win was never speed. It’s catching the three slides you would have shipped anyway because you had stopped seeing them.
Try it on the next deck, email, or outline you build. Finish it completely, then hand it to a context with no memory of why you made any of those choices. Watch what survives the fight. This one’s a keeper!
The full thread in r/PromptEngineering has more back and forth worth reading if you want the rest of the argument. The debate over making a double pass cheaper is still open, and it’s worth a look.
Frequently Asked Questions
Q: Does a fresh context reviewer over-critique and add fake problems?
It can, but that’s where context design matters. Give the fresh reviewer only your success criteria and requirements, not the production history. You’ll likely get some over-suggestions, but the fix is simple: only implement critiques that you can’t talk yourself out of. If the fresh context found a real flaw, you should still see it after pushing back.
Q: How much context should you actually give the fresh reviewer?
Separate required context from production history. Give the reviewer requirements, success criteria, and source material genuinely needed to evaluate, but skip the notes and reasoning behind the current version: that’s production bias at work. Clean context keeps reviews independent without being useless.
Q: Is testing in a fresh context different from a fresh account?
Yes. A fresh context might still inherit implicit biases from your account settings, conversation history, or persistent personalization. For maximum rigor (especially if you’re building for others), test in a completely clean account with no history at all. That’s the strongest robustness test.
Q: Won’t the fresh reviewer just undo decisions you already made?
Maybe, but that’s actually useful signal. Some users report that fresh reviews can suggest changes that break the original intent. The fix: only act on critiques where the fresh reviewer’s concern survives your pushback. If you can easily explain why you made a choice and the reviewer still objects, that’s worth investigating.
should you review an ai presentation generator in a fresh context, not the one that made it?
by u/Lazy-Entrance446 in PromptEngineering