The PDAID Method
Prompt-Driven AI Development
PDAID — Prompt-Driven AI Development — is a behaviour-first method for building software with AI through small, controlled and testable increments.
AI can implement changes quickly, but speed does not remove the need to decide what should be built, how it should behave, what boundaries it must respect or how the result will be verified. PDAID separates those decisions from implementation so that each change begins from an accepted description of the work.
The method is not a collection of clever prompts. It is a repeatable development cycle that moves from purpose and behaviour through clarification, implementation, testing and a preserved working baseline.
Behaviour-first does not mean Behaviour comes first.
Purpose establishes why an increment is needed. Behaviour then defines what must happen before implementation choices are made.
The seven phases
From intent to a stable working baseline.
Each PDAID increment passes through seven phases in a fixed order. The early phases establish the decisions; Build implements them; Test & Correct verifies the result; Commit & Maintain preserves an understood baseline for what comes next.
-
01
Purpose
Define the high-level useful outcome of the current increment and why it is needed.
Purpose establishes direction without prematurely deciding detailed behaviour or implementation.
-
02
Behaviour
Define what should happen from the user or system point of view in observable, testable terms.
Describe outcomes before implementation details.
-
03
Clarifications
Resolve ambiguities, assumptions, edge cases and missing decisions before the AI is allowed to infer them.
The result should contain accepted decisions, not unanswered questions.
-
04
Context & Constraints
Describe the relevant existing project state and define the boundaries the implementation must respect.
Context explains where the change belongs. Constraints limit what the AI is authorised to change.
-
05
Build
Assemble the accepted outputs from the earlier phases into one controlled implementation prompt.
The accepted decisions are implemented without silently expanding or reinterpreting the work.
-
06
Test & Correct
Test the implementation against the accepted Behaviour, Clarifications and relevant Constraints.
When something is wrong, correct the smallest understood difference and then retest.
-
07
Commit & Maintain
Review and preserve the tested increment as a dependable baseline before the next increment begins.
Any maintenance remains narrowly bounded and must preserve accepted Behaviour.
Division of responsibility
The human decides. The AI implements.
PDAID separates decisions about the software from the act of implementing them. AI can suggest options and produce code quickly, but those suggestions do not become accepted decisions until the person directing the work has reviewed and accepted them.
The human is responsible for
- deciding why the increment is needed
- accepting the required Behaviour
- resolving important ambiguities
- providing accurate Context
- establishing Constraints
- reviewing and testing the result
- deciding whether the result is stable enough to preserve or release
The AI is responsible for
- implementing accepted decisions within the established boundaries
- explaining technical options where useful
- making routine implementation choices that do not alter accepted decisions
AI suggestions are not decisions until the human accepts them.
Control the change
Build the smallest useful increment.
PDAID does not aim for the smallest possible change. It aims for the smallest change that produces a useful, coherent result and can still be understood, tested and recovered if something goes wrong.
Keep the outcome coherent
An increment should deliver one understandable piece of behaviour rather than fragmenting a single useful result into artificial steps.
Keep scope stable
Once the increment reaches Build, Test & Correct and Commit & Maintain, unrelated improvements and new ideas should not be allowed to expand its accepted scope.
Prefer reversible decisions
Where several reasonable approaches exist, prefer choices that can be changed later without unnecessary disruption.
Preserve progress
Every completed cycle should leave something dependable behind.
A completed PDAID increment should leave the project in an understood, tested and recoverable state. That stable baseline becomes the starting point for the next increment.
Version control provides the technical checkpoint, but the commit is only meaningful after the accepted Behaviour has been verified and relevant Constraints still hold. That distinction is worked through in always have something that works to go back to.
Future work should begin from a known working state, not from an accumulation of partially understood changes.
Confidence comes from evidence
AI saying it works is not proof that it works.
Testing in PDAID is tied to accepted Behaviour, Clarifications and Constraints. Confidence grows from observable evidence that the result does what was agreed, not from the AI describing its own work as complete, correct, secure or production-ready.
The amount of evidence required depends on the risk. A small personal utility and software handling security, privacy, financial transactions, medical decisions or safety-critical behaviour do not require the same standard of review.
Where the risk exceeds your current knowledge, responsible development may mean seeking specialist review rather than asking the AI to provide more reassurance. When to involve a professional and why a confident claim is not evidence cover both halves of this in more detail.
PDAID does not remove judgement from software development. It gives that judgement a repeatable structure.