The method v1.0 · production

The CodeMySpec Method.

Generating code is the easy part. Shipping is the loop.

AI can write code. Shipping working software takes stories, architecture, BDD specs, verified implementations, and QA. Six phases, every artifact verified by the next, problems routed back to the right level. Here's the full loop.

By John Davenport · the engineer who built CodeMySpec with CodeMySpec

Install CodeMySpec See the loop ↓

01 the loop

Six phases. Every artifact verified.

Stories define what done looks like. Each subsequent phase verifies its predecessor. When verification fails, the issue routes back to the level that owns it — story, design, or code. The forward path is solid. The feedback edges are dashed. That's the whole methodology in one diagram.

Forward · artifact passed

Feedback · routed by root cause

02 the problem

Code generation isn't software.

Most AI coding tools stop at code generation. You get output that looks right, passes a vibe check, and falls apart in production.

No Verification

Generated code compiles and maybe passes a few tests. But does it actually do what the user asked for? Nobody checks.

No Traceability

Requirements live in a chat thread. Architecture lives in the AI's head. When something breaks, there's no trail back to intent.

No Feedback Loop

When QA finds a bug, where does it go? Back into the same chat? A new prompt? There's no structured path from 'this is broken' to 'this is fixed.'

AI code generation without verification is just sophisticated autocomplete. You need the full loop.

03 the solution

The full loop.

Code generation is one step in a six-step process. Every step produces artifacts that the next step verifies against. Nothing ships without passing through the full loop.

Stories define what 'done' looks like — with testable acceptance criteria
BDD specs turn acceptance criteria into executable Gherkin scenarios
Component specs and tests verify the implementation per bounded context
Application QA verifies features work end-to-end in the running app
Problems at any gate route back to the right level — story, design, or code

Stories→Architecture→BDD Specs→Impl→QA→Ship.

04 the six phases

Each phase is a real artifact.

Phase 01 of 06 Stories

Stories

Define what 'done' looks like

The Stories MCP Server interviews you about requirements, generates stories with acceptance criteria, and tracks them through the development lifecycle. Stories link to bounded contexts and BDD specs automatically.

AI interviews you with a structured PM persona

Generates stories with testable acceptance criteria

Stories link to contexts and BDD specs automatically

Track status throughout the development lifecycle

Creates User stories with testable acceptance criteria

Managing User Stories →

Phase 02 of 06 Architecture

Architecture

Define bounded contexts and dependencies

The Architect MCP Server designs bounded contexts, validates dependencies, and catches circular references before implementation begins. Component spec stubs are generated for each context.

AI designs bounded contexts with dependency validation

Architecture review catches circular dependencies

Component spec stubs generated per context

Full dependency graph visualization

Creates Context boundaries, dependency graph, component spec stubs

Managing Architecture →

Phase 03 of 06 BDD Specs

BDD Specs

Turn acceptance criteria into executable scenarios

AI generates one Gherkin scenario per acceptance criterion. These scenarios run against the actual application after implementation — they're the contract between stories and working software.

One Gherkin scenario per acceptance criterion

Scenarios validated against story structure

Execute against the running application

BDD specs are the contract between stories and software

Creates Gherkin scenarios for each story's acceptance criteria

BDD Specs for AI-Generated Code →

Phase 04 of 06 Implementation

Implementation

Specs → tests → code → green, per bounded context

Session orchestrators handle the full spec → test → code → green loop. Component specs are generated from the context design, tests are written from specs, and implementation iterates until all tests pass.

Component specs generated from context design

Tests written from specs — they fail first (TDD)

AI implements and iterates until green

Static analysis validates code quality

Creates Component specs, tests, and implementation that passes all tests

Writing Design Documents for AI →

Phase 05 of 06 BDD Verification

BDD Verification

Run BDD specs against the app — does it actually work?

BDD specs execute against the live application. Failures generate structured issues with reproduction steps, categorized by root cause: spec problem, design problem, or implementation bug. The feedback loop routes issues back to the right phase.

Specs execute against the live application

Failures generate structured issues automatically

Issues categorized by root cause

Feedback loop routes to the right phase

Creates Verified features that pass acceptance criteria against the running app

Verification Over Writing Code →

Phase 06 of 06 Application QA

Application QA

Browser automation, screenshots, and end-to-end verification

The QA agent tests each story against the running application using browser automation. It clicks through flows, takes screenshots, and files structured issues for failures. Features ship when QA passes.

Browser automation tests each story

Screenshots captured at key states

Structured issues filed for failures

Features ship when QA passes

Creates QA results with screenshots, filed issues, ship-ready features

Agentic QA Verification →

05 the proof

Built with the loop. Shipped with the loop.

I built CodeMySpec using this method. Every feature went through the full loop.

Stories with acceptance criteria drive every feature
Architecture review catches design problems before implementation
BDD specs verify features do what users asked for
Unit tests verify implementations match their specs
Application QA catches what automated tests miss
The feedback loop routes problems to the right level

Every feature traces from story → BDD spec → implementation → QA. The loop is the methodology.

06 start the loop

Run the loop on your codebase.

Phoenix-native today, ~30 minutes to set up. Install the plugin, run the story interview, and you're in phase 01.

Try CodeMySpec Talk to John →

/codemyspec

/plugin marketplace add Code-My-Spec/plugins

/plugin install codemyspec@codemyspec

claude code · v1.0 Read the brief →

07 faq

Questions we get.

How is this different from just using Cursor/Copilot/Claude?

Those tools generate code. This is a methodology for shipping working software. Code generation is step 4 of 6. The verification steps — BDD specs and application QA — are what catch the problems that code generation introduces.

Why BDD specs AND unit tests?

They catch different things. Unit tests verify the implementation matches its spec. BDD specs verify the feature does what the user asked for. You need both — unit tests passing doesn't mean the feature works.

What if requirements change?

Update the story → BDD specs update → implementation changes flow through the same loop. Every change goes through verification. The traceability means you can see exactly what's affected.

Isn't this a lot of overhead?

Less than you'd think. Most of the artifacts are generated. And it's far less overhead than debugging AI-generated code that passed a vibe check but doesn't actually work. The verification steps save more time than they cost.

What happens when BDD specs or QA finds a problem?

Problems get filed as structured issues and routed to the right level. A code bug goes back to implementation. A spec mismatch goes back to design. A requirements gap goes back to the story. The feedback loop is the point.

08 ready

Now run the loop on your codebase.

~30 minutes to set up. One Claude Code plugin install. BYO model, BYO keys.

Get started See install commands ↑

Comparing approaches first? Read the neutral guide to spec-driven development covering the whole tool landscape.