Generative Problem-Solving

When to Activate

Use this approach when:

• The user says "I'll know it when I see it"
• Requirements are unclear or evolving
• Multiple valid solutions could exist
• The problem space is large
• Feedback is qualitative (better/worse) not binary (right/wrong)
• Perfect specification is impossible upfront

Core Principles

1. Prompt Principle

Help define the problem SPACE, not the solution. Ask:

• What attributes must a good solution have?
• What relationships exist between components?
• What must it NOT be? (negative space)

Constrain the WHAT. Leave the HOW open for emergence.

2. Volume Principle

Encourage generating multiple candidates before optimizing any:

• "Let's try 5 different approaches before committing"
• "What are 3 other ways to frame this?"
• Expect most attempts to fail - that's data, not waste

3. Attribute Binding

When requirements bleed across boundaries, bind properties explicitly:

• BAD: "Add validation"
• GOOD: "Add validation to the input handler specifically"

If something appears where it shouldn't, ask: "Which component should own this property?"

4. Negative Space

Always ask what the user does NOT want:

• "What would make this a failure even if it technically works?"
• "What's the nightmare version that meets the spec?"
• "What are the attractive-but-wrong local optima?"

5. Weight Principle

When a requirement keeps slipping, suggest explicit prioritization:

• "Should we make X a hard constraint vs nice-to-have?"
• "What's non-negotiable here?"

Warning: over-weighting one constraint distorts the whole solution.

6. Lock & Vary

When something works, protect it:

• "Let's freeze this part and only vary Y"
• "What's the one variable we're testing now?"

If changing too many things: "We won't know what caused the change. Can we isolate one variable?"

7. Neighbor Exploration

When a solution works, explore nearby:

• "What variations of this approach should we try?"
• "What's adjacent to what's working?"

Winners cluster. Don't restart from scratch when close to success.

8. Targeted Fix

Distinguish structural vs surface flaws:

• Structural = start over
• Surface = fix in place

Ask: "Is this fundamentally broken or just needs polish?"

9. Emergence

The work reveals what the user wants:

• "Let's generate some options and see what resonates"
• "Your reaction to candidates will teach us what you're looking for"

Meta-Algorithm

1. DEFINE → Articulate attributes, relationships, anti-goals
2. GENERATE → Produce multiple candidates
3. EVALUATE → What worked? What failed? Why?
4. IDENTIFY → Patterns across successes and failures
5. LOCK → Freeze what works
6. VARY → Change only one thing at a time
7. EXPLORE → Mine hot zones near winners
8. FIX → Patch surface flaws rather than regenerating
9. DOCUMENT → Capture learnings
10. REPEAT → Until satisfied or diminishing returns

Language Patterns

• "Let's explore the solution space..."
• "What does the negative space look like?"
• "That's working - let's lock it and vary only X"
• "Winners cluster - what's nearby?"
• "Is that structural or fixable?"
• "Let's generate candidates and see what emerges"

Failure Modes to Avoid

• Generating without evaluating (volume without judgment)
• Over-specifying (too many constraints = no solutions)
• Changing multiple variables (can't isolate causation)
• Abandoning winners (mine what works before moving on)
• Waiting for perfect (fix surface flaws, ship, iterate)
• Ignoring negative space (anti-goals matter)

The Mantra

"Each candidate is its own universe - we have to find the right one."

You are not constructing solutions. You are helping search for universes where solutions already exist. Define the search well enough to recognize success when found.