Context Confusion

Module 8.3: Context Confusion

Estimated time: ~30 minutes

Prerequisite: Module 8.2 (Loop Detection & Breaking)

Outcome: After this module, you will recognize context confusion symptoms, understand its causes, and know when and how to use /compact and /clear to restore clarity.

---

1. WHY — Why This Matters

You’re 2 hours into a coding session. You ask Claude to update the user service. It produces code that references an old API structure you discussed an hour ago — not the new one you agreed on 30 minutes ago. You correct it. Claude apologizes and produces code referencing BOTH structures mixed together. Now you’re more confused than before.

The problem isn’t Claude being incompetent. The problem is context confusion — Claude is trying to satisfy contradictory information from different points in the conversation. Long sessions accumulate lots of decisions, changes, and pivots. Without management, this creates a soup of conflicting context that leads to inconsistent output.

---

2. CONCEPT — Core Ideas

What is Context Confusion?

Context confusion is when Claude mixes up information from different parts of the conversation:

• Using outdated decisions when newer ones exist
• Blending details from different files or features
• Applying patterns from one discussion to an unrelated topic
• NOT forgetting — rather, failing to prioritize recent information over old

Unlike hallucination (inventing facts) or stuck loops (repeating actions), context confusion involves real information from your conversation — just misapplied or blended incorrectly.

Context Confusion vs. Other Problems

Problem	What’s Happening	Key Symptom
Hallucination	Making up facts	Information not in conversation at all
Stuck loop	Repeating same action	Same error/edit pattern
Context confusion	Mixing up real info	References to OLD or MIXED decisions

Causes of Context Confusion

1. Long sessions (2+ hours of dense work)
2. Topic switches (worked on feature A, now on B — confuses A and B)
3. Contradictory updates (“Actually, change X to Y” creates tension between old X and new Y)
4. Multiple similar files (mixing up userService.ts vs userController.ts)
5. Interrupted sessions (came back after break, context partially stale)

Confusion Symptoms

Watch for these warning signs:

• References to decisions you changed or abandoned
• Code using patterns from earlier (now superseded) discussion
• Mixing up file names or component names
• Inconsistent naming within the same response
• “Didn’t we already decide…” when you didn’t

Prevention and Cure

Prevention:

• Proactive /compact before topic switches
• Explicit statements: “Forget about X, we’re now doing Y”
• Periodic compaction during long sessions

Cure:

• /compact to condense and clarify context
• /clear for severe cases (nuclear option)
• Re-grounding: After /compact, explicitly re-state current state

When to Use /compact

Is Claude referencing outdated info? → /compact
Switching to new major topic? → /compact first
Session > 1 hour of dense work? → Proactive /compact
Code mixing patterns from different discussions? → /compact + re-state
Severe confusion, nothing helps? → /clear + fresh start

---

3. DEMO — Step by Step

Scenario: After working on user authentication, you switch to payment integration. Claude confuses auth patterns with payment patterns.

Step 1: Observe Confusion Symptoms

You: Let's implement the payment webhook handler.

Claude: I'll create the payment webhook handler. Based on our earlier
discussion, I'll use the JWT validation middleware...

[Claude produces code with JWT auth logic in payment webhook]

Problem: Payment webhooks use signature verification with a secret key, not JWT. Claude is mixing auth context with payment context.

Step 2: Confirm Confusion

You: Wait, payment webhooks don't use JWT. They use signature verification
with the webhook secret. We discussed JWT for user authentication, not webhooks.

Claude: You're right, I apologize. Let me fix that...

[Claude produces code still importing JWT middleware but ALSO adding
signature verification — a MIXED approach]

Worse: Now it’s blending both approaches together. Correction didn’t help — the confusion is too deep.

Step 3: Use /compact to Clear Confusion

/compact

Expected output:

Context compacted. Summary retained:
- Working on payment system integration
- Need webhook handler for payment notifications
- Project uses TypeScript, Express

Step 4: Re-ground After Compact

You: To be clear for the webhook handler:
- This is for PAYMENT webhooks (Stripe, VNPay), NOT user auth
- Use signature verification with webhook secret
- No JWT involved whatsoever

Now implement the webhook handler.

Claude: Understood. Here's the payment webhook handler using signature
verification:

[Clean code with ONLY signature verification, no JWT confusion]

Key technique: /compact removes the noise. Re-grounding ensures Claude has correct current context. Together, they restore clarity.

---

4. PRACTICE — Try It Yourself

Exercise 1: Induce and Fix Confusion

Goal: Experience context confusion firsthand and practice fixing it.

Instructions:

1. Start a session, discuss implementation approach A in detail (e.g., REST API)
2. Pivot to approach B (e.g., GraphQL) without /compact
3. Ask Claude to implement something — watch for A contamination in B
4. Use /compact + re-grounding to fix

Expected result: You’ll see mixed patterns before /compact, clean output after.

💡 Hint

Good confusion triggers:

• “Let’s use REST” → discuss for 10 min → “Actually, let’s use GraphQL instead”
• “We’ll store in PostgreSQL” → discuss → “Switch to MongoDB”

Watch for: old patterns appearing in new implementation, mixed terminology.

Exercise 2: Proactive Compaction

Goal: Practice preventing confusion before it happens.

Instructions:

1. Work on a feature for 30+ minutes
2. Before switching topics, run /compact proactively
3. Explicitly state: “New topic: X. Previous topic Y is complete, don’t reference it.”
4. Compare: is confusion less than without proactive compaction?

Expected result: Cleaner transitions, less contamination from previous topic.

Exercise 3: Re-grounding Drills

Goal: Find re-grounding phrases that work for your workflow.

Instructions:

1. After /compact, practice different re-grounding phrasings:
   • “To be clear: current state is…”
   • “Forget everything about X. We’re now doing Y with approach Z.”
   • “Here’s what matters NOW: [requirements]”
2. Note which phrasings produce the cleanest responses

✅ Solution

Most effective re-grounding patterns:

After topic switch:

Previous topic (auth) is COMPLETE. Do not reference it.
New topic: Payment processing.
Key facts:
- Webhook verification uses HMAC signature
- No JWT, no user tokens
- Framework: Express with raw body parsing

After confusion detected:

STOP. Clear your assumptions about this file.
Current truth:
- File: paymentWebhook.ts
- Purpose: Verify and process Stripe webhooks
- Auth method: Signature verification ONLY
Start fresh with this understanding.

---

5. CHEAT SHEET

Confusion Symptoms

Symptom	Action
References to OLD decisions	/compact
Mixed patterns from different discussions	/compact + re-ground
Inconsistent naming	Correct once; if repeats → /compact
”Didn’t we already…” (when you didn’t)	Confusion confirmed → /compact

/compact Timing

• Before major topic switch
• After 1 hour of dense work
• When you see confusion symptoms
• Proactively when context feels “heavy”

Re-grounding Templates

After /compact:

"Current state: We're implementing [X] using [Y approach].
Previous discussion about [Z] is no longer relevant.
Continue with [specific next step]."

"Forget [old topic]. New focus: [new topic].
Key constraint: [most important requirement]."

/compact vs /clear

Command	Effect	When to Use
/compact	Condense context, preserve key decisions	First response to confusion
/clear	Nuclear reset, lose everything	When /compact doesn’t help

---

6. PITFALLS — Common Mistakes

❌ Mistake	✅ Correct Approach
Long sessions without /compact	Proactive /compact every hour or at topic switches
/clear as first response to confusion	Try /compact first. /clear loses progress.
/compact without re-grounding	Always re-state current context after /compact
Assuming Claude “remembers” recent stuff better	Recency doesn’t guarantee priority. Be explicit.
Not recognizing confusion (blaming Claude)	Mixed references = confusion, not incompetence
Too many corrections without reset	3 corrections for same confusion? /compact time.
Switching topics without notice	Explicit: “We’re done with X. Now doing Y.”

---

7. REAL CASE — Production Story

Scenario: Vietnamese team building e-commerce platform. Developer worked on product catalog for 2 hours, then switched to order processing. Claude kept putting product-related code into the order service.

Symptoms observed:

• Order service importing ProductValidator
• Order webhook checking inventory (product concern, not order concern)
• Naming confusion: productOrder variable instead of order
• References to “catalog sync” in order processing comments

Diagnosis: Context confusion from long session + topic switch without compaction.

Fix applied:

/compact

Then:

New context: We're ONLY working on ORDER service now.
- Product catalog is DONE, don't reference it
- Order service handles: checkout, payment, fulfillment
- No product validation in order service
- No inventory checks here (that's product domain)

Continue with order webhook handler.

Result: Clean order service code with no product contamination. Clear domain boundaries maintained.

Team practice added: “Switching domains? /compact first, then state new context explicitly. We call it the ‘clean slate protocol.’”

Time saved: Estimated 45 minutes of debugging mixed concerns, prevented by 30 seconds of /compact + re-grounding.

---

Next: Module 8.4: Quality Assessment →