Structured-Prompt-Driven Development (SPDD)
Structured-Prompt-Driven Development (SPDD)
How to make LLM-assisted changes governable, reviewable, and<br>reusable
LLM programming assistants have demonstrated considerable value, but mostly with<br>individual developers. The internal IT organization in Thoughtworks has been<br>using them for their teams and have developed a method and workflow called<br>Structured Prompt-Driven Development (SPDD). The article describes a simple<br>example of this workflow with details in github. This<br>workflow treats the prompts as a first-class artifact, kept with the code in<br>version control, and used to align development with business needs. We have<br>found that developers need three key skills to be effective: alignment,<br>abstraction-first, and iterative review.
28 April 2026
Wei Zhang
Wei Zhang is an AI-assisted delivery expert at Thoughtworks.<br>With nearly a decade of experience in software delivery, including three<br>years focused on architecture, he designs engineering practices for<br>AI-augmented software delivery — evolving the methods that help teams<br>harness AI with both speed and discipline.
Jessie Jie Xia
Jessie Xia is Global CIO at Thoughtworks, where she has built<br>a 20-year career across software delivery, business leadership, and enterprise<br>technology transformation. She previously served as Managing Director for<br>Southeast Asia with P&L responsibility, and earlier spent five years in<br>software delivery. She now focuses on advancing AI-first software delivery<br>at Thoughtworks Global IT Services, while also sharing practical perspectives<br>with clients on how to apply AI in ways that are governed, scalable, and<br>reliable.
generative AI
Contents
What is SPDD?
The REASONS Canvas
The SPDD workflow
Enhancing a billing engine with SPDD
The current system
The enhancement
Step 1: Create initial requirements
Step 2: Clarify analysis
Step 3: Generate analysis context
Step 4: Generate structured prompt
Step 5: Generate code
Step 6: generate unit tests
What this example delivered
Three core skills
Abstraction first
Alignment
Iterative Review
Where SPDD fits
Fitness assessment
Trade-offs to consider
Closing
Sidebars
What SPDD adds to spec-driven development
Combined user story (simplified)
What if the structured prompt needs modifications?
To be continued: breaking the “expert-only” barrier
Q & A
Once a team adopts AI coding assistants, the first gains show up at the<br>individual level: one developer can draft, modify, and refactor code<br>much faster than before.<br>But delivery speed is rarely limited by typing.<br>When you look at the full delivery lifecycle, from requirements through<br>release, new friction appears:
Ambiguous requirements become code quickly, and misunderstandings scale with them.
Reviews have to process more change, and inconsistency becomes easier to introduce.
More integration and testing issues surface because “generated” doesn't mean “aligned.”
Production risk is harder to reason about when the volume of change rises.
So yes, local speed improves. But that doesn't automatically<br>translate into system-level throughput. It's like buying a Ferrari and driving it on muddy roads: the engine is<br>powerful, but your arrival time is determined by road conditions and<br>traffic. In our experience, the real question isn't “How do we generate more code?” It's<br>how do we make AI-generated changes governable, reviewable, and reusable,<br>so teams get faster and safer?
That led our Thoughtworks internal IT teams (Global IT Services) to a<br>method and workflow we now call Structured Prompt-Driven Development (SPDD).<br>SPDD aims to turn AI assistance from personal efficiency into an organization-level<br>capability that scales, without trading away quality.
Prompts as First-Class Delivery Artifacts
What is SPDD?
Structured Prompt-Driven Development (SPDD) is an engineering method<br>that treats prompts as first-class delivery artifacts.
Instead of relying on ad hoc chats, SPDD turns prompts into assets that<br>can be: version controlled, reviewed, reused, and improved over time.<br>Teams use structured prompts to capture requirements, domain language,<br>design intent, constraints, and a task breakdown. Then the LLM generates<br>code within a defined boundary, so output becomes more predictable and<br>easier to validate.
It has two core components
The REASONS Canvas
The REASONS Canvas is a structure for generating prompts. It forces<br>clarity around requirements, domain model, solution approach, system<br>structure, task decomposition, reusable norms, and safeguards. So the<br>LLM is guided by intent, not guesswork.
The REASONS Canvas is a seven-part structure that guides a prompt from<br>intent → design → execution → governance.
Abstract parts (intent & design)
R — Requirements: What problem are we solving, and what is DoD?
E — Entities: Domain entities and relationships.
A — Approach: The strategy of how we'll meet the requirements.
S — Structure: Where the change fits in the system;...