Vibe Coding for Production: The Professional's Workflow

🤖 Ghostwritten by Claude Opus 4.5 · Edited by GPT-5.2 Codex · Curated by Tom Hundley

This article was written by Claude Opus 4.5, fact-checked by GPT-5.2 Codex, and curated for publication by Tom Hundley.

---

This is Part 6 of the Professional's Guide to Vibe Coding series. Start with Part 1 if you haven't already.

---

The Production Mindset

Karpathy's original vibe coding concept was explicitly for "throwaway weekend projects." The approach he described—accepting all changes, not reading diffs, working around bugs randomly—is fine when failure has no consequences.

Production code is different. Production code:

• Will be maintained by future developers (including future you)
• Handles real user data with real privacy implications
• Has actual users who experience actual bugs
• Represents commitments to stakeholders

The professional's workflow adapts AI-assisted development for contexts where quality matters.

---

The Core Cycle: Plan → Act → Review → Repeat

The fundamental workflow is simple:

1. Plan: Define what you're building before asking AI to build it
2. Act: Generate code in controlled, testable stages
3. Review: Verify output before integrating
4. Repeat: Iterate until the feature is complete

This isn't bureaucracy—it's the minimum structure needed to maintain quality while leveraging AI's speed.

---

Phase 1: Planning With AI

Before writing any code, establish clarity:

Define the Scope

Be explicit about what you're building and what you're not building:

I'm building a user authentication system with:
- Email/password login
- Session management
- Password reset flow

I am NOT building:
- OAuth/social login (future phase)
- Multi-factor authentication (future phase)
- User profile management (separate feature)

Specify Constraints

Make project-specific constraints explicit:

Constraints:
- Must integrate with existing PostgreSQL database
- Must use existing bcrypt password hashing utilities
- Sessions stored in Redis, not database
- All endpoints must return JSON, not HTML

Request an Outline First

Before asking for implementation, ask for a plan:

Before implementing, outline:
1. What new files you'll create
2. What existing files you'll modify
3. Dependencies you'll need to add
4. Database changes required

Review the outline. Adjust before investing in code generation.

---

Phase 2: Staged Implementation

Don't ask for everything at once. Break implementation into testable stages.

Example Staging Strategy

For the authentication system above:

Stage 1: Database schema and models

• Generate migration
• Review and test migration
• Commit when verified

Stage 2: Password utilities

• Generate hashing/verification functions
• Test with various inputs
• Commit when verified

Stage 3: Registration endpoint

• Generate endpoint
• Test happy path and error cases
• Commit when verified

Stage 4: Login endpoint and session management

• Generate endpoints
• Test authentication flow
• Commit when verified

Each stage is:

• Small enough to review thoroughly
• Testable in isolation
• Committable as a checkpoint

The Checkpoint Discipline

After each stage:

1. Run tests to verify behavior
2. Review code for security and architecture
3. Commit with a clear message
4. Only then proceed to the next stage

If a stage introduces problems, you can revert to the previous checkpoint instead of debugging a massive changeset.

---

Phase 3: The Review Discipline

Every piece of AI-generated code goes through review before integration.

The Quick Triage

For simple generations (under 50 lines):

• Scan for obvious security issues
• Verify imports and dependencies exist
• Check logic for edge cases
• Run tests

If triage passes, proceed. If not, regenerate or fix manually.

The Deep Review

For complex generations:

• Apply the full checklist from Part 3 of this series
• Test behavior, not just that it compiles
• Verify against original requirements
• Consider future maintainability

The Integration Check

Before committing:

• Does this integrate correctly with existing code?
• Are there conflicts with concurrent work?
• Do all tests pass, including existing ones?
• Is the commit message clear about what was done?

---

The CLAUDE.md Pattern

For projects using Claude Code or similar tools, a project context file maintains consistency across sessions.

What to Include

# Project: [Name]

## Quick Facts
- Language: TypeScript with strict mode
- Framework: Next.js 15 (App Router)
- Database: PostgreSQL with Prisma
- Styling: Tailwind CSS

## Key Constraints
- All API routes require authentication except /api/auth/*
- Never log PII or secrets
- All database operations use the ORM; no raw SQL
- Tests are required for all new features

## Patterns to Follow
- Use existing /lib/utils.ts helpers before creating new ones
- Error responses use the ApiError class from /lib/errors.ts
- Form validation uses Zod schemas in /lib/schemas/

## Current Focus
- Building user authentication system
- See /docs/auth-spec.md for requirements

## Files NOT to Modify
- /prisma/migrations/* (managed by Prisma CLI)
- /.env* (contains secrets)

Why It Works

Without persistent context, AI starts every session fresh. It doesn't know your patterns, constraints, or conventions.

With a CLAUDE.md file:

• AI starts with project-relevant context
• Patterns are applied consistently
• Constraints are honored without re-stating them
• Focus stays on the current work

---

Test-First Vibe Coding

One of the most effective patterns I've found:

Write Tests First, Then Generate Implementation

1. Write (or ask AI to write) the test cases
2. Review and adjust the test cases
3. Then ask AI to implement code that passes the tests

Why This Works

• Tests clarify requirements before coding begins
• AI has concrete targets instead of vague intentions
• You catch misunderstandings at the spec level, not the code level
• The tests become documentation

Example Flow

First, write test cases for a password strength validator:
- Should reject passwords under 8 characters
- Should reject passwords without uppercase
- Should reject passwords without lowercase
- Should reject passwords without numbers
- Should accept "ValidPass123" as valid

Then:

Now implement passwordStrengthValidator() that passes all these tests.

---

Real Workflow Example: Adding Search

Here's how I'd add semantic search to this blog:

Planning Phase

I want to add semantic search to the blog. Requirements:
- Users can search via a search bar
- Results ranked by relevance
- Must work with existing PostgreSQL database
- Should use embedding-based search

Before implementing, outline the approach and list all files
that will need to be created or modified.

AI provides outline. I review and adjust.

Stage 1: Database Setup

Create a migration to add a vector column to the posts table
for storing embeddings. Use pgvector extension.

Review migration. Test locally. Commit.

Stage 2: Embedding Generation

Create a utility function to generate embeddings from post content
using OpenAI's embedding API. Follow the patterns in /lib/openai/.

Review function. Test with sample content. Commit.

Stage 3: Search API

Create /api/search endpoint that:
- Accepts a query string
- Generates embedding for the query
- Finds similar posts via vector similarity
- Returns top 10 results with relevance scores

Review endpoint. Test with various queries. Commit.

Stage 4: Frontend Component

Create a SearchBar component that:
- Renders a search input
- Debounces input
- Calls the search API
- Displays results in a dropdown

Review component. Test in the UI. Commit.

Each stage is reviewable, testable, and committable. If stage 3 introduces problems, I don't lose stages 1 and 2.

---

Common Anti-Patterns

The Mega-Prompt

Asking for entire features in one prompt leads to:

• Overwhelming diffs that can't be reviewed thoroughly
• Errors that compound through the generation
• Difficulty identifying where things went wrong

Fix: Break into stages.

The Zero-Context Start

Starting a session without establishing project context leads to:

• Generic solutions that don't fit your patterns
• Repeated explanation of the same constraints
• Inconsistent code across sessions

Fix: Use CLAUDE.md or equivalent.

The Review Skip

"It's just a small change, I don't need to review it" leads to:

• Small bugs that accumulate
• Security issues that slip through
• Technical debt that compounds

Fix: Review everything. Smaller reviews are faster; use that as incentive to keep stages small.

---

The Bottom Line

Production vibe coding requires structure that weekend vibe coding doesn't:

• Plan before generating
• Stage into reviewable chunks
• Review every generation
• Test before committing
• Document context for future sessions

This structure adds time, but not as much as debugging a production incident would.

---

Next in the series: The Enterprise Adoption Playbook: Vibe Coding at Scale

---

Ready to level up your team's AI development practices?

Elegant Software Solutions offers hands-on training that takes you from AI-curious to AI-proficient—with the professional discipline that production systems require.

��� Book a consultation