Español

Never Accept Your AI's First Plan Without the Loser

Never accept your AI's first plan without seeing the loser. When an agent hands you a single approach with a tidy paragraph of justification, you are not looking at a decision — you are looking at a default. The model reached for the first plausible pattern in its training distribution and then rationalized it after the fact. That is not the same thing as weighing options and choosing.

Why one option is a red flag

A choice only means something relative to what you rejected. If nothing was rejected, nothing was chosen. Single-option output hides three failure modes at once: the model never explored the space, so it can't tell you what it skipped; it can't surface the trade-off that actually matters to you; and when the plan hits a wall in week two, you have no documented fallback and no record of why this path won.

This isn't a quirk of one model — it's how greedy generation works. Ask for "the answer" and you get the highest-probability continuation, which is confident, fluent, and completely silent about the roads not taken.

The fix: diverge, then converge

Make the agent do two separate jobs in order. First diverge — generate genuinely different approaches, not three flavors of the same idea. Then converge — score them and commit to one, keeping the strongest runner-up on the record.

Drop this into your prompt or your agent's planning step:

Before recommending anything, generate at least THREE genuinely different
approaches. They must differ in structure, not just naming.

Score each on: implementation cost, blast radius / risk, and reversibility.

Then output:
  1. Your pick and why.
  2. The strongest runner-up and the SPECIFIC reason it lost.
  3. The trigger that would make the runner-up the right call instead.

That last line is the one people forget. "Why it lost" is a static verdict; "what would flip it" is a live fallback you can act on when reality disagrees with the plan.

The payoff

The runner-up earns its keep twice. When the pick stalls — the library you chose gets deprecated, the API you assumed doesn't exist — you already have the next move written down, along with the conditions that now favor it. And the rejected option is the audit trail that proves the choice was reasoned, not the path of least resistance. This is exactly why mature engineering teams write Architecture Decision Records with a required "Considered Options" and "Pros and Cons" section: recording only the winner throws away the analysis that made the decision defensible.

Power moves

• Force divergence by sampling, not asking. Requesting three options in one greedy response often yields three near-duplicates. Instead, generate the options in separate runs at higher temperature, then have a fresh call judge them. This is the same "sample many reasoning paths, then reconcile" idea behind self-consistency and Tree of Thoughts — divergence comes from independent samples, not from politely asking one pass to be creative.
• Name the decision drivers first. Before the agent proposes anything, make it list the criteria the solution must satisfy. Options judged against explicit drivers beat options judged against a gut feeling — and you can check whether the winner actually meets them.
• Ban the tie. If the model says two options are "roughly equal," it hasn't finished thinking. Force a ranked pick and a concrete tiebreaker; a real runner-up loses for a specific, stateable reason.

Resources

• About MADR — the Markdown ADR template — makes "Considered Options" and "Pros and Cons of the Options" required sections.
• ADR Templates — full and minimal decision-record templates to copy.
• Self-Consistency Improves Chain of Thought Reasoning (Wang et al., 2022) — sample diverse reasoning paths, then reconcile.
• Tree of Thoughts: Deliberate Problem Solving with LLMs (Yao et al., 2023) — explore multiple branches before committing.