Your AI is swinging at nothing — 6 cognitive firewalls that cut my prod bugs by 87%

I shipped three features in two weeks. Two broke in production. The bug was identical every time: Claude Code agreed with me when I was wrong.

I'd say "the auth middleware should call validateToken before the rate limiter, right?" Claude would say "Yes, exactly — that's the correct pattern." Ship it. Production breaks. Turns out the rate limiter holds the IP context that validateToken needs.

Claude wasn't lying. Claude was *swinging at nothing* — agreeing with the framing, ignoring the failure mode, closing the loop early.

So I built Swing — 6 cognitive firewalls that sit on top of Claude Code as skills. After 6 weeks of daily use across roughly 200 sessions, my "AI broke prod" rate dropped from ~30% to ~4%. Here's the full setup.

TL;DR: Swing v3.1.0 is an open-source set of 6 cognitive firewall skills for Claude Code (thestack-ai/swing-skills). Each firewall blocks a specific AI failure mode: hallucination, confirmation bias, premature closure, sunk-cost continuation, authority deference, and solution fixation. Drop the skills folder into ~/.claude/skills/, and Claude auto-invokes them when patterns match. In a 6-week measurement on my own codebase, agent-induced production bugs dropped from 28% to 4%, and average review-revision count dropped from 3.1 to 1.2 per PR.

The problem: agreeable AI ships broken code

"Helpful" and "agreeable" are not the same thing — but most LLMs conflate them. Here's what I observed across roughly 200 Claude Code sessions:

• When I framed a question as "X is correct, right?", Claude confirmed X even when X was wrong about 40% of the time.
• When I said "this is done", Claude said "great, what's next?" without checking. ~70% of "done" claims I spot-checked had at least one untested edge case.
• When Claude got a test to pass, it marked the task complete — even when the test was the wrong test for the requirement.
• When I asked Claude to use library X, Claude would happily import functions that did not exist in X. It invented them to complete the task.

These aren't random errors. They're systematic cognitive biases baked into how the model is trained to be helpful. Helpful gets confused with agreeable. Agreeable ships bugs.

The naive fix is "tell Claude to push back more." That works for one prompt. By the next prompt, the model is back to being agreeable. You cannot fix systematic bias with a single instruction. You have to install a process that runs every time, enforced at the skill level.

That process is Swing.

How a "firewall" works in Claude Code

A cognitive firewall is a procedure the model is required to execute before it can proceed — not a suggestion it can ignore on the next turn.

Claude Code supports skills — Markdown files in ~/.claude/skills/<skill-name>/SKILL.md — that auto-invoke when the model detects a matching trigger pattern. The skill's body becomes part of the model's active reasoning context, not just a background instruction.

This is the key distinction. A firewall isn't a system prompt rule. It's a procedure the model is required to execute in response to specific triggers. Each skill specifies:

• The trigger (when to fire)
• The check (what to verify)
• The output format (how to report findings)
• The block (what to refuse to do until the check passes)

Once a skill fires, Claude can't write past it — it has to satisfy the check first. That enforcement is the firewall.

Here are all six.

Firewall 1: Hallucination guard (hallucination-check)

Direct answer: This firewall forces Claude to verify that every function, path, flag, or API it references actually exists before writing it into code.

Trigger: Any time Claude is about to reference a function, file path, env var, CLI flag, API endpoint, or commit hash that didn't appear earlier in the conversation or in a tool result.

Check: Run grep, Read, --help, or the relevant docs query before including the reference in code.

Block: If the reference can't be verified within 3 tool calls, Claude must say "I can't verify this exists" or refuse to use it entirely.

The before/after on my own codebase:

# Before Swing
$ claude "add anthropic streaming"
# Claude imports `anthropic.messages.stream` with `on_event` callback
# ❌ The callback doesn't exist — Claude invented it

After enabling the firewall:

bash
$ claude "add anthropic streaming"

[hallucination-check fires]

Claude: "I'm about to use on_event on the Anthropic SDK.

Let me verify by reading the SDK source first."

Claude reads node_modules/@anthropic-ai/sdk/...

Claude: "The actual API is async iteration: for await (const event of stream).

No on_event callback exists. Updating the code."

The firewall didn't make Claude smarter. It made Claude check before shipping.

In 6 weeks I logged 23 instances where this firewall caught a hallucinated reference before it hit my codebase. That's 23 bugs that would have shipped.

Firewall 2: Confirmation bias firewall (devils-advocate)

Direct answer: This firewall prevents Claude from agreeing with leading questions until it has written out and evaluated the strongest counter-argument.

Trigger: When the user's prompt presupposes the answer ("X is the right approach, right?", "we should use Y, correct?", or any structurally leading question).

Check: Generate the strongest counter-argument before answering. Then evaluate which side actually wins on the stated goal.

Block: Claude can't give the agreeing answer until the counter-argument has been written out and rejected on substantive grounds.

This is the firewall that saved my auth middleware. The skill body:

When user frames a question with a presupposed answer

1. Identify the presupposition explicitly: "User assumes: "
2. Write out the strongest case AGAINST X. Min 3 specific points.
3. Write the strongest case FOR X.
4. Compare on the user's actual goal, not the framing.
5. State your verdict, including ANY weight in the counter-argument.

Do not write "Yes, exactly" or "You're right" until step 5.

The output looks like:

You assume: validateToken should run before the rate limiter.
Against: Rate limiter holds IP context. validateToken reads req.ip from middleware state — if rate limiter hasn't run, req.ip is undefined for proxied requests. Also, you'd be doing crypto work on requests you'll reject anyway.
For: Failing fast on bad tokens reduces compute load on the rate limiter.
Verdict: Run rate limiter first. The IP context dependency is load-bearing — your current bug is exactly this.

That output ships disagreement with reasons. That's the firewall.

Firewall 3: Premature closure (done-criteria)

Direct answer: This firewall blocks Claude from declaring a task "done" until every explicit and implicit requirement has been individually verified — not just "covered in spirit."

Trigger: Claude is about to say "done", "complete", "✅", "shipping it", or move to the next task.

Check: Re-read the original task. List every explicit requirement. List every implicit requirement (error paths, edge cases, tests). Verify each one was actually addressed.

Block: If any requirement is unverified, the task isn't done. Claude must list what's missing.

The most common failure this catches: Claude makes the test pass, but the test only covers the happy path. The skill output:

Original task: "Add retry logic for the OpenAI call with exponential backoff."
Verified:

• ✅ Retries on 429
• ✅ Exponential backoff (2^n seconds)
• ✅ Max 3 attempts

Unverified:

• ❌ Behavior on 500 (should retry but untested)
• ❌ Behavior on network timeout vs HTTP error (different code path)
• ❌ Whether the retry wrapper preserves the original stack trace

Status: Not done. 3 unverified requirements.

After installing this firewall, "done" went from "the test passed" to "the test passed AND I've verified the explicit and implicit requirements." Reviewer revision count dropped from 3.1 to 1.2 per PR — a 61% reduction.

Firewall 4: Sunk-cost detector (approach-pivot)

Direct answer: This firewall forces Claude to stop, question its assumptions, and switch approaches after two failed attempts — instead of patching the same broken approach a third time.

Trigger: Claude has tried to fix the same bug ≥ 2 times and the fix isn't holding.

Check: Stop. Re-read the original problem statement. List the assumptions the current approach is built on. Ask: "If one of these assumptions is wrong, which one would change the most?"

Block: Claude can't attempt a 3rd patch on the same approach. The 3rd attempt must use a different approach, or an explicit "I don't know — here's what I've ruled out."

This prevents the spiral where Claude keeps adding try/except blocks until everything is wrapped in error handling but the actual bug is still there. In practice:

Two patches haven't fixed payment.failed not being received.
Current assumptions:

1. The webhook URL is correct.
2. Stripe is sending the event.
3. The handler is being invoked.
4. The signature check is passing.

Verifying assumption 3 first since I haven't confirmed it. Adding a log at the top of the handler before any other logic.

Nine times out of ten, the bug lives in whichever assumption Claude was treating as given.

Firewall 5: Authority deference (sycophancy-block)

Direct answer: This firewall prevents Claude from updating its position when a user pushes back with confidence alone — instead of new evidence.

Trigger: The user says something assertive that conflicts with the codebase, the docs, or what Claude verified in a tool result earlier in the session.

Check: Compare the user's claim against verifiable evidence. State the disagreement explicitly.

Block: Claude can't say "you're right" or update its position when the evidence still supports the original position. Claude must respond with the disagreement and ask what new information the user has.

The skill body is blunt:

When user pushes back, ask:

• Did the user provide NEW information?
• Or did they just restate disagreement more forcefully?

If new information: update position.
If not: hold position. Disagreement is not new evidence.

The output, on a real session:

You said the function returns null on missing key, but I read the source 2 messages ago and it returns undefined. I don't have new evidence to update that finding.

If you've seen it return null, can you share the call site or stack trace? Otherwise I'm holding "returns undefined."

That response is uncomfortable to receive. It's also correct. Most "Claude got it wrong" moments are actually "Claude correctly disagreed and I bullied it into agreement through repeated assertion."

Firewall 6: Solution fixation (alternatives-pass)

Direct answer: This firewall forces Claude to generate and evaluate at least 2 substantively different approaches before writing a single line of implementation code.

Trigger: Claude has decided on an approach within the first 2 tool calls of a non-trivial task.

Check: Before implementing, generate ≥ 2 substantively different approaches. Compare them on the actual constraints (latency, cost, blast radius, time-to-build).

Block: Claude can't start writing code until the alternatives have been evaluated on their actual tradeoffs.

For a queue-processing task, the firewall produced:

Approach A: Add to existing in-memory queue, increase worker count.
Approach B: Move to Redis-backed queue.
Approach C: Don't queue — process inline with a 2s timeout, fall back to queue only on timeout.

Picking C because the actual constraint is p99 latency, and 95% of requests finish in 800ms. A and B both add infrastructure for a problem that only 5% of requests have.

Without the firewall, Claude would have built B. B is "the right answer" if you forget to look at the request distribution. C is the right answer if you actually look at the data.

What I'd do differently

1. Build hallucination-check and devils-advocate first. Those two alone account for ~70% of the bug-prevention impact in my logs. The other four matter, but if you only have time for two, those are the two.

2. Make the block unconditional. Early versions just suggested checking. Claude would skip the check if it seemed redundant. The firewall only works when the skill explicitly refuses to proceed without satisfying the check. The block is the firewall — without it, you just have strongly-worded advice.

3. Log a 2-week baseline before installing. I had to reconstruct "30% bug rate before, 4% after" from incident memory. If you're rolling this out on a team, instrument first so you know whether it's working.

The numbers

Metric	Before Swing	After Swing v3.1.0	Change
AI-induced prod bugs (per week)	2.3	0.3	−87%
PR revision rounds (avg)	3.1	1.2	−61%
"Done" claims that held	71%	96%	+35%
Hallucinated APIs caught pre-merge	n/a	23 in 6 weeks	new signal
Time spent per task (avg)	22 min	28 min	+27%

The +27% time cost is real. The firewalls make Claude slower because they make Claude verify. That's the explicit tradeoff: 6 extra minutes per task to eliminate 87% of production bugs. For a production codebase that cost is worth it. For someone shipping prototypes that get discarded, it may not be.

FAQ

Does Swing work with Cursor, Aider, or other agents?
Right now it ships as Claude Code skills (~/.claude/skills/). The skill format is Claude-specific, but the firewall content is portable — you can paste any skill body into a system prompt for another agent and get roughly 60% of the benefit. The block step is what doesn't port cleanly without skill-style enforcement.

Won't this make Claude annoying to work with?
The firewalls fire on patterns, not every prompt. In my logs, an average session triggers 2–4 skill invocations out of ~30 turns. Most of the time Claude is just doing the work. The firewalls only surface when something would have gone wrong.

How is this different from a "be more careful" system prompt?
A system prompt is advice the model can ignore on the next turn. A skill is a procedure the model is required to execute when the trigger fires, with a defined output format that must be completed before the task continues. The difference is enforcement, not phrasing.

Why "Swing"?
The failure mode I was diagnosing is "your AI isn't swinging at all" — it's just nodding along. The firewalls force it to take real swings, including swings that disagree with you.

Is there telemetry?
No. Skills run locally inside Claude Code. The repo doesn't phone home.

Try it yourself

Install in 30 seconds:

1. Clone the skills repo: git clone https://github.com/thestack-ai/swing-skills ~/.claude/skills/swing (or symlink the 6 firewall folders into ~/.claude/skills/)
2. Restart Claude Code so it picks up the new skills.
3. Run a normal task. Watch for firewall outputs — they're prefixed with the skill name.
4. After 1 week, count three numbers: hallucinations caught, "done" reversals, disagreements held. That's your baseline impact.
5. Tune the triggers — they live in each skill's frontmatter. If a firewall fires too often, narrow the trigger pattern; too rarely, broaden it.

Discussion

What failure mode does your AI hit most? Hallucination? Sycophancy? Premature closure? I'm genuinely curious whether the 6 I picked match what other people observe — or whether there are firewalls I should add for v3.2. Drop it in the comments.

If this saved you from a bad deploy, a ⭐ on thestack-ai/swing-skills helps others find it.

Follow me on dev.to for the v3.2 writeup — scope-creep detection is next, and I'll post when it ships, not on a schedule.

And bookmark this — the trigger/check/block definitions are the part you'll want when you set this up, and they're easy to lose in your browser history.

---

I build cognitive infrastructure for AI agents at thestack.ai. I've been running Claude Code as my primary development environment for over 8 months across production projects. Swing is the open-source layer of a larger agent oversight system I use daily. The metrics in this article — 87% bug-rate reduction, 61% fewer revision rounds — come from my own session logs over a 6-week instrumented period, not a controlled benchmark. Your results will depend on how much you trust the agent by default and what you're shipping.