Module 1: Only 3% Trust It — Why, and What to Do

Two Dangerous Extremes

Capsule overview

When a developer starts using AI coding tools, they tend to fall into one of two extremes: accepting everything it generates ("it works, ship it") or rejecting AI entirely ("I don't trust code I didn't write"). Both extremes seem reasonable. Both are professionally dangerous. In this capsule you're going to understand why, with concrete examples of how each extreme affects your work.

The point isn't to judge — it's to recognize. If you identify with one of the extremes, it's not a flaw. It's a natural pattern almost everyone experiences. What matters is that you recognize it and move toward the middle ground: calibrated trust.

Extreme 1: Accept Everything

The pattern

Developer asks → AI generates → "Looks good" → Accepts → Commit → Push

No significant review.
No logic verification.
No security check.

Why it's tempting

Speed. Reviewing takes time. Accepting is instant.
Trust in the tool. "Claude Code is from Anthropic, it must know what it's doing."
Confirmation bias. The code looks good, it works on the happy path, and you don't want to go looking for problems.
Time pressure. Real deadlines make "it works" enough.
The first-impression effect. Well-formatted code with good variable names looks correct. AI is very good at generating code that looks professional.

The concrete danger

Let's look at a real example of what can happen:

# Claude Code generated this login endpoint
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import jwt
import hashlib

app = FastAPI()

SECRET_KEY = "my-super-secret-key-2024"

class LoginRequest(BaseModel):
    email: str
    password: str

@app.post("/login")
async def login(request: LoginRequest):
    user = get_user_by_email(request.email)
    if not user:
        raise HTTPException(status_code=401, detail="Invalid credentials")
    
    password_hash = hashlib.md5(request.password.encode()).hexdigest()
    if password_hash != user.password_hash:
        raise HTTPException(status_code=401, detail="Invalid credentials")
    
    token = jwt.encode(
        {"user_id": user.id, "email": user.email},
        SECRET_KEY,
        algorithm="HS256"
    )
    
    return {"access_token": token, "token_type": "bearer"}

At first glance it looks professional. FastAPI, Pydantic, JWT. But it has 4 serious problems:

Problem 1: SECRET_KEY hardcoded in the code
→ Anyone who sees the repo has your secret
→ Consequence: they can forge valid JWT tokens

Problem 2: MD5 for password hashing
→ MD5 is insecure for passwords (rainbow tables)
→ It should use bcrypt or argon2
→ Consequence: passwords crackable in minutes

Problem 3: Token with no expiration
→ The JWT has no "exp" field
→ A stolen token is valid forever
→ Consequence: permanent account compromise

Problem 4: Doesn't validate email format
→ Accepts "not-an-email" as a valid email
→ Consequence: inconsistent data in the database

A developer who accepts this code without review has just introduced 4 security vulnerabilities. And the code works perfectly on the happy path — a correct login returns a token, an incorrect login returns 401.

Symptoms that you're at this extreme

✅ You accept Claude Code output if it has no syntax errors
✅ Your main criterion is "does it work?" not "is it correct?"
✅ You don't remember the last time you rejected an AI suggestion
✅ You've never found a bug in AI-generated code (you probably don't look for them)
✅ Your acceptance speed is < 30 seconds for any amount of code

Extreme 2: Reject Everything

The pattern

Developer asks → AI generates → "I don't trust it" → Rewrites all of it → Commit → Push

Uses AI as brainstorming but rewrites every line.
Or simply doesn't use AI out of distrust.

Why it's tempting

Control. If you write it, you understand all of it.
Prior experiences. Once AI generated something incorrect and now you don't trust it.
Professional pride. "A good developer writes their own code."
Perfectionism. The AI code isn't exactly how you'd do it.
Fear of the unknown. You don't understand how it generates the code, so you don't trust it.

The concrete danger

Let's look at the real cost:

Scenario: Build a CRUD API with 5 endpoints

Without AI:
- Write models: 45 min
- Write endpoints: 1.5 hrs
- Write validations: 1 hr
- Manual testing: 30 min
- Total: ~3.5 hrs

With AI (accepting everything without review):
- Prompt + accept: 15 min
- Total: 15 min (but with 4 bugs)

With AI (calibrated trust):
- Prompt: 5 min
- Review business logic: 20 min
- Verify security: 15 min
- Adjust 2 issues found: 10 min
- Total: 50 min (no significant bugs)

With AI (rejecting everything):
- Prompt: 5 min
- Read output, discard it: 10 min
- Rewrite everything manually: 3 hrs
- Total: 3.25 hrs (same result as without AI)

The developer who rejects everything spends almost the same as without AI. They have the tool but don't use it.

The hidden cost

It's not just time. It's opportunity:

Developer A (calibrated trust):
- Generates CRUD with AI: 50 min
- Uses the remaining time to:
  - Improve the architecture
  - Write more complete tests
  - Document edge cases
  - Implement an additional feature
  
Developer B (rejects everything):
- Rewrites CRUD manually: 3.5 hrs
- Has no time left for:
  - Architecture improvements
  - Exhaustive tests
  - Documentation
  - Additional features

The developer who rejects AI doesn't just lose speed — they lose the opportunity to invest time in higher-value work.

Symptoms that you're at this extreme

✅ You use AI to generate code but rewrite most of it
✅ You struggle to accept code you didn't write, from any source
✅ Your main argument is "I'd do it differently"
✅ You spend more time modifying AI output than using it
✅ You feel that using AI is "cheating" or is for "juniors"

Comparison: The Two Extremes vs The Middle Ground

Criterion	Accept Everything	Reject Everything	Calibrated Trust
Speed	Maximum	Minimum	High
Quality	Unpredictable	Consistent (your level)	Consistent (your level + AI)
Risk	High (hidden bugs)	Low	Low
Productivity	High apparent, low real	Low	High real
Learning	Low (you don't review)	Medium	High (you review and learn)
Sustainability	No (problems accumulate)	No (burnout from the pace)	Yes
Security	Dangerous	Depends on you	Verified

The "speed" trap

The accept-everything extreme looks more productive. But real productivity includes the cost of bugs, fixes, and refactors:

Real productivity = 
  (Speed of generation) 
  - (Time debugging hidden bugs)
  - (Time refactoring)
  - (Impact of security issues)
  - (Accumulated technical debt)

When you include these costs, the accept-everything extreme is frequently LESS productive than the middle ground.

How They Show Up Day to Day

Scenario 1: Urgent feature request

Accept everything: "Claude Code, generate the endpoint. Done, it works, PR created." Reject everything: "Let me think it through and write it myself. It takes me 3 hours but I do it right." Calibrated: "Claude Code, generate the endpoint. I review auth and business logic — good. The validations are incomplete, I adjust them. PR created in 45 min."

Scenario 2: Bug in production

Accept everything: "Claude Code, fix this bug." → Accepts the fix without verifying → Can create a new bug. Reject everything: Investigates manually for 2 hours. Debugs without AI. Finds the bug but takes a long time. Calibrated: "Claude Code, analyze this stack trace." → Reads the explanation, verifies the hypothesis → Implements a verified fix.

Scenario 3: Module refactoring

Accept everything: "Claude Code, refactor this module." → Accepts 200 new lines without review. Reject everything: Refactors manually line by line. 4 hours. Calibrated: "Claude Code, refactor this module." → Checks that the public API didn't change, that the tests pass, that the core logic is correct. Adjusts 3 details. 1.5 hours.

The Real Spectrum

The extremes are the poles of a spectrum:

Accept Everything ←————————————————————→ Reject Everything
     |         |         |         |
     0%       25%       50%       75%      100%
   review    review    review    review    review

   ←— Danger           Optimal          Danger —→
                      (varies by
                    type of task)

The optimal point isn't fixed — it varies by type of task:

Boilerplate:     10-20% review (trust more)
CRUD:            30-40% review
Business Logic:  60-80% review
Auth/Security:   80-100% review (trust less)

Troubleshooting

Problem 1: "I identify with accept everything and I don't know how to change"

Cause: A habit of speed over quality. Solution: Start with a simple rule: before accepting, ask yourself 3 questions: (1) Does it have business logic? Review it. (2) Does it touch security? Review it exhaustively. (3) Is it boilerplate? OK, accept it. Gradually add more questions.

Problem 2: "I identify with reject everything and I feel slow"

Cause: Fear of losing control or a previous negative experience. Solution: Try it with low-risk tasks. Generate a README.md or a setup script with Claude Code. Review it quickly. If it's good, accept it. Build trust gradually, starting with the lowest-risk items.

Problem 3: "I swing between both extremes depending on the day"

Cause: Lack of a framework — your decision depends on your mood, not on criteria. Solution: That's normal. The framework you'll build in capsule 05 removes the variability. You'll have clear criteria that don't depend on how you feel that day.

Exercises

Exercise 1: Identify the extreme (Easy)

For each scenario, identify whether the developer is at the "accept everything" or "reject everything" extreme:

Scenario A: María asks Claude Code to generate tests for her API. She receives 15 test cases. She runs them, all pass, and she commits.

Scenario B: Carlos asks Claude Code to generate an email validation helper. He receives a 20-line function. He deletes it and writes his own 18-line version that does exactly the same thing.

Scenario C: Ana asks Claude Code to generate a Dockerfile. She reads it quickly, sees that it uses the correct image and standard commands, and accepts it.

See solution

A: Accept everything. The tests passing doesn't mean they test the right thing. AI-generated tests can have trivial assertions or fail to cover edge cases. María should verify that the tests validate the correct logic, not just that they run without error.

B: Reject everything. Carlos spent time rewriting something that was practically identical. If the output was correct, he should have accepted it (perhaps with minor adjustments).

C: Calibrated trust. Ana reviewed what was relevant (image, commands) for a low-risk type of task (Dockerfile) and accepted it. This is correct calibration — review proportional to the risk.

Exercise 2: Calculate the real cost (Medium)

A team of 5 developers uses Claude Code. Each developer generates AI code an average of 8 times a day. Calculate the weekly cost in each scenario:

Accept everything: 2 min per acceptance, but 1 in 10 introduces a bug that takes 45 min to fix
Reject everything: 30 min average rewriting each output
Calibrated: 10 min average of review, 1 in 25 introduces a bug that takes 30 min to fix

See solution

Per developer, per day (8 generations):

Accept everything:

Acceptance time: 8 × 2 min = 16 min
Bugs: 8/10 × 0.8 bugs/day × 45 min = 36 min of debugging
Daily total: 52 min
Weekly (×5 days): 260 min = 4.3 hrs

Reject everything:

Time rewriting: 8 × 30 min = 240 min
Daily total: 240 min
Weekly: 1200 min = 20 hrs (half of the work week!)

Calibrated:

Review time: 8 × 10 min = 80 min
Bugs: 8/25 × 0.32 bugs/day × 30 min = 9.6 min of debugging
Daily total: ~90 min
Weekly: 450 min = 7.5 hrs

For the team of 5 (weekly):

Accept everything: 21.5 hrs (but with accumulated bugs)
Reject everything: 100 hrs (12.5 work days!)
Calibrated: 37.5 hrs

Conclusion: Calibrated is 2.7x more efficient than rejecting everything, and 1.7x more than accepting everything — not counting the long-term cost of bugs in production.

Exercise 3: Your transition plan (Medium)

If you identify with one of the extremes, write a 3-step plan to move toward the center. Be specific — not "review more" but "before accepting auth code, verify that tokens expire."

See solution

If you're coming from "accept everything":

This week: before accepting any code, verify there are no hardcoded secrets (search for strings like "sk-", "password", API keys)
Next week: in addition to point 1, for any endpoint, verify that it has error handling (try/except or HTTPException)
Week 3: in addition to 1 and 2, for business logic, read the entire implementation and verify against the requirements

If you're coming from "reject everything":

This week: accept without modification all code that is boilerplate (project setup, imports, configuration)
Next week: in addition to point 1, accept CRUD endpoints if the structure is correct, only modify specific logic
Week 3: for each output, identify what percentage is fine before deciding to rewrite. If >70% is fine, edit instead of rewriting

The key: Gradual change, not revolution. Move the dial 10-20% per week.

Exercise 4: Internal debate (Hard)

A senior developer says: "The only safe way to use AI code is to review all of it line by line. If you don't review all of it, it's professional negligence." Do you agree? Argue against it with data from this capsule.

See solution

Counterargument:

Reviewing everything is economically unviable. If a developer reviews every line of the 8 daily AI generations, they spend ~4 hours/day on review alone. That eliminates the productivity benefit of AI tools.
Not every line carries the same risk. Reviewing import os line by line is a waste. Reviewing token = jwt.encode(...) is essential. Review should be proportional to the risk, not uniform.
The concept of "negligence" assumes uniform risk. A doctor doesn't do an MRI for a cold. A developer shouldn't do an exhaustive code review for boilerplate. Negligence is in not reviewing what matters, not in trusting what's routine.
The data shows that calibration is more effective. The calibrated team (exercise 2) spends 37.5 hrs/week vs 100+ hrs if they review everything, with comparable quality. Efficiency isn't negligence.

Note: The senior is right about ONE thing — for high-risk code (auth, security, business logic), exhaustive review is essential. But generalizing that to all code is impractical.

Summary

In this capsule you learned:

Extreme 1 (Accept everything) is dangerous: apparent speed that hides bugs, security holes, and technical debt
Extreme 2 (Reject everything) is costly: you lose productivity and opportunity without gaining significant quality
The two extremes are natural reactions — not flaws. What matters is recognizing where you are
The optimal middle ground varies by type of task: more trust for boilerplate, less for auth/security
Real productivity includes the cost of bugs and refactors — accepting everything looks fast but isn't
The change should be gradual: move the dial 10-20% per week, not 100% at once

Next capsule: Calibrated Trust — the professional framework for the middle ground.

Additional resources

ACM Queue — The Cost of Code Review - Research on the costs and benefits of code review
Microsoft Research — Developer Productivity with AI - Studies on productivity with AI coding tools
Google — Code Review Best Practices - Google's code review practices, adaptable to AI code
Anthropic — Claude Code Best Practices - Official recommendations for verifying output
The Pragmatic Programmer - Chapter on tools and automation with judgment

Debugging & Code Review with Claude Code — Module 1, Capsule 03 Claude Code Agentic Development Path — Guide #6 of 11

← PreviousThe 3% Statistic Next →Calibrated Trust