DOKKAEBILABS
WhatsApp us
← All posts

Dokkaebi Labs · April 8, 2026 · 8 min read

When NOT to Use AI for Your Code (The Hard Limits)

AI coding assistants are powerful. They're also confidently wrong in ways that can break your app, leak your data, or waste your time. Here's when to use them — and when to absolutely not.

aiprogrammingproductivityclaudechatgpt

The Dangerous Assumption

AI coding assistants (Claude, ChatGPT, Copilot) are genuinely good at some things: boilerplate, documentation, refactoring, tests.

But there's this idea floating around: "AI can do anything. You just need to ask right."

That's wrong.

AI is confidently wrong in ways that slip past you. It generates code that compiles, runs, looks reasonable—but has logic bugs, security holes, or architectural problems that you won't notice until they're in production. This is about where AI actually fails you.

Where AI Coding Assistants Excel

Let's start with what they're actually good at:

  • Boilerplate code (CRUD operations, API endpoints, config files)
  • Documentation and comments (explaining code you've written)
  • Unit tests (given working code, generate tests for it)
  • Refactoring for readability (rewrite code more clearly)
  • Explaining unfamiliar code (what does this do?)
  • Converting between languages/frameworks (rewrite this Python in JavaScript)
  • Regex patterns (generate a regex that matches X)
  • Quick syntax lookups (how do you do X in library Y?)

Pattern: Repetitive, well-documented, low-stakes work. Code where "good enough" is actually good enough.

Where AI Will Confidently Fail You

1. Architecture Decisions

AI doesn't know your system. It doesn't know:

  • How many users you actually have (100? 1 million?)
  • Your real constraints (money, team size, timeline)
  • What patterns you already use
  • What actually matters to your business

So it generates plausible-sounding architectures that don't fit you.

Example: You ask, "How do I build real-time notifications?" AI says: WebSockets + microservices + Redis + Kubernetes. You're a 2-person team building an MVP. You needed: polling + one server + SQLite. AI over-engineered it by 10x.

Real cost: 3 weeks building infrastructure you don't need. Your actual product ships late.

Rule: Don't let AI make structural decisions about your code.

2. Security-Critical Code

This is the dangerous one.

AI is trained on publicly available code. Most public code has security issues. AI regularly generates code with:

  • SQL injection vulnerabilities (concatenating user input into queries)
  • XSS vulnerabilities (rendering user input as HTML without escaping)
  • Authentication bypasses (weak password validation, missing checks)
  • Hardcoded secrets (API keys in code instead of environment variables)
  • Insecure defaults (storing passwords in plaintext, using weak hashing)
  • Path traversal (allowing users to read arbitrary files)

AI doesn't think like an attacker. It generates "working" code, not "secure" code.

Example: You ask, "Generate a login endpoint." AI produces:

@app.route('/login', methods=['POST'])
def login():
    username = request.form['username']
    password = request.form['password']
    user = User.query.filter_by(username=username).first()
    if user and user.password == password:  # ← plaintext comparison, no hashing
        session['user_id'] = user.id
        return "Login successful"
    return "Invalid credentials"

Looks reasonable. Doesn't work. It's storing passwords in plaintext and comparing them directly. This will get your company sued.

Real cost: Data breach. Legal liability. Trust destroyed.

Rule: Never use AI-generated code for authentication, authorization, cryptography, or data handling without expert review. Have a senior engineer check it. Assume it's wrong until proven otherwise.

3. Code You Don't Understand

The most dangerous pattern: copying AI code without understanding it.

You'll ship bugs you can't debug. You'll build on foundations you can't maintain. When it breaks (and it will), you won't know where to start.

Example: AI generates a complex state management solution. You copy it. Weeks later, your app starts losing data under load. You don't understand the code well enough to debug it. You spend days in the weeds while your users are angry.

Real cost: Downtime, bugs you can't fix, technical debt you inherit.

Rule: If you can't explain every line to a junior developer, don't ship it. If it's complex, understand it. If you can't understand it in a reasonable time, rewrite it simpler.

4. Novel Problems

AI is trained on existing code. It pattern-matches.

If your problem has been solved publicly before, AI can remix that solution. But if your problem is genuinely novel—something nobody's solved the way you need to solve it—AI will hallucinate.

It will look correct. It will compile. It will be wrong.

Example: You're building a novel real-time collaboration system (like Google Docs but for your industry). You ask AI, "How do I implement operational transformation for collaborative editing?"

AI generates code. It looks right. It handles concurrent edits. You ship it.

Then you hit edge cases: conflict resolution under fast, concurrent edits. Undo/redo with multiple editors. The AI solution fails silently, corrupting document state.

Real cost: Weeks debugging. Users losing work. Credibility damage.

Rule: For genuinely novel problems, AI is a brainstorming partner, not a solution provider. Use it to explore ideas, but you need to think through the hard parts yourself.

5. Performance-Critical Code

AI optimizes for readability and correctness, not performance.

It doesn't know:

  • Your data volumes (are you handling 100 rows or 100 million?)
  • Your latency requirements (sub-100ms? sub-1s? who cares?)
  • Your bottlenecks (what's actually slow?)

So it generates code that's correct but slow.

Example: You ask, "How do I find all users with a specific tag?"

AI generates:

users_with_tag = [user for user in all_users if tag in user.tags]

It's O(n). You have 1 million users. This is slow.

The efficient solution is an index. But AI didn't know you needed one. Or should consider a database query instead of loading everything into memory.

Real cost: Your page loads in 30 seconds instead of 500ms. Users leave.

Rule: Profile first. Optimize manually. Use AI only for implementation details after you've identified the bottleneck.

Real Examples of AI-Generated Bugs

Example 1: The "Working" Code That Leaked Data

Scenario: You ask AI to generate an API endpoint that returns user data.

@app.route('/users/<user_id>', methods=['GET'])
def get_user(user_id):
    user = User.query.get(user_id)
    return jsonify(user.to_dict())

It works! You can fetch user data. It compiles. Tests pass.

But there's no authorization check. Any authenticated user can fetch any other user's data. Admin passwords? Credit card numbers? All exposed.

AI didn't include the authorization logic because it wasn't explicit in the prompt. The code is "working"—it's just insecure.

Example 2: The Hallucinated Library

Scenario: You're working with Python. You ask AI, "What's the best library for X?"

AI recommends: from fancylib import do_thing

You try: pip install fancylib

It doesn't exist. AI hallucinated it based on naming patterns.

You spend an hour trying to install something that was never real.

Example 3: The Subtle Logic Error

Scenario: You ask AI to generate date comparison logic.

if user.created_date > cutoff_date:
    send_notification(user)

Looks correct. Tests pass with standard dates.

Then it fails on edge cases:

  • Timezones (users in different TZ compare wrong)
  • Daylight saving time (dates shift)
  • Leap seconds (systems handle them differently)

The bug isn't caught until production, 3 months later, during specific conditions.

The Right Mental Model for AI Coding

Think of AI as a very fast, very confident junior developer.

They can write code quickly. They don't always understand why. They're good at generating options, bad at making judgment calls.

You wouldn't let a junior deploy to production without review. Same applies to AI.

Your job: Architect, review, verify, decide.

AI's job: Draft, iterate, explain.

When to Use AI (Decision Framework)

TaskUse AI?Why
Boilerplate/CRUD✅ YesLow-risk, repetitive, AI does this well
Documentation✅ YesAI explains code clearly
Unit tests✅ YesCoverage boost, low risk
Refactoring✅ With reviewCheck for behavioral changes
Comments/docstrings✅ YesTime-saving, low stakes
Auth/security❌ NoToo high-risk, assume it's wrong
Architecture❌ NoAI lacks context about your constraints
Novel algorithms⚠️ Brainstorm onlyWill hallucinate without guidance
Production debugging⚠️ CarefullyCan mislead, needs verification
Code you don't understand❌ NoYou'll maintain it badly

The Skill That Still Matters

Here's the hard truth: AI makes it easier to write code.

It doesn't make it easier to understand systems. Doesn't teach you how to think about problems deeply.

The developers who thrive in the AI era will be those who:

  • Understand fundamentals deeply
  • Know when AI is useful (and when it's dangerous)
  • Can review, debug, and fix AI-generated code
  • Think critically about architecture and security

AI amplifies your abilities. But you need abilities to amplify.

A junior who can't architect, debug, or review AI code is more dangerous with AI than without it. They'll ship insecure code and break things confidently.

A senior who uses AI for boilerplate and rote work? They'll ship faster and better.

CTA

Learning to code in the AI era means learning when to use AI and when to think for yourself. Our programming tutoring focuses on building real understanding—not just prompting skills.

We teach you to understand what's happening. To review code critically. To know when something is wrong, even if it compiles.

Learn more →

Have questions or want to discuss this further? Reach out on WhatsApp or email.

Get in touch →