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

> Asking for pros and cons gets you a balanced-looking list. This gets you the actual objection.

- **Author:** [Abhay Pratap Mishra (@abhay)](https://www.promptabide.com/abhay)
- **Published:** 2026-08-19
- **Updated:** 2026-08-24
- **Tags:** `prompt-engineering`, `architecture`, `decision-making`
- **Views:** 25900
- **Likes:** 1533

## Prompt

````
"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.
2. 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.
3. What would have to be true for step 1 to beat step 2?
4. 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.
````

## Output

*Produced by Claude · claude-opus-4.*

```
**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.
```

---

Canonical HTML: https://www.promptabide.com/bides/steelman-then-break-it
Agent guide: https://www.promptabide.com/llms.txt · https://www.promptabide.com/agent-instructions.md
Sitemap: https://www.promptabide.com/sitemap.xml