You're mid-incident or mid-debug. You ask an AI CLI to explain a stack trace, and it comes back with a confident, specific, plausible-sounding root cause.
It's also the only opinion you've got.
Getting a second opinion used to mean paging a colleague in an incident, or breaking their flow during a debug session. Now it can mean opening a second terminal and asking a different model to critque the answer of the first.
The setup
Open two terminals — two windows, two tabs, whatever you already use. Run one AI CLI in each: Claude Code, Codex CLI, Gemini CLI, any combination. The only requirement is that they're genuinely separate sessions with separate context — nothing you tell the first one is visible to the second unless you paste it there yourself.
(If you already run tmux, splitting panes instead of alt-tabbing between windows is a nicer way to do this once you're doing it often. Worth knowing about, not required to start.)
The critical bit
The easy way to get this wrong is asking the second model the same vague question. Here's what to do, in order:
- Ask the first session something concrete. "Here's a stack trace from the checkout service, what's the likely cause?" — not "what's wrong with this?" Treat the answer as a draft, not a verdict.
- Paste the real answer into the second session, not a paraphrase. "Here's another model's diagnosis of this stack trace. What's missing, or what would you check before trusting it?" A vague question gets a generic response; a concrete claim gets a concrete critique.
- Weigh disagreement instead of averaging it away. If both agree, that's mild evidence, not proof — correlated training data can produce correlated blind spots. If they disagree, that's telling you exactly where the ambiguity in your problem or your data is.
That's the whole technique: two independent sessions, and the discipline to paste the answer instead of the question.
Use for the tough questions, not every question
Cross-examining every question doubles your round-trip time for a fix you were probably going to get right anyway. Use your judgement to know when it's actually worth it: a fix about to touch production is worth it, a syntax question doesn't. That line isn't obvious the first few times — expect to over-check things that didn't need it, and skip it on something that did, before it turns into a habit instead of a rule you have to think through.
I wrote this up as one step in a longer pathway on debugging with nothing but a terminal (grep, jq, git, and yes, tmux, all building toward this) — if you want the full "when to bother" breakdown: Multiple AI CLIs, One tmux Session / full pathway.
Has anyone pushed this past two sessions, or cross-examined between more than two vendors' CLIs at once — does the signal hold up past a second opinion, or does it just get noisy?
Top comments (3)
I like the discipline of asking the second model to audit the first answer, not rerun the same prompt. That keeps the two sessions independent enough to catch a false premise. For production-ish changes, I’d want the second terminal to ask for the rollback path too, not just the root cause.
Good call! Rollback is always an important consideration
서로 다른 모델의 두 번째 의견을 받는 방식은 특히 장애 대응에서 유용해 보입니다. 다만 첫 모델의 결론만 넘기면 같은 가정에 끌려갈 수 있으니, 두 번째 모델에는 원본 로그와 재현 조건을 먼저 주고 독립적으로 원인을 적게 한 뒤 두 답을 비교하는 순서가 더 안전하겠어요.