What this prompt does
This prompt makes an AI assistant act as a senior architect who refuses to give a single answer. Instead it must propose three genuinely distinct implementations, each specified tightly enough to estimate. It takes four context variables — [requirement], [stack], [scale], and [constraint] — and for every approach returns a name, a high-level sketch, pros (including where it shines under [scale]), cons and failure modes, a 1-to-5 cost-and-complexity rating, and guidance on when to choose it. It closes with one recommendation and the single biggest risk to watch.
The three-option structure works because it breaks the model's habit of anchoring on its first idea and defending it. By forcing three distinct designs, you surface tradeoffs you'd otherwise never see. The [scale] variable matters most here: an approach that's elegant at low volume can fall apart under bursty traffic, and tying the pros to [scale] makes the model reason about that explicitly. The [constraint] field keeps all three options inside reality — for example, "stay on managed services, no self-hosted Kafka."
When to use it
- On architecture decisions that are expensive or hard to reverse later
- When designing notifications, queueing, caching, or other systems with real tradeoffs
- When you suspect the obvious first answer isn't the best one
- When you need to justify a design choice to teammates or a client
- When scale targets make some approaches viable and others not
- When a hard constraint rules out the default "textbook" solution
Example output
You get three labeled approaches, each with a sketch, pros tied to your scale target, cons and failure modes, and a 1-to-5 cost-and-complexity rating. After the three, you get a single clear recommendation and one line naming the biggest risk to watch. The format is comparison-first, so you can scan the tradeoffs side by side rather than reading one long essay defending a single design. Because each approach names when to choose it over the others, you can map your own priorities — cost, time to ship, operational simplicity — onto the spread instead of accepting the model's default ranking. The recommendation at the end is a starting position, not a verdict you have to take.
Pro tips
- Make
[scale]concrete ("10k concurrent connections, bursty traffic") so the pros and cons are grounded, not generic - Use
[constraint]to exclude options you genuinely can't run, which keeps all three answers actionable - If two of the three approaches feel like the same idea reworded, push back and ask for a genuinely different third
- Pay close attention to the single-biggest-risk line — that's usually where the real engineering work hides
- Tighten
[requirement]to one decision; bundling several muddies all three designs - Ask follow-ups on the cons section before committing, since failure modes are easy to gloss over
