DEV Community: Junkyu Jeon

Why AI Coding Goes Off the Rails — And How to Take Back Control

Junkyu Jeon — Thu, 16 Apr 2026 06:44:54 +0000

The Honeymoon Phase

You remember the moment. You opened Cursor, or Bolt, or Claude for the first time, typed something like "Build me a landing page with a hero section and a pricing table," and watched as fully functional code materialized in front of you. In minutes, not hours.

You kept going. "Add a contact form." Done. "Make it responsive." Done. "Add dark mode." Done. You felt like a 10x developer. The possibilities felt limitless. You started telling friends about it. You stayed up late building things you'd been putting off for months.

This phase is real. It's not a trick. AI coding tools genuinely are that powerful for getting something off the ground. The problem is what happens next.

When Things Start Breaking

It's subtle at first. Around the time your project hits 20-30 files, something shifts. The AI that was nailing everything starts... stumbling.

You notice it in small ways:

It forgets decisions it made earlier. You established a pattern for how components fetch data, but the AI starts using a completely different approach in new files.
It contradicts its own patterns. Half your files use one error-handling style, the other half use another. Neither is wrong, but the inconsistency makes everything harder to follow.
It breaks existing features while adding new ones. You ask for a new settings page and suddenly your authentication stops working.
Its fixes create new problems. You point out a bug, it patches it, and now something else is broken. You fix that, and the original bug comes back.
It goes in circles. Fix this, breaks that. Fix that, breaks this. You spend an hour and end up back where you started, except now the code is messier.

If this sounds familiar, you're not alone. This is the experience of almost every developer who uses AI tools on a project beyond a certain size. And it's not because the AI got dumber or because you're doing something wrong.

Why This Happens: The Context Problem

Here's the thing most people don't understand about AI coding tools: they have a limited working memory.

AI models operate within something called a context window — the amount of text they can "see" and think about at any given time. Think of it like a desk. When your project is small, all your files fit on the desk. The AI can see everything at once — every component, every function, every decision you've made together.

But as your project grows, files start falling off the desk. The AI can only look at a slice of your codebase at a time. It literally cannot see what's in the other files. It doesn't know what patterns were established. It doesn't remember what constraints exist. It doesn't recall the naming conventions you agreed on three sessions ago.

It's like asking someone to renovate your house, but they can only see one room at a time. They might pick a great paint color for the kitchen — that clashes horribly with the living room they can't see.

And here's the part that really stings: each conversation starts fresh. When you open a new chat or start a new session, the AI has zero memory of your previous interactions. It doesn't know about the bug you spent two hours fixing yesterday. It doesn't know about the architectural decision you made last week. Every time, it's meeting your project for the first time.

This isn't a flaw that'll be fixed in the next update. It's a fundamental characteristic of how these models work. And once you understand it, the frustrating behavior makes perfect sense.

The Snowball Effect

Here's where it gets really painful. When things break, the natural instinct is to tell the AI: "Fix it." And the AI obliges — it patches the immediate symptom. But because it can't see the full picture, it's not fixing the root cause. It's applying a band-aid.

Each band-aid adds complexity. And that complexity makes it even harder for the AI to understand the codebase on the next request. So the next fix is even more likely to be a band-aid. And the cycle continues:

Something breaks
AI patches the symptom
The patch adds complexity
The added complexity causes something else to break
Go to step 1

Your codebase becomes a patchwork of contradictory patterns, redundant logic, and fragile workarounds. Eventually the AI is spending more tokens trying to understand the mess than actually solving the problem you asked about.

This is why vibe coding hits a wall. Not because AI is bad at coding. Not because you're not technical enough. But because the approach of "just keep prompting" doesn't scale. The more you build, the less effective each prompt becomes, until you're fighting the tool instead of building with it.

The Shift: From Prompting to Harness Engineering

When people hit this wall, their first instinct is to write better prompts. More detailed instructions. Longer explanations. "Be very careful not to break the auth system when you add this feature."

This helps a little. But it's treating the symptom, not the disease. You can't prompt your way out of a structural problem.

The real unlock is something we call harness engineering — designing the environment and structure that the AI works within.

Think about it this way:

Prompt engineering is telling the AI what to do.
Harness engineering is setting up where and how the AI works.

A "harness" is everything that surrounds the AI: the project structure, the rules it follows, the context it receives, the guardrails that catch its mistakes. It's the difference between dropping a builder in an empty field and saying "build a house," versus handing them blueprints, a materials list, and a building code.

When you invest in the harness, the AI performs dramatically better — even with the exact same prompts you were using before. Because the environment compensates for the AI's limitations.

Here's what harness engineering looks like in practice:

CLAUDE.md / .cursorrules files that give the AI persistent context about your project — your tech stack, your conventions, your constraints. Things the AI would otherwise forget between sessions.
Clean folder structure so the AI only needs to see the relevant files for any given task, keeping more of the important context on that "desk."
Module boundaries that limit the blast radius of AI changes. If the AI makes a mistake in the settings module, it shouldn't be able to break authentication.
Test suites that catch when the AI breaks something, before you even notice.
Memory systems that preserve decisions across sessions — so the AI doesn't have to rediscover your architecture every time.

None of these require you to be a senior engineer. They require you to think like an architect, not a prompter.

Practical Steps to Take Back Control

You don't need to rebuild everything from scratch. Here are concrete things you can do today to improve how AI works with your project:

1. Set Up a CLAUDE.md or .cursorrules

This is the single highest-leverage thing you can do. Create a file that tells the AI everything it keeps forgetting: your tech stack, your folder structure, your naming conventions, your patterns, your constraints. The AI reads this at the start of every session, giving it the context it would otherwise lack.

We wrote a full guide on how to do this well: How to Make AI Tools Understand Your Codebase.

2. Break Your Project Into Modules

Smaller, self-contained pieces mean less context needed per task. When your auth logic is in its own module with clear boundaries, the AI can work on it without needing to understand your entire app. Feature-based folder structure is a great starting point — see our guide on how to structure your AI project.

3. Give AI One Job at a Time

Instead of "Build the auth system with social login, password reset, 2FA, and admin panel," try:

"Add a basic email/password login page"
"Add password reset functionality"
"Add Google OAuth login"

Each focused request is more likely to succeed because it requires less context and produces smaller, more reviewable changes.

4. Add Tests Before Adding Features

Tests are your safety net. When the AI changes something, tests tell you immediately if it broke something else. You don't need 100% coverage. Even basic tests for your critical paths — login works, data saves correctly, pages load — will catch the most damaging regressions.

5. Review Before Accepting

This is the hardest habit to build. AI-generated code comes out fast and looks professional, so it's tempting to accept it without reading. Don't. Spend 30 seconds scanning each change:

Does it follow your existing patterns?
Did it change files it shouldn't have touched?
Does the logic actually make sense, or does it just look right?

You don't need to understand every line. But you should understand the shape of the change.

6. Version Control Religiously

Commit every working state. Every one. When the AI inevitably breaks something, you can roll back to the last good version instead of trying to untangle the damage. git commit is your undo button. Use it early and often.

The Mindset Shift

Here's the most important thing to internalize: you're not a prompter. You're an architect.

The AI is the builder. It's fast, it's capable, and it works tirelessly. But builders need blueprints. They need someone who understands the whole structure, who can see across all the rooms at once, who makes sure the kitchen paint works with the living room.

That's you.

The best AI-assisted developers don't write the most code. They don't write the fanciest prompts. They design the best structures for AI to work within. They set up the harness so well that the AI almost can't fail.

And that's a skill worth developing — because as AI tools get better, the people who know how to direct them effectively will build things the rest of the world didn't think were possible.

If your project has already gone off the rails and you're not sure how to get it back on track, we can help. We specialize in taking AI-built codebases and giving them the structure they need to keep growing.

And if you want to prevent this from happening on your next project, start with our guide on how to structure your AI project from day one.

Originally published at bivecode.com

Cursor Rules vs CLAUDE.md: When to Use Which (And How They Work Together)

Junkyu Jeon — Thu, 16 Apr 2026 06:39:12 +0000

If you're using AI coding tools seriously, you've probably heard of both .cursorrules and CLAUDE.md. They solve the same fundamental problem: giving AI persistent context about your project.

Without them, every AI session starts from scratch. The AI doesn't know your tech stack, your folder conventions, your naming patterns, or the quirks that make your project unique. You end up repeating the same instructions over and over.

Both files fix this. But they work differently, they're read by different tools, and they have different strengths. Most developers pick one and ignore the other. That's a mistake — they're most powerful when used together.

What .cursorrules Does

.cursorrules is Cursor's project-level configuration file. When you open a project in Cursor, it automatically reads this file and applies the rules to every AI interaction within that project.

Key characteristics:

Tool-specific — only Cursor reads it. Other AI tools ignore it completely.
Instruction-focused — best for telling the AI what to do and what not to do.
Applies to all interactions — every chat, every inline edit, every Cmd+K generation follows these rules.
Supports glob patterns — you can scope rules to specific file types or directories.

A typical .cursorrules:

You are an expert in TypeScript, React, Next.js App Router, and Tailwind CSS.

Key Principles:
- Write concise, technical TypeScript code
- Use functional and declarative programming patterns
- Prefer iteration and modularization over duplication
- Use descriptive variable names with auxiliary verbs (isLoading, hasError)

Naming Conventions:
- Components: PascalCase (UserProfile.tsx)
- Hooks: camelCase with "use" prefix (useAuth.ts)
- Utilities: camelCase (formatDate.ts)
- Constants: SCREAMING_SNAKE_CASE

DO NOT:
- Use `any` type
- Use default exports (except for pages)
- Put business logic in components
- Use inline styles

What CLAUDE.md Does

CLAUDE.md is Claude's project context file. Claude Code, Claude in the terminal, and other Claude-powered tools read it automatically when they enter your project directory.

Key characteristics:

Tool-specific — Claude tools read it. Cursor doesn't (unless you explicitly include it in context).
Context-focused — best for explaining your project's architecture, decisions, and constraints. Not just rules, but why those rules exist.
Hierarchical — you can have a root CLAUDE.md plus subdirectory-specific ones (e.g., src/components/CLAUDE.md). Claude merges them based on what files it's working with.
Supports project commands — you can define shortcuts for common tasks like building, testing, and deploying.

A typical CLAUDE.md:

# Project Overview
Next.js 15 SaaS app for invoice management.
- Frontend: React 19, TypeScript, Tailwind CSS
- Backend: Next.js API routes, Drizzle ORM
- Database: PostgreSQL (Supabase)
- Auth: Better Auth with Google OAuth
- Payments: Stripe
- Deployment: Vercel

# Architecture
Feature-based folder structure:
src/
  app/         # Pages and API routes
  features/    # Feature modules (auth/, billing/, invoices/)
  components/  # Shared UI components
  lib/         # Utilities, DB client, API helpers

# Important Constraints
- Auth middleware runs on Edge Runtime — no Node.js APIs
- All monetary values stored as integers (cents), displayed as decimals
- Invoices use optimistic locking — always check version before update

# Commands
- Build: npm run build
- Test: npm run test
- Dev: npm run dev

The Key Differences

Aspect	.cursorrules	CLAUDE.md
Read by	Cursor only	Claude tools only
Primary strength	Coding rules and patterns	Project context and architecture
Tone	Imperative ("Do this, don't do that")	Descriptive ("Here's how the project works")
Hierarchy	Single file at project root	Root + subdirectory files, merged contextually
Best for	Enforcing code style and patterns	Explaining architecture and constraints
Project commands	Not supported	Supported (build, test, lint)
Glob scoping	Supported	Via subdirectory files

When to Use Which

Use .cursorrules when:

Your team primarily uses Cursor as their AI coding tool
You want to enforce strict coding patterns across all AI interactions
Your rules are mostly about code style: naming, imports, error handling patterns
You want rules that apply to inline edits and quick generations, not just chat

Use CLAUDE.md when:

Your team uses Claude Code or Claude-powered tools
You need to document complex architecture that requires explanation, not just rules
Your project has non-obvious constraints (edge runtime limitations, data format decisions, etc.)
You want project commands integrated into the AI workflow
Different parts of the codebase need different context (use subdirectory CLAUDE.md files)

Use both when:

Team members use different AI tools (some on Cursor, some on Claude)
You want consistent AI behavior regardless of which tool is used
You want the best of both: Cursor's pattern enforcement + Claude's architectural context

How to Use Them Together

Here's the approach that works best: put architectural context in CLAUDE.md, put coding rules in .cursorrules, and keep them in sync.

What goes in CLAUDE.md only:

Project overview and tech stack
Architecture decisions and their reasoning
Non-obvious constraints ("monetary values are stored as cents because...")
Common tasks with step-by-step instructions
Build/test/deploy commands

What goes in .cursorrules only:

The persona prompt ("You are an expert in...")
Cursor-specific behaviors (how to handle inline edits, tab completions)

What goes in both (keep synced):

Naming conventions
Folder structure
Import patterns
Error handling approach
"Do not" rules

Yes, there's some duplication. That's the cost of supporting multiple tools. The alternative — having rules in one file and not the other — means your AI behavior is inconsistent depending on which tool you're using. That's worse.

Keeping them in sync

The practical approach: treat CLAUDE.md as the source of truth for architecture and constraints, and .cursorrules as the source of truth for coding patterns. When you update a shared rule (like naming conventions), update both files. It takes 30 seconds and prevents drift.

Common Mistakes

1. Making them too long

Both files compete for the AI's attention window. A 2,000-line rules file means the AI is spending context on your instructions instead of on understanding the code it's working with. Aim for 200-500 lines max for each file.

2. Being vague

"Write clean code" is useless in both files. "Use named exports for all non-page files" is actionable. Be specific enough that there's only one way to interpret the rule.

3. Never updating them

Your project evolves. Your rules should too. If you switched from REST to tRPC three months ago but your CLAUDE.md still describes REST patterns, the AI will generate REST code. Review your files monthly.

4. Not including examples

AI tools are pattern matchers. A rule like "use the repository pattern for database access" is vague. A rule with a 5-line code example of what that looks like in your project is crystal clear.

Getting Started Today

If you have neither file, here's the 30-minute setup:

Create CLAUDE.md — write your project overview, tech stack, folder structure, and top 5 constraints.
Create .cursorrules — write your coding conventions, naming rules, and "do not" list.
Copy shared rules — naming conventions, folder structure, and import patterns should appear in both.
Test it — ask both tools to create a new component. Does the output match your conventions? If not, your rules aren't specific enough.

If you already have one file, creating the other takes 15 minutes — most of the thinking is already done.

For a deeper dive into CLAUDE.md specifically, check out our CLAUDE.md setup guide.

Originally published at bivecode.com

The Vibe Coding Security Checklist: 7 Things to Check Before You Ship

Junkyu Jeon — Thu, 16 Apr 2026 06:36:05 +0000

Here's a stat that should keep you up at night: 24.7% of AI-generated code contains security vulnerabilities. Nearly 45% of those hit the OWASP Top 10 — the most common, most exploitable categories of web security flaws.

This isn't because AI is bad at coding. It's because AI optimizes for making things work, not making them safe. When you ask it to "add a user login," it builds a functional login. It doesn't think about session fixation, brute force protection, or what happens when someone puts a SQL statement in the email field.

If you've built an app with Cursor, Bolt.new, Lovable, or any AI coding tool and you're about to ship it to real users — run through this checklist first. Each item takes 5-15 minutes. All of them together could save you from a breach that kills your product.

1. Secrets Are Not in Your Code

This is the most common and most dangerous mistake in AI-built apps. AI tools love to hardcode API keys, database URLs, and secrets directly in the source code.

Check for:

API keys in JavaScript/TypeScript files (search for sk-, pk_, key_, secret)
Database connection strings in source code
JWT secrets hardcoded in auth files
Third-party service credentials (Stripe, SendGrid, AWS) in client-side code

How to fix:

# Search your codebase for exposed secrets
grep -rn "sk_live\|sk_test\|password\|secret\|api_key\|apiKey" src/

# Move all secrets to environment variables
# .env.local (never committed to git)
DATABASE_URL=postgres://...
STRIPE_SECRET_KEY=sk_live_...
JWT_SECRET=your-secret-here

# .gitignore (make sure this exists)
.env
.env.local
.env.production

Critical: If secrets were ever committed to git, they're in the history even after removal. Rotate them immediately — generate new keys and revoke the old ones.

2. All User Input Is Validated

AI-generated code almost never validates input properly. It trusts whatever the user sends, which opens the door to injection attacks, crashes, and data corruption.

Check for:

Form inputs used directly without validation
API route parameters used without type checking
Database queries built from user input (SQL injection risk)
File uploads without type/size restrictions

How to fix:

// Use Zod for input validation in API routes
import { z } from 'zod';

const CreateUserSchema = z.object({
  email: z.string().email().max(255),
  name: z.string().min(1).max(100),
  age: z.number().int().min(13).max(150).optional(),
});

export async function POST(request: Request) {
  const body = await request.json();
  const result = CreateUserSchema.safeParse(body);

  if (!result.success) {
    return Response.json(
      { error: result.error.flatten() },
      { status: 400 }
    );
  }

  const { email, name, age } = result.data;
  // ... safe to use
}

Validate on the server, always. Client-side validation is for UX — server-side validation is for security. Never trust the client.

3. Authentication Is Actually Protecting Routes

AI tools often generate auth that looks right but has gaps. The login page works, but the API routes behind it? Wide open.

Check for:

API routes that should require authentication but don't check for a session
Middleware that checks auth on some routes but misses others
Admin-only endpoints accessible to regular users (broken access control)
Direct object references — can user A access user B's data by changing an ID in the URL?

Quick test: Open your browser's dev tools, find an API call your app makes, copy it as a cURL command, remove the auth cookie/token, and run it. If it still returns data, your route isn't protected.

// Every protected API route should start with this
export async function GET(request: Request) {
  const session = await getSession(request);
  if (!session) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  // For user-specific data, always filter by the authenticated user
  const data = await db.query.items.findMany({
    where: eq(items.userId, session.user.id), // NOT from URL params
  });

  return Response.json(data);
}

4. No Sensitive Data in Client-Side Code

Everything in your frontend JavaScript is visible to anyone who opens dev tools. AI tools frequently put things on the client side that should stay on the server.

Check for:

API keys in .env files prefixed with NEXT_PUBLIC_ that shouldn't be public
Business logic that reveals pricing algorithms, discount rules, or internal calculations
Error messages that expose database schema, file paths, or internal system details
User data from other users leaking into API responses (overfetching)

How to fix:

Only prefix env variables with NEXT_PUBLIC_ if they're truly meant to be public
Move business logic to server-side API routes or server components
Return generic error messages to the client, log detailed errors on the server
Shape API responses to include only what the requesting user needs to see

5. Rate Limiting Exists

Without rate limiting, anyone can hammer your API thousands of times per second. This leads to DDoS vulnerability, brute force attacks on login, and runaway costs on pay-per-use services (like AI APIs).

AI-generated code almost never includes rate limiting.

What to protect:

Login/signup endpoints — prevent brute force (5-10 attempts per minute)
AI generation endpoints — prevent cost abuse
Password reset — prevent email bombing (2-3 per hour)
General API — prevent abuse (100-1000 requests per minute)

// Using Upstash Redis for serverless rate limiting
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, '1 m'),
});

export async function POST(request: Request) {
  const ip = request.headers.get('x-forwarded-for') ?? '127.0.0.1';
  const { success } = await ratelimit.limit(ip);

  if (!success) {
    return Response.json(
      { error: 'Too many requests' },
      { status: 429 }
    );
  }
  // ... handle request
}

6. Dependencies Are Not a Liability

AI tools add npm packages liberally. Each dependency is code you didn't write running in your app. Some may have known vulnerabilities, be abandoned, or even be malicious.

# Check for known vulnerabilities
npm audit

# See what you've got installed
npm ls --depth=0

# Check for unused dependencies
npx depcheck

Fix critical and high vulnerabilities. Remove packages you don't use.

7. HTTPS, Headers, and CORS Are Configured

The boring infrastructure stuff that AI never sets up but attackers always check.

Essential security headers (add to next.config.ts):

const securityHeaders = [
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-XSS-Protection', value: '1; mode=block' },
  { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
];

const nextConfig = {
  async headers() {
    return [{ source: '/(.*)', headers: securityHeaders }];
  },
};

CORS: If your API is only used by your own frontend, don't enable CORS at all. If you need CORS, whitelist specific origins — never use * in production.

The 15-Minute Security Sprint

If you can only do one thing from this list, here's the priority order:

Secrets audit (5 min) — grep for exposed keys. Highest-impact, easiest-to-exploit.
Auth check (5 min) — test your API routes without authentication. Find the gaps.
Input validation (5 min) — add Zod to your most critical endpoint.

These three catch the majority of real-world attacks on AI-built apps.

A security breach doesn't just break your app. It breaks trust. Users whose data gets leaked don't come back.

AI made it possible to build an app in a weekend. But shipping it without a security review is like driving a car without brakes — it works fine until it doesn't, and when it fails, it fails catastrophically.

Spend the hour. Run the checklist. Ship with confidence.

Originally published at bivecode.com