When Not to Use AI — AI-Assisted Coding, Part 9
Updated: 2 days ago
AI-Assisted Coding · Part 9
AI accelerates a lot of coding — and there's a specific list of places it should never touch, where its confidence runs highest and its judgment is worst. Security-critical code, novel architecture, business logic that lives in people's heads rather than the spec, concurrency: these are exactly where a fluent wrong answer costs the most. This walks through knowing when to close the AI and write it yourself — and why "the AI sounded very sure" is itself a warning sign, not a reassurance.
AI accelerates many things. Some it should not touch. Knowing the line.
Step 1: Security-Critical Code (15 min)
Don't trust AI for:
Auth flows
Cryptography
Permission checks
Input validation for security
Anything generating credentials / tokens
AI happily writes:
hash = md5(password) # broken crypto
Read security guidance from humans. Write security-critical code yourself; pair-review.
Step 2: Novel Architecture (10 min)
AI is great at "match a pattern." Less great at:
Designing entirely new systems
Trade-off decisions specific to your business
Choosing between two unfamiliar approaches
Talk to humans. Use AI for parts; not the whole design.
Step 3: Business Logic With Unwritten Rules (10 min)
"Calculate the discount for premium members."
AI generates a plausible-looking calculation. Is it right? Depends on rules that exist only in product manager's head.
Don't AI-generate code where:
Acceptance criteria aren't fully written
The "spec" is a vague PM message
Edge cases require business judgment
Clarify first; then implement.
Step 4: Code You Don't Understand (10 min)
If AI generates:
# Some clever optimization
And you can't explain why it works:
Don't ship it
Study it
Or pick a simpler version
You'll maintain this. Future-you needs to understand.
Step 5: Legal / Compliance Sensitive (10 min)
GDPR, HIPAA, PCI-DSS code:
Get specific requirements from legal
Implement deliberately
Audit by humans
Don't shortcut with AI patterns
The cost of getting compliance wrong: massive fines + reputation.
Worth slower.
Step 6: Production Hot Paths (10 min)
Code that runs millions of times:
Performance matters
Bugs amplify
Side effects spread
Read carefully. AI doesn't profile. AI doesn't know your latency budget.
Pair-review hot path changes specifically.
Step 7: Concurrency-Heavy Code (10 min)
Races, deadlocks, atomicity:
AI suggests "looks right" code that subtly races
Human review with concurrency expertise needed
Use deterministic concurrency tools (Go race detector, ThreadSanitizer)
For multithreaded / async code: think carefully; AI is one input.
Step 8: When You're Learning (10 min)
Junior engineers especially:
Resist using AI for everything
Write from scratch sometimes
Learn the fundamentals
If AI does it all: you don't grow.
Use AI like a senior pair — they explain; you understand; you write.
Step 9: When AI Confidence Is Suspicious (10 min)
AI says: "Definitely use X."
If X is:
Old advice (out of date)
A confident-sounding but rare library
An approach that doesn't fit your codebase
Push back. Ask "are you sure?" — sometimes AI revises.
Confidence != correctness.
Step 10: When Your Org Forbids It (10 min)
Some orgs:
Don't allow AI assistants on the codebase (IP)
Restrict to specific tools (compliance)
Require human authorship for certain code (legal)
Respect those rules. Even if individually you'd benefit, the org's posture matters.
What You Just Did
When not to AI: security, novel arch, vague business logic, code you don't understand, compliance, hot paths, concurrency, learning, suspect confidence, org rules. Knowing the line.
Common Failure Modes
AI generates security code; you ship. Vulnerability.
AI generates concurrency code; you ship. Race in production.
AI handles entire feature; you don't understand it. Can't maintain.
Use AI for novel architecture. Pattern-match doesn't apply.
Org said no; you used anyway. IP risk.
Continue the AI-Assisted Coding path
Previous — Part 7: Use AI for Debugging
Part of the AI-Assisted Coding learning path.
