I Don't Vibe Code. Here's What I Do Instead.

Everyone and their LinkedIn recruiter is talking about vibe coding right now. Forbes is running headlines about solo founders shipping products overnight. Reddit threads are blowing up. Wikipedia literally has a page for it. And here I am, a senior developer who uses AI to write code 8+ hours a day, telling you: the vibe coding vs professional AI development distinction is the most important conversation nobody is having.

I use Claude Code every single day across product work, experiments, and production web apps. AI writes a massive percentage of my code. But that does not mean I hand the project to the model and hope for the best. The leverage is in deciding where AI belongs, what workflow fits the task, and how much structure the work needs before generation starts.

What Vibe Coding Actually Is

Andrej Karpathy coined the term in early 2025. The idea is simple: you describe what you want in plain English, the AI writes the code, and you accept it. You "give in to the vibes" and stop trying to understand every line. If it works, it works.

The concept took off because it's real. 84% of developers now use AI coding tools. The barrier to getting something running has never been lower. I've watched people with zero programming experience spin up functional web apps in an afternoon.

That's genuinely impressive. It's also genuinely dangerous when you're building something that matters.

Why I Don't Vibe Code

Here's the thing about accepting AI output blindly: it works until it doesn't. And when it doesn't, you're standing in a codebase you can't debug because you never understood it in the first place.

I've been building software for over 15 years. I've seen every flavor of technical debt. Vibe-coded debt is a new species. It's code that looks clean, passes a surface-level review, and hides problems that only surface when real users hit edge cases at scale.

Business Insider got it half right when they wrote that "the burden shifts to testing and reviewing." But that framing assumes the person doing the reviewing knows what to look for. A vibe coder who accepts AI output can't meaningfully review AI output. That's the paradox.

I wrote about this in my post on when Claude Code makes things worse. AI doesn't just produce bad code sometimes. It produces confident, plausible, subtly wrong code. The kind that passes your quick scan and breaks in production three weeks later.

What I Do Instead: Engineer the Workflow

The real shift isn't from writing code to not writing code. It's from manually typing every line to engineering the process that produces the right lines. The hard part is not "using AI." The hard part is deciding which parts of a project benefit from AI workflows, which parts need tighter control, and what kind of workflow fits the job.

A greenfield feature, a risky refactor, a production bug, and a one-off script should not all get the same AI treatment. Sometimes the right move is spec-first generation. Sometimes it is contract-first agent coordination. Sometimes it is low-effort scaffolding followed by manual implementation. Sometimes the correct answer is: do this part by hand.

Every technique I use comes back to one principle: set the stage, constrain the work, validate the outputs, trust nothing in between.

Context Engineering with AGENTS.md

My AGENTS.md file is over 200 lines. It defines hard rules (never push to main, never spend money without approval), correction patterns for repeated mistakes, delegation rules for agent teams, and security boundaries. Every time Claude Code starts a session in my workspace, it reads this file first.

This isn't configuration. It's context engineering. I'm not hoping the AI figures out my preferences. I'm telling it, explicitly, in a structured document that acts like onboarding for a new team member. I wrote a full breakdown in my post on context engineering for AI coding assistants.

The difference between vibe coding and what I do starts here. A vibe coder opens a chat and types "build me a dashboard." I open a workspace where the AI already knows my stack, my conventions, my security rules, and my deployment targets before I type a single word.

Scaffolding Beats Vibe Coding

The highest-leverage use of AI is often not "write the whole feature." It is spinning up the scaffolding that makes good implementation easier: specs, contracts, task breakdowns, file ownership, acceptance criteria, test plans, and validation steps.

That setup work sounds less glamorous than one-shot generation, but it is where most of the value lives. Good scaffolding turns AI from a guessing machine into a constrained builder.

Spec-Driven Development: Write the Spec, Not the Code

I use TinySpec to write structured specifications before any code gets generated. A spec includes task groups, subtasks, acceptance criteria, and test plans using Given/When/Then format.

Here's why this matters: when you tell AI "add billing to my app," you get generic payment code. When you hand it a spec that says "implement usage-based billing with metered subscriptions, prorated upgrades, and the event handling required to keep account state in sync," you get code that actually matches your business logic.

The spec is the product. The code is a byproduct.

# Example TinySpec structure
title: Billing Event Handlers
tasks:
  A:
    title: Invoice lifecycle handlers
    subtasks:
      A.1: Handle invoice.paid - update subscription status
      A.2: Handle invoice.payment_failed - trigger retry logic
      A.3: Handle customer.subscription.updated - sync plan changes
    test_plan:
      - given: A valid invoice.paid webhook fires
        when: The handler processes the event
        then: User subscription status updates to active

Writing specs takes 15 minutes. Debugging vibe-coded billing logic takes days. I'll take the 15 minutes.

Permission Workflows: Review What AI Does

Claude Code has a permission system, and I actually use it. When my AI agent wants to run a shell command, modify files outside the current scope, or do anything with side effects, I get a notification on my phone. I review it. I approve or deny it.

I detailed this entire setup in my post on the Claude Code permission workflow. The key insight: this isn't about slowing things down. It's about staying in the loop. I'm the architect reviewing pull requests from a very fast, very capable junior developer who occasionally hallucinates.

Vibe coders turn permissions off. They run Claude Code in YOLO mode and let it do whatever it wants. For a weekend hack, fine. For a production app handling real payments? Absolutely not.

Contract-First Agent Teams

When I need multiple AI agents working on related features, they don't just go off independently and hope for the best. I use contract-first spawning, where agents coordinate through shared specifications.

Agent A produces a typed interface. Agent B consumes it. The contract is defined before either agent writes a line of code. This is the same principle that makes microservices work, applied to AI development.

Agent 1: Build the API endpoint (outputs OpenAPI spec)
Agent 2: Build the frontend component (consumes that spec)
Contract: The spec is written first, both agents reference it

Without this, you get two agents that each produce working code in isolation and a three-hour integration headache when you try to combine them. I've been there. It's not fun.

Validation Loops: Never Trust, Always Verify

Every sub-agent that reports "task complete" gets verified. I run git status. I check that files actually exist. I run the tests. I look at the output with my own eyes.

This sounds paranoid. It is. It's also necessary. AI agents are phenomenal at producing detailed, confident summaries of work they didn't actually finish. I've had agents tell me "all tests passing" when they never ran the test suite. The validation loop catches this.

My rule: if an agent says it's done, verify three things before moving on. Did the files change? Does it build? Does the actual feature work?

The Real Skill Shift

The question used to be "can you write code?" Now it is also "can you design the right workflow for this problem?" That is a different skill than prompting, and honestly a more important one.

Writing code is still a craft. But directing AI well means choosing the right mode for the work:

• scaffold first or generate directly?
• one agent or coordinated agents?
• prototype workflow or production workflow?
• low-effort exploration or high-effort implementation?
• manual fix, assisted fix, or full delegated pass?

That is engineering judgment. You need to understand architecture, system design, security implications, business logic, and failure modes well enough to decide how the work should happen before the model starts typing. You need more experience, not less.

That academic paper, "Vibe Coding Kills Open Source," makes a real point. If contributors don't understand the code they're submitting, the review burden shifts entirely to maintainers. The bottleneck doesn't disappear. It moves.

Augment Code published research suggesting professional practice should combine vibe coding speed with spec-driven durability. I agree with the framing. Speed without structure is just fast failure.

I run Claude Code hard enough that model access and tooling choices matter. But the tooling is maybe 20% of the equation. The other 80% is knowing what to ask for, how to structure the ask, and how to evaluate what comes back.

When Vibe Coding Is Perfectly Fine

I'd be dishonest if I said vibe coding is always wrong. It's not.

Building a prototype to test an idea? Vibe code it. Hacking together a script to rename 500 files? Vibe code it. Weekend project that nobody else will ever touch? Go for it. Exploring an unfamiliar API to see how it works? Accept the vibes.

The problem isn't vibe coding as a technique. It's vibe coding as an identity. It's building production software, handling user data, processing payments, and scaling to thousands of users on a foundation of "the AI said it works, so it probably works."

Know when you're prototyping and when you're building. Vibe code the former. Engineer the latter.

The Future Is Process Engineering

The conversation about AI coding keeps splitting into two camps: people who think AI replaces developers and people who think AI is just autocomplete with better marketing. Both are wrong.

AI is a force multiplier for developers who know how to shape the work before generation starts. The multiplier depends entirely on workflow design. No workflow, no multiplier. Just fast, confident, broken code.

I do not get the biggest wins from asking AI to magically build software. I get them from setting the stage: the spec, the constraints, the contracts, the validation gates, the context, the handoff points, the approval boundaries. Once that scaffolding is in place, the implementation moves fast.

That is why this is bigger than vibe coding. The craft is not just writing code or prompting for code. It is deciding where AI helps, where it hurts, and what operating mode fits this exact project, feature, or bug.

I engineer context, scaffolding, and validation. AI handles the typing acceleration inside that system. That is not vibe coding. That is the job, evolved.