Prompting for analysis and decisions

1. What's different about decisions

For analysis and decisions, the failure mode isn't bad output — it's premature output. The model is happy to recommend something on turn one, with no real reasoning, especially if your framing nudges it toward a particular answer.

The fix is forcing the comparison before the recommendation. Make the model commit to specifics about each option before it picks. The verdict at the end is then anchored in the analysis, not in the model's read of which way you wanted to go.

2. The compare-then-recommend pattern

A shape that works across most decisions. The structure:

• For each option, list: strongest case for it, strongest case against it, the condition under which it's the right choice.
• Then recommend an option for my specific situation. The recommendation must reference at least one of the cases above.

Three things this does.

One. Forces the model to think about each option in isolation before comparing.

Two. The condition under which it's right line surfaces hidden assumptions — X is right when latency matters more than cost; Y is right when cost matters more. This is the actual decision content; the verdict is often less interesting than the conditions.

Three. The recommendation must reference clause prevents the model from drifting into a recommendation that ignores its own analysis.

3. The pair

Should I use Postgres or DynamoDB for storing user session data?

Output: "Both are good options, but DynamoDB tends to be better for session data because..." The model picks an answer in the first sentence and spends the rest justifying it. You learn one perspective.

I'm choosing between Postgres and DynamoDB for storing user session data.

For each option:
- Strongest case for it (one paragraph)
- Strongest case against it (one paragraph)
- The condition under which it's the right choice (one sentence)

Then recommend an option for my situation:
- ~1M active users
- Sessions are written on every page load, read on every request
- We already run Postgres for the main database; no AWS account today
- p99 latency target: 50ms for session reads

The recommendation must reference at least two of the conditions above.

Now you get a real comparison — both sides, both fairly. The recommendation is anchored in your stated conditions. If you change one of those conditions (no Postgres dependency, say), the recommendation might flip. That's useful information.

4. The trap — pre-loaded framing

Beware of phrasings that telegraph your preference. The model picks them up.

• Postgres or DynamoDB, but I'm leaning Postgres because... → Recommendation: Postgres.
• Postgres or DynamoDB; what would a senior engineer who hates Postgres choose? → Recommendation: DynamoDB.
• Postgres or DynamoDB. Both are fine; which fits the constraints below? → Genuine comparison.

If you want a real opinion, neutralize the framing first. State the constraints, ask for both sides, force the verdict to reference the constraints. The result will be more useful than your gut would have been.

5. Try it