The hardest part of AI coding, for me, is not making code appear.
That part got weirdly easy. The hard part is knowing when the code is trustworthy enough to ship, especially when the decision is technical and I do not have the background to audit it deeply. I can read a UI. I can understand a product flow. I can often tell when something smells off. But if a model chooses a data shape, a security assumption, or a migration path, I am partly blind.
For a while I tried the obvious fix: ask the same model to review itself.
It helps a little, but not enough. The model often defends the shape it just created, or catches surface issues while missing the assumption underneath. So I started doing something dumber and more useful: before I trust an important plan or risky diff, I show it to a different model family and ask it to find the holes.
That is the double-tap.
What I wanted to know
The question was not "which model is smarter?"
The question was narrower: can a second model, with different defaults and blind spots, cheaply point me toward the part of the first model's answer I should not trust yet?
That distinction matters. I am not asking the reviewer model to take over the work. I am asking it to create friction at the moment where blind confidence is most expensive. If it says the plan is good, I move faster. If it disagrees, I have a place to inspect.
The win is upstream. A bad plan becomes code. Code becomes dependencies. Dependencies become bugs that look unrelated two days later. Catching the shaky assumption before the first file is touched is much cheaper than reviewing every diff after the project has already drifted.
Where I use it
I use the double-tap in four places.
First, plan review. Before Claude writes code, I copy the plan into another model and ask what will fail later. This catches missing rollback paths, vague success criteria, and "simple" plans that are only simple because they ignore the hard part.
Second, minimal-version pressure. Models love to make the first version a little too complete. I ask a second model what is too much, what is missing, and what the smallest shippable version would be. This has saved me from polishing features that should not exist yet.
Third, technical foundation checks. If a model suggests a library, architecture, schema, auth pattern, queue, database move, or anything that will be annoying to reverse, I double-tap before accepting the foundation.
Fourth, risky diffs. I do not review every diff this way. That would be slow and probably fake discipline. I use it for migrations, data changes, destructive commands, auth, payment logic, and anything client-facing where a mistake would hurt.
The handoff has to be almost free
The workflow only survived when I made the handoff cheap.
At first I did it manually: copy the plan, open another tab, write a reviewer prompt, paste context, wait, paste the answer back. That was fine when I felt careful. It died on tired afternoons, which is exactly when I needed it most.
The current version is Raycast snippets with {clipboard} placeholders. Raycast is a command launcher on macOS, and snippets are reusable text blocks. The useful part is that a snippet can paste a full reviewer prompt around whatever I just copied.
So the loop is:
- Copy the plan, proposal, or diff.
- Trigger the reviewer snippet.
- Read the review.
- Paste only the smallest useful correction back to the writer model.
The final step matters. I do not want a long second-model essay. I want the patch prompt that changes the first model's next action.
When the input starts as dictation, the Promptify mode from my Handy setup makes this smoother. I can speak the messy thought, have the local model structure it as a prompt, then double-tap that prompt before handing it to Claude. It sounds overbuilt until it saves you from a confident wrong instruction.
The snippets I actually use
For plans, this is the one I trigger most:
Find the holes in this plan before I let it run.
Context:
{clipboard}
Focus on:
- assumptions that would fail later
- unnecessary scope
- fragile technical foundations
- a simpler first version that would still ship
- missing rollback or test path
If it is good enough, say "go".
If not, give me the smallest paste-back prompt for the writer.
For first versions:
Challenge this first version.
Context:
{clipboard}
What is too much?
What is missing?
What assumption is most likely wrong?
What is the smallest version worth shipping?
End with one paste-back prompt.
For risky diffs:
Review this diff for merge readiness.
Context:
{clipboard}
What did the writer miss?
What is the regression risk?
What tests would you want before this lands?
End with one paste-back prompt,
or "looks good" if nothing material.
The wording is intentionally boring. The snippet should make the reviewer useful, not clever.
Which models I route to
As of May 2026, my routing is habit more than science.
I tend to use Grok for plan-poking and minimal-version challenges because its answers are often sharp in that mode and the free tier covers the volume I need. I use ChatGPT or Codex when the question is backend logic or merge readiness. I use Gemini more often when the question is visual, layout, or frontend shape.
I would not turn that into a universal rule. The property I care about is difference. Same family, same defaults, same blind spots, less useful review. A different model family is valuable because it is more willing to disagree in a different direction.
The double-tap is not a vote. If Claude says one thing and Codex says another, I do not average them. I inspect the disagreement. That is usually where the useful information is.
When I skip it
I skip it a lot.
For throwaway scripts, tiny copy changes, obvious UI tweaks, and experiments I can delete by Friday, I just ship. For diffs that follow a plan I already double-tapped, I usually do not re-review unless the diff touches something riskier than expected. For visual and content work, my own eye is often the second model.
The workflow is for the work I cannot judge well enough alone. That category is large enough without pretending every decision needs ceremony.
There is also a failure mode: double-tapping can become procrastination with a smarter costume. If I ask three models because I am avoiding a decision, the workflow is no longer quality control. It is avoidance. One second opinion is usually enough to reveal where to look.
What I would copy first
I would not start with two terminals, five models, or a big agent system.
I would start with one snippet. Pick the riskiest recurring decision in your work. If you are technical, maybe that is migrations. If you are not technical, maybe it is "is this plan safe enough to let run?" Write one reviewer prompt that ends with a paste-back instruction for the writer model.
Use it for a week before important plans. Keep a small note of what it catches. If it catches nothing useful, delete it. If it catches one mistake that would have cost you an afternoon, keep it and maybe add a second snippet.
The broader lesson is not that two models are magic. It is that solo AI work needs roles. A software team is not one person with a bigger brain. It is a writer, a reviewer, and a tester, sometimes the same person wearing different hats.
The double-tap is the smallest version of that structure I have found that I will still run on a tired Friday. claude-relais is the larger version, where the role split becomes structural across runs instead of manual across tabs.