Yes-or-no when you wanted a list

1. The failure mode

The shape of the question determines the shape of the answer. Ask a yes/no question and you get a yes-or-no answer — even if what you actually wanted was the supporting list.

• Is this code good? → Yes, this code is well-structured. (You wanted the list of issues.)
• Should I use Redis here? → Yes, Redis is a good fit. (You wanted the comparison.)
• Are there any bugs? → I don't see any major bugs. (You wanted the bug list.)

In every case, the answer is technically responsive and operationally useless. The model answered the question you asked. You wanted a different question answered.

2. The reframe

When you want a list, ask for a list. The mechanical move:

• Is X good? → What's wrong with X? List up to N issues.
• Should I use Y? → Compare Y with Z. For each, list one upside and one downside.
• Are there bugs? → Find bugs. Return JSON. Empty array if none.

The reframe always shifts the verb from existence (is, are, should) to enumeration (list, find, compare). Enumeration prompts the model into producing the structure you wanted.

3. Same intent, two framings

Is this approach good? I'm using a single table for both users and admins, with a 'role' column.

The output: "Yes, that approach works well for most use cases. It's a common pattern called single-table inheritance, and..." You scan three paragraphs and learn nothing.

I'm using a single table for both users and admins, with a 'role' column.

List the three strongest arguments FOR this design.
List the three strongest arguments AGAINST it.
Then recommend an approach for our context: ~10k users, ~50 admins, role rarely changes.

Now the model has to commit to specifics on both sides before the recommendation. You read a real argument structure, not a verdict.

4. Try it