StructuredPromptDrivenDevelopment
title: Structured-Prompt-Driven Development type: technique created: 2026-05-19 last_updated: 2026-05-19 related: ["Playradar", "radar/techniques/LLMTDDLoop", "radar/tools/TDDGuard", "radar/tools/Lattice"] sources: ["https://martinfowler.com/articles/structured-prompt-driven/"] radar_quadrant: Techniques radar_ring: Assess radar_position: inner
A software engineering methodology that treats prompts as maintained, version-controlled artifacts rather than disposable chat logs. Published on Martin Fowler's martinfowler.com. The central claim: individual developer speed from AI assistants does not automatically translate to faster team delivery. SPDD makes LLM-assisted development governable, reviewable, and reusable at the team level.
Unstructured prompt-driven development produces speed for individuals but creates friction at scale: ambiguous requirements expand into code, reviews are difficult, integration is hard to coordinate, and production risk is high when change velocity is high. Prompts are ephemeral — the intent behind each code generation is lost.
The methodology centres on a seven-part structured prompt template:
| Section | Content |
|---|---|
| Requirements | What must this do |
| Entities | Domain objects and their relationships |
| Approach | Technical strategy chosen |
| Structure | File and module organisation |
| Operations | Concrete implementation steps |
| Norms | Coding standards and conventions |
| Safeguards | Error handling, security, edge cases |
The canvas forces clarity on constraints before code generation begins.
Prompts as first-class artifacts: Prompts are versioned alongside code in the repository. A diff of prompts is reviewable like a diff of code.
Intent-before-code workflow: Requirements → entities → design → prompt → code → test. Each step is a discrete artefact.
Bidirectional synchronisation: When implementation diverges from the prompt, the prompt is updated first — or the code is refactored and the prompt synced back. The prompt is the source of truth for intent.
The methodology frames AI-assisted development as shifting developer value from typing speed toward clarity of thought, problem framing, and decision-making. The REASONS canvas externalises design decisions that would otherwise remain implicit.
LLM TDD Loop (Assess/center) focuses on test-driven iteration with a shell script orchestrating the LLM and test runner. SPDD operates upstream: it structures the prompt before any code generation begins. TDD Guard (Tools/Assess/inner) enforces TDD discipline at tool-call level. Lattice (Tools/Assess/inner) composes skill workflows. SPDD complements all three by adding version-controlled intent to the development process.
Structured-Prompt-Driven Development sits in the Assess ring of the Techniques quadrant, at inner position. First studied via martinfowler.com on 2026-05-19; no personal use. Inner position reflects direct applicability to any active Claude Code project — no tooling is required to start, only the discipline of writing prompts using the REASONS canvas and committing them alongside code. Martin Fowler's platform adds practitioner credibility. The remaining gate before Trial is a completed project where prompts are versioned and the REASONS canvas is used throughout the development cycle.
