There are two completely different ways to work with AI on code, and most developers are doing one when they should be doing the other.
The first way: you describe what you want, accept what the AI gives you, iterate fast, and don't overthink it. You're in flow. You're shipping. You barely read the diff.
The second way: you break the task down, hand the AI specific pieces, review every change carefully, and stay firmly in the architect seat. The AI handles implementation. You own the design.
These aren't just different styles. They produce different results, different quality levels, and different failure modes. Knowing which one your task needs — before you start — saves a lot of cleanup.
What vibe coding actually is
Vibe coding is the low-friction mode. You give the AI a loose description, accept output that's roughly right, and keep moving. You're not reading every line. You're not challenging the architecture. You're saying "make it work" and trusting that it will.
This is appropriate in a lot of situations:
- Throwaway scripts you'll run once
- Prototypes you're using to validate an idea
- Exploring an unfamiliar library or API
- Personal tools where security and maintainability don't matter
- First drafts of UI components you'll redesign anyway
The key mental model: you're not taking ownership of the code. You're borrowing it. If it works, great. If it breaks, you'll fix it or regenerate it.
In practice, vibe coding looks like this:
"Build a script that reads a CSV of email addresses, deduplicates them,
and outputs a clean list sorted alphabetically."
You run the output. It works. You ship it. You never look at the code again.
The session has a rhythm: describe, generate, test, describe again. You're not reviewing implementation details. You're testing behavior.
What AI pair programming actually is
AI pair programming is deliberate. You're still the architect. The AI is a fast, tireless implementer who does exactly what you tell it — as long as you tell it precisely.
You break the work down before you prompt. You review every diff before you commit. You push back when the AI takes shortcuts you wouldn't take. You maintain the design decisions yourself.
This is the right mode for:
- Production code that will be maintained by a team
- Systems where security matters (auth, payments, user data)
- Refactors that touch core abstractions
- Anything with complex business logic the AI can't infer from context
- Code that needs to meet specific architectural standards
The mental model here is the opposite: you own the code completely. The AI is accelerating your typing, not making decisions for you.
A pair programming prompt looks very different:
"Add a rate limiter to the /api/login endpoint. Use the existing Redis client
from lib/redis.ts. Limit to 5 attempts per IP per 15 minutes. Return 429 with
a Retry-After header when exceeded. Don't change the middleware chain order."
You review the diff. You check the Redis key format. You verify the 429 response structure matches your error handling patterns. You merge when it looks right.
The decision framework
Here's how to decide which mode to use before you start:
Will this code be deployed to production? If yes, pair programming. If no or maybe, vibe coding is fine.
Will someone else maintain this code? If yes, pair programming. Vibe-generated code tends to have idiosyncratic patterns that are hard for others to follow.
Does this touch security-sensitive paths? Auth, payments, PII, admin routes — always pair programming. The AI will often generate code that looks correct but misses subtle security requirements.
How well do you understand the domain? If you're an expert in this area, vibe coding is fine because you can spot problems instantly. If you're learning, pair programming forces you to understand what's being generated.
Is the task exploratory or execution? Exploring new ideas = vibe coding. Executing against known requirements = pair programming.
How much context does the AI have? If the AI has never seen your codebase and you're asking it to touch core infrastructure, that's a pair programming situation. The AI needs constraints and guidance, not freedom.
What's the cost of a bug? Low stakes = vibe coding. High stakes = pair programming.
How vibe coding goes wrong
The failure mode of vibe coding isn't "the code doesn't work." That's easy to catch.
The real failures are:
Context drift. You start a session, add features, keep going. By the end, the AI has accumulated contradictory context and is quietly patching over inconsistencies. The code runs but the logic is tangled. You don't notice until you try to extend it six months later.
Hallucinated dependencies. The AI imports a package that doesn't exist, or calls a method on an object that doesn't have it in your version. If you're not reading the code, you might not notice until runtime.
Silent security holes. SQL queries that aren't parameterized. File paths that aren't sanitized. JWT tokens that aren't verified. These don't produce errors. They produce vulnerabilities.
Architecture rot. Vibe coding for six weeks on a codebase that needs structure produces a mess. Every new feature worked, but nothing coheres.
None of this means vibe coding is bad. It means it has a context where it's appropriate and one where it isn't.
Making vibe coding safer with project rules files
The biggest practical improvement to vibe coding safety is maintaining a project rules file: CLAUDE.md, .cursorrules, or whatever your editor uses.
This file gives the AI persistent context about your project: the stack, the patterns you follow, the files you want it to read before touching anything, the things it shouldn't do.
When the AI knows your conventions up front, it generates code that fits your codebase instead of code that works in isolation. The architectural decisions you'd make in pair programming mode get baked into the rules file once, and then apply automatically in every vibe coding session.
Good project rules files include:
- Stack and version specifics
- File structure and naming conventions
- Patterns you always follow (e.g., always use the existing error handler, never use raw SQL)
- Patterns you never want (e.g., don't use any, don't install new packages without asking)
- Key files the AI should read before making changes
See how to write a CLAUDE.md for any project for a full breakdown. This single artifact lets you maintain much of vibe coding's speed while reducing its risks.
Context engineering goes deeper on this: what you put in the context window shapes what the AI generates, and project rules files are a structured way to control that input.
How a pair programming session actually runs
Here's what a real pair programming session looks like on a non-trivial task.
Say you need to add webhook signature verification to an API. Instead of asking the AI to "add webhook security," you break it down first:
- Read the webhook provider's docs and extract the verification algorithm
- Identify where in the middleware chain this should live
- Write the prompt: exactly what to implement, which files to touch, what patterns to follow
- Review the generated code against the docs
- Run tests
- If anything looks wrong, push back with specifics
The prompts are tighter. The reviews are more careful. The session takes longer. But the output is code you'd confidently put in production.
The hybrid approach
Most real work doesn't fit cleanly into one mode. The practical pattern is: vibe code to explore, pair program to ship.
When you're uncertain about an approach, vibe coding is the fastest way to find out if it works. Build a rough version quickly. See the shape of the solution. Find the problems.
Once you understand the problem space, switch modes. Throw away the vibe-coded prototype (or at least treat it as pseudocode). Write the production version with care, reviewing every step.
This isn't wasteful. The exploration phase is learning. The pair programming phase is building. They serve different purposes and you should let them.
A concrete comparison
Same task, two modes.
The task: add pagination to an API endpoint.
Vibe coding prompt:
"Add cursor-based pagination to the /api/posts endpoint"
You accept what comes back, test it, ship it.
Pair programming prompt:
"Add cursor-based pagination to GET /api/posts in src/routes/posts.ts.
The cursor should be the post ID (integer). Accept ?cursor=ID&limit=N
query params. Default limit 20, max 100. Return { data: Post[], nextCursor: number | null }.
Use the existing Prisma client from lib/db.ts. Follow the same pattern as
the existing /api/comments endpoint for the response shape."
You review the Prisma query. You check the limit clamping. You verify the nextCursor logic handles the last page correctly. You merge.
The first version gets you something that works in demo. The second gets you something you can maintain.
Pick the mode that matches what you actually need.
