PDD (Prompt Driven Development): .prompt Files as Source, Generated Code as Output
Prompt Driven Development (PDD): The Last Programming Language™. Prompt files are source; code is generated output.
At a glance
- What is it?
- PDD is a Python CLI that treats .prompt files as the source language and Python, TypeScript or Go as compiled artifacts. The README describes an ambitious agentic workflow, but the material here does not let you verify how well it holds up on a real repository.
- Who is it for?
- PDD is worth a look if your team already writes long-lived prompts and you want those prompts under version control as the primary artifact, with code treated as a build product. Skip it if you need a single deterministic compiler you can reason about from a spec sheet: the material here describes LLM-backed agentic commands, multiple workflow lengths (13, 15, 18 steps), and a routing policy document, which is a lot of moving parts to accept on trust.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 7 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem PDD claims: prompt files as the durable source of truth
Most AI coding tools sit beside your repository. You keep writing Python or TypeScript by hand and ask a model to fill in gaps. PDD inverts that arrangement. The README states that .prompt files are the human-authored source language, and that Python, TypeScript, Go and other traditional languages are generated artifacts. Code stays real and reviewable, but it stops being the primary source of truth. The intended audience is a team that has already accepted long prompts as a real asset and now wants them versioned, linted and tested like source. The README frames this as a specific sense of the phrase "the last programming language": you author intent, constraints, examples and tests once, then compile that into whichever implementation language a project needs. That is a narrower and more defensible claim than it first appears. It does not say code disappears. It says the diff you argue about in review is a prompt diff.
How the compile step is described: prompts in, language artifacts out
The README does not describe a tokenizer, an AST or a deterministic compiler. What it describes is a set of agentic commands, each with a numbered workflow, that read a prompt or an issue and produce or modify code. The visible list is: pdd change for feature requests at 13 steps, pdd split for diagnosing and splitting large dev units at 15 steps, pdd generate for producing architecture.json from a PRD issue at 11 steps, and pdd test for UI tests at 18 steps with exploratory testing, contract validation and accessibility audits. pdd bug and pdd fix are described as a pair. The README gives an explicit routing rule: if an issue reports a current runtime symptom (stack trace, failing command, wrong CLI or API output, regression, crash), run pdd bug first and then pdd fix, so the failure is reproduced and covered by a behavioral test. Use pdd change only when there is an explicit source-truth or spec change with no runtime failure to reproduce, followed by sync. That routing rule is the most concrete design decision in the material, and it is the part I would read twice before trusting the rest. It means the tool's own author considers the ordering load-bearing, not cosmetic.
Installation: uv, pdd setup, and a web UI on port 9876
The recommended install path is uv. The README gives the commands: curl -LsSf https://astral.sh/uv/install.sh | sh, then uv tool install pdd-cli. Verify with pdd --version. The README states that this method handles the PDD_PATH environment variable and isolates PDD from other Python packages. After that, pdd setup detects agentic CLI tools, scans for API keys, configures models and seeds local configuration files. If you skip it, the README says the CLI shows a reminder banner the first time you run another command. Then pdd connect launches a web interface at localhost:9876 for implementing GitHub issues, generating and testing code from prompts, and managing projects visually. On macOS the README lists prerequisites: xcode-select --install, Homebrew, and Python 3.12 or higher via brew install python, noting that recent macOS versions no longer ship Python. The README does not document the contents of the seeded config files, the names of the API key environment variables, or how model selection is persisted. If you need to provision this in CI without a human running pdd setup, that gap matters and the material here does not close it.
The quality gates are the part worth reading closely
PDD ships more linting and coverage machinery than the top of the README suggests. There is a prompt lint document covering vague terms, vocabulary and optional LLM review. There is a deterministic contract-section lint covering <contract_rules>, <coverage>, waivers and a story-level ## Covers section. There is a rule-to-story coverage matrix behind pdd checkup coverage, with a @pytest.mark.story regression marker and a per-story has_regression_test dimension. There is a prompt source-set quality gate with a documented JSON schema, pdd.prompt_source_set_report.v1, including a per-finding clarification signal (requires_clarification and clarification_reason). And there is a bounded, non-interactive prompt repair path for when a prompt source-set checkup fails. Taken together, this is the shape of a system that expects prompts to rot and provides tooling to detect the rot. That is a more honest position than claiming prompts stay correct on their own. The cost is surface area: a new contributor has to learn the checkup commands, the schema and the waiver mechanism before they can tell whether a change is acceptable.
Where the README does not answer: determinism, cost and failure modes
The README says the whitepaper includes benchmarks and case studies, and links to it. It does not reproduce any number in the README itself. So there is no way, from this material, to state how often pdd change produces code that passes the generated tests, how many tokens a 13-step workflow consumes, or what happens when the agentic CLI it routes to is unavailable or rate-limited. The routing policy document is referenced but its contents are not shown. The failure mode I would want answered first is the one the README's own framing implies: if code is generated output, then a prompt edit silently changes many files, and the review surface becomes the prompt plus a large generated diff. The README does not describe how generated artifacts are marked, whether they are committed, or how a reviewer distinguishes a regenerated file from a hand-edited one. That is not a small omission. Until it is answered, the claim that code stays reviewable rests on a convention the documentation does not state.
Compared with a deterministic scaffolder like Cookiecutter
The nearest thing to compare PDD against is not another AI coding assistant. It is a template engine such as Cookiecutter, or a code generation tool driven by a schema. The difference in approach is the whole argument. Cookiecutter takes a template plus variables and produces files by string substitution. Run it twice with the same inputs and you get byte-identical output. You can diff the result, pin the template version and reason about upgrades mechanically. PDD takes a prompt plus an LLM-backed agentic workflow and produces files whose content is not reproducible from the inputs alone. That buys you the ability to express intent in prose and to handle cases a template cannot, such as generating a behavioral test from a bug report. It costs you determinism. If your project needs generated code that is identical across machines and CI runs, a template engine is the correct tool and PDD is the wrong one. PDD is aimed at the case where the input is genuinely ambiguous and a model's judgement is part of the value.
Maintenance, versioning and the MIT licence
The repository is MIT licensed, which permits commercial use and modification provided the licence and copyright notice are retained. That is a permissive default and the README does not add terms on top of it. Two things are worth separating. First, the CLI itself: releases are frequent and version numbers are at v0.0.x, with v0.0.310 dated 2026-09-09, v0.0.309 on 2026-07-26 and v0.0.308 on 2026-07-24. The zero-zero prefix is a factual signal about API stability, not a judgement. Expect CLI flags and workflow step counts to move. Second, the generated code: the licence of PDD does not determine the licence of what you generate, and the README does not address provenance or training-data questions for model output. If you are generating code for a commercial product, that is a question for your own counsel, not something the MIT text resolves. The maintenance cost you can actually estimate from this material is the prompt corpus itself: every checkup command, waiver and coverage marker is another artifact your team has to keep current as the tool's schemas evolve.
Editorial conclusion
PDD is worth a look if your team already writes long-lived prompts and you want those prompts under version control as the primary artifact, with code treated as a build product. Skip it if you need a single deterministic compiler you can reason about from a spec sheet: the material here describes LLM-backed agentic commands, multiple workflow lengths (13, 15, 18 steps), and a routing policy document, which is a lot of moving parts to accept on trust. Before adopting, run pdd setup and then pdd bug against one issue with a reproducible stack trace, and check whether the generated behavioral test actually fails for the right reason before pdd fix makes it pass.
Community notes