Ask for Alternatives, Then Choose With a Rubric

The first answer is not automatically the best answer. It may simply be the easiest pattern for the model to produce. I ask for a few distinct approaches, then compare them against a rubric I wrote before seeing the options. For idea-heavy work, Use AI for Brainstorming, Then Narrow With Real Criteria turns a long list into a small, testable shortlist.

For a browser game without accounts, I might ask: Give three ways to save a player's local progress. For each, describe what survives a refresh, what survives a new device, setup effort, and one failure mode. Do not recommend one yet. State assumptions. The options might include in-memory state, browser storage, and a server-backed system. The important step is to compare them against the actual goal. If the goal is “survive a refresh during a prototype,” browser storage may be enough. If the goal is “sync across devices,” the same choice fails.

I can ask the model to list criteria, but I choose their weight. For a weekend prototype, speed and reversibility may outrank scalability. For a live product with paying users, data-loss risk is much more important. A tidy comparison table does not decide that for me.

Three options with different names but the same tradeoff are not useful. Ask: Which decision changes between these options? Merge duplicates and replace one with a meaningfully different approach. Then run a quick reality check against official documentation or your actual codebase. Alternative generation is brainstorming, not validation. Try it: Choose a decision you have been postponing. Ask for three options without a recommendation. Write your three most important criteria before reading the result, then score each option. If the best option depends on a missing fact, ask for that fact rather than guessing. Keep learning: Use AI for Brainstorming, Then Narrow With Real Criteria, Prompt AI for a Game Idea Without Getting Generic Tropes, and How to Tell Whether an AI Answer Is Any Good.