10 Prompt Patterns I Use Every Single Day
Last Tuesday I spent 40 minutes arguing with Claude about a database schema before I realized I had never told it what I already tried. I described the problem, it gave me the same three suggestions I had already ruled out, I pushed back, it apologized and gave me variations of the same three suggestions. The entire session was garbage because I started from zero instead of from where I actually was. I closed the tab, rewrote my first message, and had a working solution in six minutes. That gap — between how most people prompt and how it actually works when you treat the model like a collaborator who needs real context — is what this post is about.
Pattern 1 & 2: Lead With What You Already Tried, and State the Constraint That Binds You
These two patterns are almost always used together, so I won't pretend they're separate.
When you describe a problem without the history of your attempts, you are forcing the model to rediscover your dead ends. Every developer knows this frustration: you explain a bug, get back a solution you tried on Monday, explain you tried that, get a variation, explain that too — it's a recursive waste. The fix is brutal honesty upfront: "I need X. I already tried A and B. A failed because [specific reason]. B is off the table because [constraint]. Don't suggest either."
The constraint layer is the other half. Models are optimists by default. They will give you the architecturally clean, perfectly testable solution that requires three new dependencies and a refactor of your auth layer. Unless you tell them you are shipping in two days, can't add dependencies, and the code needs to be readable by someone who last touched Python in 2019. Constraints aren't limitations on the answer — they are the answer. Front-load them or you will spend the session rejecting suggestions that are technically correct but situationally useless.
Pattern 3 & 4: Output First, Reasoning After — and Diff Only, Not Rewrites
Two sides of the same coin: stop asking for explanations you don't need, and stop asking for full rewrites when you need a small change.
"Output first, reasoning after" means your prompt ends with: "Give me the code first, then explain the non-obvious parts only." The default model behavior is to explain, caveat, then produce. That's fine for learning. When you're building, you want the artifact immediately so you can evaluate it before committing to reading a paragraph of justification. You can always ask for the explanation after. Flipping the order costs nothing and saves you from reading context you didn't ask for.
"Diff only" is the more underused pattern. If you have a 200-line function and you want to change the error handling in one branch, don't ask for a rewrite of the whole function. Say: "Show me only the lines that change and their immediate surrounding context. Don't reproduce the rest." This does two things: it forces the model to localize the problem instead of generating a plausible-looking full rewrite that silently changes things you didn't ask it to touch, and it makes review fast. The number of times a full rewrite introduced a subtle regression versus a targeted diff is not close.
Pattern 5 & 6: The Adversarial Loop — Steelman Then Attack
This is the pattern I use most on architecture decisions, and it has saved me from at least a dozen bad calls.
Step one: ask the model to steelman your current approach. Not "what are the pros and cons" — that gets you a balanced list written by a committee. Ask it to make the strongest possible argument for what you are already doing. This forces it to surface the genuine merits you might be underselling.
Step two: switch modes. "Now you are a skeptical senior engineer who has been burned by this exact pattern before. What breaks? What are the second-order failures? What does the on-call alert at 2am look like?"
The combination is where the value is. Steelmanning first means you don't throw away something good because the model defaulted to "here are some concerns." Attacking second means you don't commit to something fragile because it sounded reasonable in the first pass. I run this on every technical decision that will be hard to undo.
A fast variant: "What would have to be true for this to be a mistake I regret in 6 months?" That single question has killed more bad ideas faster than any other prompt I have written.
Pattern 7 & 8: Negative Space Prompting and Context Resets
Negative space: instead of describing what you want, describe what you don't want with specificity. "Write a technical blog post. Don't use bullet points. Don't start sections with rhetorical questions. Don't use the words 'leverage,' 'robust,' or 'seamless.' Don't summarize the section at the end of the section."
This sounds like micromanagement. It is. But it's targeted micromanagement based on the specific failure modes you've actually seen from this model on this type of task. The model has strong defaults. Negative space prompting is how you override them surgically without writing a 600-word system prompt.
Context resets are the defensive version of this. Long conversations drift. The model picks up framing from your earlier messages, your corrections, your off-hand examples. By message 15, you're no longer talking to a fresh reasoner — you're talking to one that has absorbed all your half-formed thinking from the last hour. When I notice answers getting hedged, circular, or weirdly deferential, I open a new chat, state only the resolved facts and the current question, and start clean. Context is not always an asset.
Pattern 9 & 10: Chain-of-Draft and the Rubber Duck Inversion
Chain-of-draft: rough → structured → final. Don't ask for a finished artifact on the first pass. Ask for a rough skeleton. Review it. Then say: "Now flesh out section 2 only, keeping everything else as placeholders." Then finalize. Trying to get a complete, polished output in one shot on complex tasks is like asking a contractor to build the house while you figure out the floor plan. You'll get a house. It won't be the one you wanted.
The rubber duck inversion is pattern 10 and probably the strangest one. When I'm genuinely stuck — not on a technical problem, but on what I'm actually trying to do — I describe the situation and end with: "Don't give me solutions. Ask me the three questions that would most clarify what I actually need." I'm outsourcing the Socratic method. The model is good at identifying the question behind the question. Answering those three questions back to the model (or just to myself) usually unblocks me faster than any direct answer would have.
The Quick-Reference Checklist
Before you send a prompt, run through this:
- [ ] Did I state what I already tried and why it failed?
- [ ] Did I name the constraints that are actually binding?
- [ ] Did I ask for the output before the explanation?
- [ ] Is this a diff task I'm incorrectly framing as a rewrite task?
- [ ] Should I steelman this before attacking it?
- [ ] Am I describing what I want, or what I don't want?
- [ ] Is this context window fresh enough to trust, or do I need a reset?
- [ ] Am I asking for a final artifact or a draft I can steer?
- [ ] Do I know what I want, or should I ask for clarifying questions first?
Nine items, not ten — because the tenth is situational: trust your read of when the model is drifting and cut the conversation.
How AI Handler Approaches This
Building AI Handler has been, in large part, an exercise in encoding these patterns at the infrastructure level rather than the prompt level. Every session you run in AI Handler carries structured context about what was already tried in prior sessions on the same problem — so pattern 1 is automatic. Constraints you set on a project propagate to every prompt in that project. You can set a default output order (artifact first, reasoning on request). You can save adversarial review as a one-click mode, not a thing you remember to do.
The insight behind the tool is that the gap between a mediocre AI workflow and an excellent one is almost never model capability. It's prompt discipline applied consistently. Most people apply it inconsistently because they're relying on memory and habit. AI Handler makes the discipline the default.
AI Handler is the unified AI workflow tool I am building. Launching June 2026. Email ceo@eternalsix.com for beta access.
Top comments (0)