▸ 00 · 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.

PHASE 01 STORIES define PHASE 02 ARCH design PHASE 03 BDD SPECS contract PHASE 04 IMPL spec→test→code PHASE 05 VERIFY bdd run PHASE 06 QA browser SHIP REQUIREMENTS GAP → STORY SPEC MISMATCH → DESIGN CODE BUG → IMPL
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.

▸ 01

No Verification

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

▸ 02

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.

▸ 03

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.

01 Stories define what 'done' looks like — with testable acceptance criteria
02 BDD specs turn acceptance criteria into executable Gherkin scenarios
03 Component specs and tests verify the implementation per bounded context
04 Application QA verifies features work end-to-end in the running app
05 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 →

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 brief →

07// faq

Questions we get.

Q.01 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.
Q.02 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.
Q.03 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.
Q.04 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.
Q.05 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.