11.5 Preventing conflicting instructions over time

Why conflicts accumulate

In long sessions you inevitably say things like:

• “Keep it simple” and later “optimize performance.”
• “No new deps” and later “use a library.”
• “Don’t change behavior” and later “change behavior.”

Humans can resolve these contradictions in their heads. Models can’t unless you make it explicit.

Symptoms of instruction conflict

• the model keeps repeating old constraints you no longer want,
• it ignores a rule you thought was stable,
• it “hallucinates” requirements that were only brainstorming,
• it produces inconsistent outputs across iterations.

Prevention: stable rules + spec block

The best prevention is structural:

• House rules: stable rules in a stable layer (Section 10.2).
• Spec block: authoritative requirements for the current task (Section 10.4).
• Summaries: periodically compress and re-anchor state (11.2).

Conflict audits (quick)

When you suspect drift, run a “conflict audit”:

• Ask the model to list all active constraints it is using.
• Ask it to list conflicts/ambiguities.
• Resolve conflicts explicitly by updating the spec block.

This is faster than debugging inconsistent behavior later.

Reset prompts (copy/paste)

Reset: summarize current authoritative state

Reset:
Summarize the current authoritative requirements and constraints in 10–20 bullets.
Then list any assumptions you are still making.
Stop and wait for my confirmation.

Reset: identify conflicts

List the active constraints you are applying.
If any constraints conflict or are ambiguous, call them out explicitly and ask which to prioritize.
Do not write code yet.

Where to go next

• 12. Safety, policies, and guardrails
• Reference: spec vs conversation