"Give me the pros and cons of X" produces a document that is shaped like analysis. Four bullets each side, roughly equal weight, no conclusion. It reads as balanced because it is symmetrical, and symmetry is not the same as insight.

What I use instead:

`
I am considering: [decision].
Context: [constraints, team size, timeline, what already exists].

1. Steelman it. Argue for this decision as persuasively as you can,

as if you had proposed it and your reputation depended on it.

1. Now break it. You are the engineer who will be on call for this in

eighteen months. What goes wrong? Be specific about the failure,
not the category.

1. What would have to be true for step 1 to beat step 2?

1. Given my actual context above, is it true?

`

Step 1 exists to prevent hedging. Ask for a critique cold and you get mild, quotable objections. Make it commit to the position first and the subsequent teardown has something real to tear down.

Step 2's framing is doing the work. "On call in eighteen months" moves the answer from architectural taste to operational consequence. You stop getting "increases coupling" and start getting "the retry queue has no dead-letter path, so a bad payload wedges the consumer at 3am and the only fix is a manual offset reset."

Steps 3 and 4 are the point. Everything before them is setup. Step 3 extracts the load-bearing assumption; step 4 forces it to be checked against your situation rather than a generic one. This is where you find out that the whole case for the decision rested on a scale you do not have.

I have reversed two decisions on step 4 and confirmed several more. Both outcomes were worth the ten minutes.

Generated Outputs (1)

1 weeks ago

Claude

claude-opus-4

1 weeks ago

Generated Output

What would have to be true

The case for moving to the queue rests on three things: that write volume keeps growing at the current rate, that the consumers can tolerate a few seconds of lag, and that you have someone who knows the broker well enough to debug it under pressure.

Given your context

The first is true - you have doubled in five months. The second is true for everything except the invoice path, which a customer watches in real time; that one needs to stay synchronous regardless.

The third is not true. You said the team is four people and nobody has run this broker in production before. That is the assumption the decision is actually resting on, and it is the one you did not list as a risk.

Either close that gap first, or take the managed option and pay for someone else's 3am.

Steelman It, Then Break It: One Prompt For Any Technical Decision

Generated Outputs (1)