From Prompt to Production: The AI Developer Workflow

"Build me a discount code feature."

You type that into your AI coding agent. It generates 400 lines across six files. Some of it looks right. Some of it uses patterns from a completely different framework. You spend the next two hours untangling what fits and what doesn't.

This is how most developers work with AI right now. And it's the slow way.

There's a structured workflow that turns AI from a code slot machine into an actual engineering partner. It has six phases, and each one matters.

Phase 1: Plan before you prompt

The single biggest mistake developers make with AI: jumping straight to "build this." No context. No constraints. No definition of done.

Start in plan mode. Write a feature prompt that gives AI everything it needs to make good decisions:

# Feature: Add discount codes to checkout

## Context
- E-commerce app, Next.js + TypeScript + Prisma
- Existing: Cart, Checkout, PaymentService
- Pattern: domain services in /src/domain/, API routes in /src/app/api/

## Requirements
- Users enter a discount code at checkout
- Validate code exists, not expired, not over usage limit
- Apply percentage or fixed discount to order total
- Store which code was used on the order

## Constraints
- Follow existing service pattern (constructor injection, Result types)
- Discount logic lives in domain layer, not in the API route
- Tests required for validation edge cases

This takes five minutes. It saves hours. The prompt tells AI your stack, your patterns, your constraints, and what "done" looks like. Without it, AI guesses. With it, AI follows your architecture.

What makes a good feature prompt

Context: what exists already, what stack you're using
Requirements: what the feature does, written as behaviors
Constraints: which patterns to follow, where code should live
Boundaries: what AI should build vs. what you'll handle yourself

Phase 2: Discuss the plan with AI

Don't approve the first plan AI produces. Treat it like a pull request from a junior developer. Read it critically.

Good questions to ask:

"What happens when two users apply the same discount code at the exact same moment?"
"Where does validation live? Show me the file structure."
"What errors can this throw and how does the frontend handle each one?"

Go back and forth until the plan covers edge cases, error handling, and fits your existing patterns. This discussion phase is where the real engineering happens. AI executes. You decide.

Phase 3: Let AI work, but steer

Once you approve the plan, AI starts building. Your job shifts from writing code to monitoring direction.

Watch for these signals while AI works:

Green flag	Red flag
Following your existing service patterns	Inventing a new pattern for this one feature
Imports from your existing modules	Installing new dependencies you didn't discuss
Error types matching your conventions	Generic try/catch with string error messages
Tests that verify behavior	Tests that just assert the code runs without error

When AI drifts, correct early. A two-sentence redirect now prevents a 200-line rewrite later.

Phase 4: Review before committing

AI finished the implementation. Do not commit yet. This is where the four-check review happens:

> Review the discount code implementation:
> - Check for security issues (code enumeration, race conditions)
> - Verify edge cases in validation logic
> - Write unit tests for DiscountService
> - Check that error messages don't leak internal details

Ask AI to review its own work. Sounds circular, but it catches real issues. AI in "build mode" optimizes for completing the feature. AI in "review mode" optimizes for finding problems. These are different mindsets, even for a model.

Then review it yourself. Focus on:

Domain logic correctness: does the discount calculation actually work for all cases?
Security: can someone enumerate valid codes by timing responses?
Integration: does this fit cleanly with the existing checkout flow?
Test quality: do tests cover the edge cases or just the happy path?

Phase 5: Automated quality gates catch what you missed

Your local pre-commit hooks run first:

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: typecheck
        name: TypeScript type check
        entry: npx tsc --noEmit
        language: system
        pass_filenames: false

      - id: lint
        name: ESLint
        entry: npx eslint --fix
        language: system
        types: [typescript]

      - id: test
        name: Unit tests
        entry: npx vitest run --changed
        language: system
        pass_filenames: false

Type checking, linting, and unit tests run before code leaves your machine. If anything fails, you fix it before the commit exists.

Then CI/CD runs on the pull request:

# .github/workflows/ci.yml
name: CI
on: [pull_request]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npx tsc --noEmit        # Type safety
      - run: npx eslint .             # Code quality
      - run: npx vitest run --coverage # Tests + coverage floor
      - run: npx audit-ci --moderate  # Dependency security

If CI finds issues, AI processes the findings and proposes a fix plan. You review the plan, approve it, and AI fixes the issues. No manual debugging of CI failures.

This is the quality safety net that makes AI-generated code production-safe. Without automated gates, every AI output is a gamble. With them, problems get caught before they reach your teammates.

Phase 6: Peer review and merge

The pull request is green. CI passes. Now another developer reviews it.

This is not optional. The four-eyes principle exists because two people catch more issues than one, regardless of how good the AI is. Your reviewer isn't checking syntax (linters do that). They're checking:

Does this approach make sense for the domain?
Are there architectural implications I missed?
Will this be maintainable in six months?

If the reviewer has comments, you go back to plan mode. Not from scratch. You update the existing plan, AI makes the changes, and the cycle continues until the PR is approved.

Then you merge. CI runs one final time on the merged branch. Done.

The full loop

Here's the complete workflow, six phases:

Plan: Write a feature prompt with context, requirements, constraints
Discuss: Challenge the plan, cover edge cases, agree on approach
Build: AI works while you monitor direction and course-correct
Review: AI self-reviews for security, tests, performance. Then you review for domain correctness
Automate: Pre-commit hooks and CI/CD catch what humans miss
Merge: Peer review, address comments, merge when approved

Each phase takes minutes, not hours. The whole loop from feature prompt to merged PR can happen in a single focused session. Compare that to the old way: days of implementation, a day of review, another day of fixes.

Why this beats "just prompting"

The unstructured approach (type a prompt, get code, paste it in) feels faster. It's not. You spend the time you "saved" on debugging integration issues, fixing pattern mismatches, and explaining to reviewers why the code looks different from the rest of the codebase.

The structured workflow front-loads five minutes of planning and saves hours of cleanup. It works because it treats AI as a junior engineer who needs clear instructions, not a magic box that reads your mind.

That's the difference between using AI and working with AI.

From Prompt to Production: The Workflow That Actually Ships