Test-Driven Vibe Development: Integrating Quality Engineering with AI Code Generation

asos · E-commerce · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: AI-assisted software delivery and quality engineering

ASOS needed to use LLM code generation without accepting the reliability risks of unstructured vibe coding, while building an internal stock discrepancy reporting system with a small part-time team.

Constraints:

• The system had to produce a full-stack MVP, not just a prototype.
• LLM context loss could occur across long development phases.
• Quality had to be defined before implementation.
• The team was relatively unfamiliar with parts of the technology stack.
• The reported speedup has a baseline-estimate caveat.

Architecture

ASOS created Test-Driven Vibe Development, a workflow that puts acceptance criteria, BDD, TDD, and architecture-driven testing before AI-generated code. Agents generate tests and implementation in short validated loops for a backend API, Azure Functions, data stores, and React frontend.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  architecture_driven_test_strategy["Architecture-driven test strategy"] --> acceptance_and_behavior_tests["Acceptance and behavior tests"]
  acceptance_and_behavior_tests --> ai_code_generation_agents["AI code generation agents"]
  ai_code_generation_agents --> generated_application["Generated application"]
  generated_application --> validation_loop["Validation loop"]
  validation_loop --> ai_code_generation_agents

Components

Data flow

The workflow begins with architecture and acceptance criteria, converts expected behavior into tests, uses AI agents to generate code against those tests, and validates each increment before moving to the next feature slice.

Why this architecture

TDVD exists because LLMs are probabilistic and context-limited; test-first structure gives the model narrow targets and automated quality gates instead of asking it to improvise large systems.

Models used: LLM code generation agents

Scale

• A 2.5-person part-time team delivered the MVP in 4 weeks.
  “With a team of effectively 2.5 people working part-time, they delivered a full-stack MVP (backend API, Azure Functions, React frontend) in 4 weeks”summary, stated
• The build took about 42 hours of active development time.
  “in just four weeks with approximately 42 hours of active development time.”summary, stated
• ASOS claimed a 7-10x acceleration, with baseline caveats.
  “representing a 7-10x acceleration compared to traditional development estimates”summary, stated

Alternatives considered (roads not taken)

Typical vibe coding with code first and tests later

Rejected because: It exposes teams to hallucinated or low-quality code without early executable requirements.

Traditional manual delivery

Rejected because: The team estimated it would take much longer, though the baseline was influenced by stack unfamiliarity.

Patterns

eval-driven-development (quality)

Tests and acceptance criteria are written before generated code and used as continuous validation gates.

context-engineering (workflow design)

The team kept features small and iterations short to prevent context loss across long prompts.

Tradeoffs

Use test-first AI development.

Chose TDVD with ATDD, BDD, and TDD over Unstructured vibe coding.

Rationale: The tests constrain model output and catch hallucinations early.

Gotchas (what bit them)

Long prompts can lose development context.

Root cause: Transformer attention becomes thinly spread across large, complex contexts.

Resolution: Keep feature slices and iteration loops short, with tests anchoring intent.

Headline acceleration can be overstated if the baseline team lacks stack familiarity.

Root cause: The comparison used an estimate from a team unfamiliar with the technology stack.

Resolution: Treat the 7-10x claim as promising but caveated.

Evaluation

ASOS evaluated the workflow through delivery time, active development hours, test validation, and caveated comparison to traditional estimates.

Metrics: 4 week MVP delivery. · Approximately 42 active development hours. · 7-10x acceleration claim with baseline caveat. · Continuous validation against predefined test requirements.

Outcomes

• ASOS delivered a full-stack stock discrepancy reporting MVP in four weeks.
• The team reported approximately 42 active development hours.
• The case claims 7-10x acceleration, while noting baseline caveats.

The case is a single internal MVP, not a broad production rollout; the clearest scale facts are 2.5 part-time people, four weeks, and 42 active hours.