When an AI brainstorming session starts repeating itself, adding “be more creative” is the prompting equivalent of restarting a service without reading the logs.
You may get different wording, but you have not identified the failure mode.
This post treats brainstorming as a small iterative system: define the state, inspect the default output, change one variable, run an adversarial check, and save a decision artifact.
The failure modes
Most stalled sessions I see can be described by one of four conditions:
UNDER_SPECIFIED: no meaningful constraints or evaluation criteria
OVER_CONSTRAINED: every important choice has already been made
LOCAL_LOOP: the model keeps remixing its first answer
NO_EXIT: the conversation generates options but never selects one
Before changing the prompt, label the failure. A useful diagnostic question is:
Is the output weak because the model lacks context, lacks tension, cannot leave its first frame, or has no rule for finishing?
The answer determines the next pass.
Pass 1: Define state and acceptance criteria
Start with a compact state object. This can be plain text; JSON simply makes omissions visible.
{
"task": "design a tutorial project for junior backend developers",
"audience": "developers who know basic HTTP and SQL",
"must_include": ["observable failure", "small deployable service"],
"avoid": ["todo app", "URL shortener"],
"success": ["teaches one production tradeoff", "buildable in a weekend"]
}
This is enough structure to evaluate ideas without dictating the answer.
Checkpoint: if two people would interpret success differently, revise the criteria before generating more options.
Pass 2: Request the default—and its assumptions
Instead of pretending the first answer will be original, ask the model to expose its defaults.
Generate the three most obvious project ideas for this state.
For each, list the assumption that makes it predictable.
Do not improve them yet.
This creates a baseline. It is the prompt equivalent of reproducing a bug before patching it.
You may learn that every idea assumes a request-response API, a single user, or a happy-path database. Those hidden assumptions are more actionable than another list of titles.
Pass 3: Mutate one variable
Change exactly one governing assumption and request the consequences.
Mutation: the service must continue producing a useful result when its primary database is temporarily unavailable.
Generate three ideas that follow from this mutation.
For each, explain what the learner can observe and measure.
Keep all other state unchanged.
Why only one variable? If you alter the audience, constraints, architecture, and outcome together, you cannot tell which change improved the result.
This pass also gives you a useful regression check: does the answer actually incorporate the mutation, or does it return to the original pattern with new vocabulary?
Pass 4: Run an adversarial review
Choose the strongest candidate and attack it with a specific reviewer lens.
Act as a maintainer reviewing this tutorial proposal.
Reject it if the learning outcome is hidden, the setup dominates the lesson,
or the failure cannot be reproduced reliably.
Return:
- strongest objection
- missing prerequisite
- smallest repair
- reason to abandon the idea entirely
“Be critical” is too vague. A reviewer with rejection criteria produces feedback you can use.
Do not automatically accept the repair. The purpose is to reveal tradeoffs before implementation.
Pass 5: Serialize the decision
End the loop with a small record that can survive outside the chat:
chosen: "offline-first incident journal"
reason: "makes degraded-mode behavior visible without a large stack"
rejected:
- idea: "distributed rate limiter"
reason: "too much setup for the target audience"
risk: "local conflict resolution may distract from the core lesson"
next_test: "prototype the failure scenario in under 30 lines"
Without this step, the session has no stable output. Tomorrow, you will reopen a long transcript and reconstruct the decision from scratch.
Separate exploration from factual trust
This loop is designed for idea quality, not factual verification. If the AI proposes a library, API behavior, security pattern, performance claim, or licensing detail, check the current official documentation before implementation.
A convenient note convention is:
[IDEA] worth exploring
[CLAIM] verify against a primary source
[DECISION] chosen by the human owner
It prevents fluent suggestions from silently becoming requirements.
When the chat environment becomes the constraint
Different AI chat products have different conversational behavior. If a legitimate creative or research prompt repeatedly collapses into generic responses or unnecessary refusals, changing the workspace may be part of debugging the workflow.
XPT is designed for more open-ended AI conversations and supports use cases including brainstorming, writing, research, coding, roleplay, and model selection. It may fit sessions where following an unconventional line of thought matters. Results vary by model and request, and a more open conversation still requires factual verification and lawful, responsible use.
The loop in one function
state = define(task, audience, constraints, success)
baseline = expose_defaults(state)
candidate = mutate_one_assumption(baseline)
review = adversarial_check(candidate, rejection_criteria)
decision = serialize(choice, reason, risk, next_test)
The key is not the syntax. It is observability. Once you can see the defaults, mutations, rejection criteria, and exit condition, “the AI is being repetitive” becomes a problem you can actually debug.
Disclosure: This article was created with AI assistance for the XPT content team, then reviewed and edited for factual accuracy and practical usefulness.
Top comments (0)