Rephrasing the same instruction five different ways is the default way people work with LLMs. A Reddit user who has been using these models for about three years, since the last weeks of GPT-3, suggests a pattern break. When the model keeps rebuilding the wrong thing, stop typing and start writing on paper. It sounds almost too simple, but it targets the real problem, which is rarely the model.
The Key Idea
The post comes from u/Echo_Tech_Labs on r/PromptEngineering. The core claim is that most prompt frustration comes from a fuzzy idea, not a weak model. You ask for a dashboard, and four turns later you are still explaining a concept a competent intern would have got in one. Each new rewording feels like progress, but it is really you thinking out loud inside the chat window, and the model is treating every half-formed thought as an instruction.
The fix is to clarify your own thinking first, then build up the model’s context in stages instead of dumping everything into one message. Think of it as doing the hard part before the model sees anything. A clear brief goes in, a usable draft comes out, and you skip the loop of corrections.
Old Way vs. New Way
The old way: Type a big prompt. Read the wrong output. Rephrase. Back up. Rephrase again. Every turn adds noise, and the model keeps sampling against a muddy context. By turn six, the conversation contains three contradictory versions of what you wanted, and the model is trying to satisfy all of them at once. That is why the output feels stubborn. It is not stubborn. It is confused by your own history.
The new way: Work out the idea offline, then feed it in gradually. Test it against a fresh set of eyes, ideally a different model. The author calls the result “In-Context Conditioning.” It is broader than in-context learning. You are not just giving examples. You are shaping the whole context the model samples against, or in the author’s metaphor, the semantic basin your idea lives in. A clean basin means the model keeps landing on the right answer. A cluttered one means it wanders.
Here is a quick example. Say you want a weekly reporting dashboard. The old way is typing “build me a dashboard for my sales data” and then correcting chart types, metrics, and layout over a dozen messages. The new way is spending ten minutes on paper first: who reads it, which three numbers matter, what a bad dashboard would look like. Then the model starts from a real spec.
Practical Steps
- 📝 Write it on paper. Note your goals, where the idea could break, and a criteria for what you want versus what is actually achievable. Keep it rough. Bullet points, arrows, and crossed-out ideas are all fine, because the point is to force decisions, not to produce a polished document.
- 📸 Show the model your notes. Photograph the page, or transcribe it with your phone’s built-in tools. Handwriting warning: if yours is messy, the model may hallucinate parts of your notes, so check the transcription. Fix any misread words before moving on, since one wrong word can send everything downstream in the wrong direction.
- 👀 Ask it what it sees. Before anything else, have the model describe your notes back to you. This shows you right away whether it understood. If its summary surprises you, the gap is either in your notes or in its reading, and now you know which one to fix.
- 🧱 Scaffold slowly. Start with first principles. Do a little research on the topic, then map your idea to that research with the model’s help. Do not put everything into one input. Add one layer at a time, and confirm the model has it before adding the next.
- Red-team in a fresh context. Pull the data out, open a new chat, and frame it like a stranger reviewing someone else’s work. A different model is even better. Ask it directly: “What is weak, missing, or likely to fail here?” Fresh eyes have no loyalty to your earlier wording.
- Repeat. Do this enough times and you build an intuition for what looks good and what looks bad. After a few rounds, you will catch fuzzy thinking before you ever open a chat.
What the Community Added
One commenter suggested running the finished note past two or three models and watching where they split. Different models make different mistakes, so matching answers let you relax, and a disagreement points at the exact claim worth checking. That is a cheap, practical upgrade to step 5. It also saves time, because you only dig into the spots where the answers diverge instead of rereading everything.
Another commenter said they had stumbled into a similar pen and paper habit months ago, which is a good sign this is not just one person’s quirk. When people arrive at the same habit independently, it usually means the habit solves a real problem.
Your Move
Next time you catch yourself rewording the same request for the third time, stop. Grab a pen, write down what you actually want and where it could go wrong, and give the model that instead. Then send the result to a second model and see where they disagree. Fair winds, and let me know how the paper trick works for you!
Frequently Asked Questions
Q: Should I sketch out my idea on paper before asking an AI?
Yeah, this one actually works. A commenter stumbled into it the same way, sketch on a sticky note, snap a pic, and just ask the model “what do you see here?” and somehow the circular back-and-forth stops cold. Something about showing the model a visual structure makes it grab your concept way better than the fifth rephrased text explanation. If your handwriting’s rough, just transcribe it.
Q: How do I know if the model’s answer is actually good?
Run it past two or three models and watch where they agree or split. When they land on the same answer, you can relax. When they disagree, that’s your signal, it points straight at the claim you should fact-check against a real source. Do this enough and you build an instinct for what “looks good” versus what’s confidently wrong.
Q: Should I red-team with one model or multiple?
Multiple, if you can swing it. Different models hallucinate in different ways, so if they all agree, you’ve got confidence. If they split, now you know exactly what to investigate. One user admitted they usually “argue with one model until I’m tired,” but the smarter move is three models in a fresh context, different framings catch different blind spots.
Q: Why do I keep explaining the same thing over and over?
The post calls it a semantic basin problem, the model didn’t build the right conceptual container for your idea. Instead of rewording again, try breaking it smaller, starting with first principles, then scaffolding step-by-step. Throw a visual reference (your sketch) at it instead of more text, that often breaks the loop faster than any rephrasing will.
The Dialogical Workflow: Red-Teaming, Scaffolding, and Paper Notes
by u/Echo_Tech_Labs in PromptEngineering