Give Your AI CLI a Second Opinion — In a Second Terminal

Brad Penney — Mon, 10 Aug 2026 01:23:13 +0000

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?

DEV Community: Brad Penney

Give Your AI CLI a Second Opinion — In a Second Terminal

The setup

The critical bit

Use for the tough questions, not every question