The AI Coding Workflow That Feels Like Cheating

I've built a spec-driven workflow using Claude Slash Commands that mirror the best SDLC processes. The spec-driven workflow repository is available at wadew/claude_code

Vibe Coding

Twenty minutes ago, you were a wizard. Claude Code turned your napkin sketch into a working prototype. Then you tried to add a second feature.

Now you're debugging code you didn't write, fighting architecture you didn't design, wondering why the AI broke what worked five minutes ago.

Vibe coding: brilliant for exploration, catastrophic for production.

The Real Problem Isn't the AI

Better prompting won't save you.

A Sanity staff engineer called AI-generated code "95% garbage." That's what happens when you ask Claude Code to "build me a login page" and cross your fingers. No matter how elegant your prompt.

The problem isn't what Claude can do. It's how we talk to it. We treat coding agents like search engines when they're actually literal-minded pair programmers. You wouldn't hand a human developer a napkin sketch and expect production code. Why expect it from AI?

Process > Prompts

The tools I've created aren't just more prompts, they're a complete development workflow with slash commands implementing each phase. The beauty isn't in the words. It's in the conversation at every step.

Think about a healthy development team. A product manager asks clarifying questions before anyone writes code. An architect challenges assumptions before committing to a database schema. A scrum master breaks work into dependencies so parallel efforts don't collide.

That's what this workflow creates. Except your "team" is specialized AI agents working from the same specs, producing consistent artifacts, and stopping for your approval before each phase.

The Conversation That Changes Everything

Traditional AI coding looks like this: "Build me a feature." Get code. Iterate frustratingly. Give up. Rewrite from scratch.

This workflow flips the script. Instead of generating code, the AI asks you questions.

Here's what happens when you run /project:prd:

AI: I'll act as your Product Manager. Before we define features, let me understand the context…

AI: Who are the key stakeholders? Who will use this daily versus occasionally?

AI: What happens if this feature doesn't ship? What breaks for the business?

AI: I'm using the SPIN framework — let's explore the Situation first. What's the current state?

The AI becomes a thinking partner, not a typing assistant. It challenges assumptions. Asks uncomfortable questions. Represents the perspectives you're too close to see.

Here's the thing: you participate in this dialogue. You steer it. You add domain knowledge the AI can't access. The resulting spec is yours. It's informed by AI's systematic exploration, but grounded in your understanding of real-world context.

Why This Beats Better Prompting

Traditional approach:

• Single prompt, hope for the best
• AI writes code immediately
• No memory between sessions — you explain context repeatedly
• Vague requirements, vague code
• Quality is an afterthought — addressed after the AI builds the wrong thing
• One AI context, everything in your head

This workflow:

• Multi-phase development with explicit checkpoints
• AI helps you plan before any code exists
• State preserved in specification files that persist between sessions
• Structured specs produce focused implementations
• Quality gates are blocking — nothing proceeds without meeting standards
• Multiple expert agents contribute specialized knowledge at each phase

The spec-kit structure makes this possible. Everything lives in .specify/, organized into modular files that fit within Claude's context window:

.specify/
├── memory/
│   └── constitution.md    # Non-negotiables: security, quality standards
└── specs/
    └── {feature}/
        ├── spec.md        # PRD - what we're building
        ├── plan.md        # SRS - how we're building it
        ├── data-model.md  # Database schemas
        ├── contracts/     # OpenAPI specs
        └── tasks.md       # Sprint breakdown with dependencies

Each file runs 10–25KB. Small enough for AI context, large enough to be useful. Requirements traceable from FR-001 through implementation. Multiple AI agents work from the same source of truth without collision.

The Ideation Phase: Your AI Advisory Board

Before product requirements, there's an optional ideation phase that feels like magic.

Run /project:ideate and you spawn five sub-agents acting as your advisory board:

• Market Researcher: analyzes TAM/SAM/SOM
• Competitive Analyst: builds SWOT assessments
• Persona Builder: uses Jobs-to-Be-Done frameworks
• Unit Economics Expert: models LTV/CAC
• Validation Designer: proposes experiments to test your riskiest assumptions

What makes this powerful? They challenge each other. In practice, you'll see the Market Researcher flag timing risk based on consolidation trends. The Competitive Analyst adds context about recent well-funded entrants. A Devil's Advocate questions whether market crowding signals margin problems.

These aren't scripted responses. They emerge from the structured prompts and your domain input. But the quality depends on what you feed it. Vague ideas get generic analysis. Specific market data and real customer conversations? You get insights worth acting on.

Flags come early. Not after weeks of coding. Confidence levels are built into every output. You're in the conversation. Adding context. Steering analysis. Bringing domain expertise the AI lacks.

The Planning and Execution Phases

Start with three commands:

• /project:prd: The AI acts as your PM and gets you a proper spec. This alone transforms how you think about what you're building.
• /project:scrum: Tasks broken down, dependencies mapped. You'll know what runs in parallel and what waits.
• /session:implement: TDD-enforced execution (red, green, refactor) with quality gates that block progress until standards are met.

Ready to go deeper? Add these:

• /project:constitution: automatic quality enforcement
• /project:validate: cross-spec consistency checks
• /session:parallel: concurrent workers on larger sprints

For the full experience, the complete workflow runs: ideate, constitution, prd, prd_signoff, srs, ux, ui, validate, scrum, init, plan, implement/parallel, end.

Here's what matters: these aren't magic prompts. They're conversation starters.

Each slash command sets up an AI persona (Product Manager, Solutions Architect, Scrum Master) with:

• Structured discovery
• Decision gates requiring your approval
• Artifacts feeding into the next phase

The value is the process, not the words.

Three technical choices make the execution phase work:

Beads integration uses hash-based task IDs (bd-xxxx) to prevent merge conflicts when multiple people (or AI workers) touch the same codebase. Run bd ready to see which tasks are unblocked. Beads is an incredible tool built by Steve Yegge - read his stuff, use his tools.

Parallel execution works without external orchestration tools. Git worktrees create isolated environments. Headless claude -p runs portably. You get up to three concurrent workers with automatic merging, and the system handles context exhaustion recovery gracefully. This is not Claude sub-agents, this is true parallel agent execution.

Quality gates block. They don't advise. 80% test coverage or your sprint doesn't close. 100% test pass rate required. Constitution violations stop implementation. This isn't about shame. It's about catching problems when they're cheap to fix.

The tradeoff: Blocking gates add friction. For teams used to shipping fast and iterating, this feels slow. The payoff comes in reduced debugging time and fewer production incidents. But you won't see that benefit until you've used the workflow long enough to compare. Start with advisory gates if blocking feels too aggressive.

Try It

Try /project:prd on your next feature. Just that one command. Notice how different it feels when the AI asks you questions instead of generating code you'll spend hours debugging.

That shift (from AI-as-typing-assistant to AI-as-thinking-partner) is what this entire workflow is built around.

AI won't replace developers. It will replace developers who refuse to think with it. The job is still the same: understanding problems, making tradeoffs, building things that work.

But let's be honest: this workflow requires discipline. You'll be tempted to skip the PRD phase when you "just know" what to build. You'll want to bypass quality gates when deadlines loom. The process works when you trust it. It fails the moment you start cutting corners. The question isn't whether the workflow is good. It's whether you'll actually follow it.

The spec-driven workflow repository is available at wadew/claude_code. For deeper reading on the principles behind this approach, see the excellent work from GitHub's spec-driven toolkit, Thoughtworks' engineering practices analysis, and Red Hat's research on spec-driven quality improvements.