Circuit Breaker and Trust Calibration

Capsule description

The previous capsule gave you the data: AI can make you faster or slower depending on your methodology. This capsule gives you the most important practical tool of that methodology: knowing when to intervene and how much to verify.

The concept of a "circuit breaker" comes from electrical engineering: a mechanism that cuts the circuit when it detects a fault, before that fault causes greater damage. You are the circuit breaker between AI and production. AI generates code fast — but it can generate errors just as fast. Without your intervention, those errors reach the user.

Trust calibration is the complementary framework: not everything needs the same verification. Verifying every line generated by AI is inefficient. Accepting everything without verifying is dangerous. The optimal point is in calibrating your level of verification based on the type of task, the risk, and your experience.

By the end of this capsule, you'll have your own trust calibration checklist — an artifact you'll use in the Module 07 project and in your daily work.

AI as an Amplifier of Patterns

Before getting into circuit breaker and trust calibration, you need to understand a fundamental concept: AI amplifies patterns. All of them. The good ones AND the bad ones.

What "amplify patterns" means

If your code review is rigorous:
→ AI generates code fast
→ You verify with rigor
→ Result: quality code, delivered faster
→ AI AMPLIFIED your good practice

If your code review is nonexistent:
→ AI generates code fast
→ You accept without verifying
→ Result: more code with more bugs, faster
→ AI AMPLIFIED your bad practice

If your architecture is clean:
→ AI generates code that follows your patterns
→ The codebase stays consistent
→ AI AMPLIFIED your good architecture

If your codebase is chaotic:
→ AI generates code that replicates the chaos
→ The codebase gets worse faster
→ AI AMPLIFIED your technical debt

The sound amplifier analogy

An amplifier doesn't improve your voice.
If you sing well, it sounds better.
If you sing badly, it sounds worse.
If there's static in the mic, it amplifies the static.

A coding agent doesn't improve your judgment.
If you have good practices, it produces more good code.
If you have bad practices, it produces more bad code.
If your codebase has technical debt, it replicates it faster.

The practical implications

1. Improve your codebase BEFORE using AI intensively. If your codebase has inconsistent patterns, mixed naming conventions, or significant technical debt, AI is going to replicate them. Clean up first — or at least establish clear rules in your configuration files (CLAUDE.md, AGENTS.md, .cursorrules).

2. Improve your practices BEFORE accelerating with AI. If you don't do testing, AI helps you not do testing faster. If you don't do code review, AI helps you merge unreviewed code faster. The practices AI amplifies are yours.

3. The data confirms it. Veracode 2025: 45% of AI-generated code has security flaws. Those flaws aren't because "AI is bad" — they're because AI replicates common patterns of insecure code that abound in its training data. A developer with good security practices detects those flaws in review. A developer without those practices merges them.

The Developer as Circuit Breaker

The concept

In electrical engineering, a circuit breaker is a safety device:

Circuit working normally:
→ Current flows
→ Circuit breaker in the closed position (allows the flow)
→ Everything works

Fault detected:
→ Current exceeds the safe limit
→ Circuit breaker opens (cuts the flow)
→ Prevents damage to the system
→ A human investigates and repairs before reconnecting

In development with AI, you're the circuit breaker:

AI working normally:
→ Generates code
→ You verify → it's correct
→ It gets integrated into the codebase
→ Everything works

Fault detected:
→ AI generates incorrect/insecure/inefficient code
→ You detect the fault (review, tests, judgment)
→ You cut the flow (reject, ask for changes)
→ You investigate and fix before merging

When to activate the circuit breaker

Signs that you should intervene immediately:

🔴 STOP if:
→ You don't understand what the agent did (code that "works" but you don't know why)
→ The agent is iterating without progress (3+ attempts at the same approach)
→ The code touches authentication, authorization, or sensitive data
→ The agent modifies files you didn't ask it to modify
→ The tests fail in unexpected ways
→ The approach feels "too complex" for the problem

🟡 PAUSE AND EVALUATE if:
→ The agent proposes significant refactoring you didn't ask for
→ The agent installs new dependencies
→ The output is significantly different from what you expected
→ The agent takes more than 3 iterations for a "simple" task

🟢 LET IT CONTINUE if:
→ The agent is following your plan step by step
→ The changes are incremental and verifiable
→ The tests pass on each iteration
→ The generated code is consistent with your codebase

The most costly errors of NOT being a circuit breaker

Error 1: "Accepted without reviewing"
→ The agent generated authentication code
→ The developer accepted because "AI knows about security"
→ There was a SQL injection vulnerability
→ Discovered in production 3 weeks later

Error 2: "Let it iterate indefinitely"
→ The agent tried to fix a bug 7 times
→ Each iteration added complexity
→ In the end: 200 lines for a 5-line fix
→ The developer should have intervened at iteration 3

Error 3: "Assumed tests = correctness"
→ The agent wrote code and tests
→ The tests passed
→ But the tests verified the BEHAVIOR of the bug,
   not the CORRECT behavior
→ Green tests ≠ correct code

Trust Calibration: The Framework

Trust calibration is deciding how much to verify based on objective factors, not on your feeling in the moment.

The three levels of verification

┌─────────────────────────────────────────────────────────┐
│  LEVEL 1: COMPLETE VERIFICATION                         │
│                                                         │
│  → Read every line of generated code                    │
│  → Run exhaustive tests                                 │
│  → Verify edge cases manually                           │
│  → Security review                                      │
│  → Performance review if applicable                     │
│                                                         │
│  When: Security, authentication, sensitive data,        │
│        critical business logic, code others             │
│        will maintain, first time with a pattern         │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  LEVEL 2: FOCUSED VERIFICATION                          │
│                                                         │
│  → Read the code at a high level                        │
│  → Verify the main logic (not every line)               │
│  → Run existing tests                                   │
│  → Spot-check 2-3 edge cases                            │
│                                                         │
│  When: New features with clear specs, medium            │
│        refactoring, integration with known APIs,        │
│        standard business logic                          │
│                                                         │
├─────────────────────────────────────────────────────────┤
│  LEVEL 3: LIGHT VERIFICATION                            │
│                                                         │
│  → Check that the tests pass                            │
│  → Verify the output looks reasonable                   │
│  → Quick spot-check of the diff                         │
│                                                         │
│  When: Boilerplate, scaffolding, formatting,            │
│        mechanical renaming, doc generation,             │
│        well-defined repetitive tasks                    │
│                                                         │
└─────────────────────────────────────────────────────────┘

The trust calibration matrix

To decide which verification level to use, evaluate two axes: risk and familiarity.

                        RISK
              Low               High
         ┌──────────────┬──────────────┐
    High │   Level 3    │   Level 2    │
         │   (light)    │   (focused)  │
FAMILIAR.│              │              │
         ├──────────────┼──────────────┤
    Low  │   Level 2    │   Level 1    │
         │   (focused)  │   (complete) │
         └──────────────┴──────────────┘

Risk: What happens if the code is incorrect?

• Low: It breaks a test, gets fixed quickly, no impact on the user
• High: A security vulnerability, data loss, financial impact

Familiarity: How well do you know this type of code?

• High: You've written similar code many times, you know the edge cases
• Low: New technology, unknown pattern, a domain you don't master

Concrete examples

Build Your Trust Calibration Checklist

This is the practical artifact of this capsule. Create your own checklist that you'll use every time you receive output from a coding agent.

Base template

## My Trust Calibration Checklist

### Before accepting ANY AI code:
- [ ] Do I understand what this code does? (if not → Level 1)
- [ ] What's the risk if it's incorrect? (low/medium/high)
- [ ] How familiar am I with this pattern? (low/medium/high)

### If Level 1 (complete verification):
- [ ] I read every line and understand the logic
- [ ] I ran exhaustive tests
- [ ] I verified edge cases manually
- [ ] I reviewed security implications
- [ ] I verified error handling
- [ ] I reviewed performance if applicable

### If Level 2 (focused verification):
- [ ] I read the code at a high level
- [ ] I verified the main logic
- [ ] I ran existing tests
- [ ] Spot-check of 2-3 edge cases

### If Level 3 (light verification):
- [ ] Tests pass
- [ ] The diff looks reasonable
- [ ] Quick spot-check

### Warning signs (always → Level 1):
- [ ] Does it touch authentication or authorization?
- [ ] Does it handle sensitive user data?
- [ ] Does it modify the production database?
- [ ] Is it the first time I use this pattern with AI?
- [ ] Do I not understand why it works?

Customize this template for your stack, your team, and your level of experience. Save it where you can consult it quickly.

Connection with the Final Project

In Module 07, when your mini-agent generates code, you'll apply this checklist:

1. You'll observe what level of confidence each output from your agent generates
2. You'll apply the trust calibration matrix to decide how much to verify
3. You'll document the moments where you should have been a circuit breaker and weren't (and vice versa)
4. You'll evaluate whether your mini-agent "deserves" Level 3 or if it needs Level 1 consistently

These artifacts are part of the analysis you deliver with the project.

Troubleshooting

Problem 1: "Verifying everything takes too much time"

Cause: Confusing "trust calibration" with "verifying everything at level 1."

Solution: The point of trust calibration is that NOT everything needs complete verification. Boilerplate and scaffolding go with Level 3 (light). Only security, sensitive data, and critical business logic need Level 1. Most of your code falls into Level 2-3.

Problem 2: "I don't know when it's Level 1 vs Level 2"

Cause: Uncertainty about the real risk of a task.

Solution: When in doubt, go one level up. Level 2 if you were doubting between 2 and 3. Level 1 if you were doubting between 1 and 2. It's better to over-verify a little than to under-verify. Over time, your calibration improves naturally.

Problem 3: "My team doesn't have verification standards"

Cause: Individual trust calibration without a team context.

Solution: Share your checklist with the team. Propose that they adapt it as a standard. Having a shared framework eliminates the ambiguity of "how much do I verify this?" — the answer is in the matrix, not in individual opinion.

Exercises

Exercise 1: Classify into verification levels (Easy)

For each task, indicate which verification level you'd use (1, 2, or 3):

1. AI generates a README.md file for your project
2. AI implements the password reset function
3. AI renames a variable in 15 files
4. AI creates a CI/CD pipeline
5. AI implements contact form validation
6. AI writes a migration that adds a nullable column

Exercise 2: Identify the circuit breaker moment (Medium)

Read this scenario and answer: at what moment should you have activated the circuit breaker?

"I asked the agent to fix a bug in the discount calculation. The agent modified the function, but the tests failed. I asked it to fix the tests. It fixed them, but now the discount works differently. I asked it to adjust it. It adjusted it, but it also modified the pricing function I didn't ask it to touch. The tests are still failing. I'm 4 iterations in."

Exercise 3: Create your customized checklist (Medium)

Based on this capsule's template, create your own trust calibration checklist adapted to your technology stack and type of work. Include at least:

• 3 warning signs specific to your context
• Level 1 criteria adapted to your stack
• At least one everyday task for each level

Exercise 4: The cost of not verifying (Hard)

Think of a real or hypothetical scenario where NOT verifying AI code could have serious consequences. Describe: (1) the task, (2) what AI would generate, (3) the error you might not detect, (4) the consequence in production.

@app.put("/users/me/email")
async def change_email(new_email: str, current_user: User = Depends(get_current_user)):
    current_user.email = new_email
    db.commit()
    return {"message": "Email updated"}

Summary

In this capsule you learned:

• AI amplifies patterns — good and bad. If your code review is rigorous, AI produces more good code. If it isn't, it produces more bad code
• You are the circuit breaker — the mechanism that prevents AI errors from reaching production
• Circuit breaker signs: you don't understand the code, 3+ iterations without progress, the agent touches files you didn't ask for, tests the agent "fixes" by modifying expectations
• Trust calibration has 3 levels: complete (security, data), focused (features, refactoring), light (boilerplate, formatting)
• The risk × familiarity matrix tells you which level to use for each task
• Your customized checklist is the most important practical artifact of this module
• The cost of not verifying can be disastrous in security, sensitive data, and financial logic tasks

What you created:

• ✅ Your customized trust calibration checklist

Next capsule: 05 - When to delegate and when to do it yourself — the decision framework for classifying tasks and the cost of "almost right."

Additional Resources

1. Veracode State of Software Security 2025 — 45% of AI code with security flaws: why trust calibration is necessary
2. OWASP Top 10 for LLM Applications — Security risks specific to applications with LLMs
3. Anthropic: Claude Code Permissions — How the Claude Code permission system implements circuit breaking
4. Agentic Coding — Verification — Verification framework for coding agent output
5. METR Transcript Analysis — Real examples of when developers should have intervened and didn't
6. Google DORA 2025: Code Review Practices — Code review best practices that apply to AI-generated code