Prompt Driven Development (PDD) A Manifesto Against Comfortable Guessing

We learned TDD because code lies. Or more precisely: code tells you everything you allow it to tell.

Now we have LLMs — and they will still tell you a coherent story even when the premise is already wrong.

Time for a small process hack that doesn’t feel like a hack.

The Scene

You’re sitting there. Coffee. Tabs. A timeline full of “AI will replace developers.”

You enter a prompt. The model delivers code. The code looks good.

And that is exactly why it’s dangerous.

Because LLMs are polite. They rarely contradict you. They deliver. They fill gaps.

And gaps are not romantic in project management. Gaps are budget.

“You wanted a solution. You got an answer. That is not the same thing.”

What PDD Is (and What It Is Not)

Prompt Driven Development (PDD) treats prompts as verifiable specifications.

Not as wish lists. Not as chat. But as a contract that must be measured against reality.

PDD Is Not

• not “prompt engineering” (more words, better magic)


• not “the LLM writes my code” (delegation without liability)


• not “generate tests and hope”


• not a workflow for buzzword pitches

PDD Is

• specification first — as a prompt


• tests as referees (not decoration)


• iteration on the prompt until it becomes measurable


• code only when “done” can be defined

The Loop

Classic (and unfortunately common):

Prompt → Code → Fix → More fixes → “Why is this taking so long?”

PDD reverses the order:

• Prompt (as specification)


• Test (as a reality sensor)


• Prompt (iteration: precision instead of poetry)


• Code (implementation inside the test cage)

If you cannot measure the system, you do not control it.

You are only telling a story about control.

The Five Theses (Manifest)

1) Prompts Are Artifacts

A prompt is not a conversation. It is a document. Versionable. Reviewable. Worth criticizing.

If your prompt disappears in chat history, it effectively does not exist in the project.

2) Unclarity Is the Real Bug

When something goes wrong, it is rarely “just a bug.”

Often it is a fog word.

“Fast.” “Intuitive.” “Simple.” — these words are like smoke grenades, except without an explosion, but with sprint meetings.

3) Tests Validate the Prompt, Not Just the Code

If a test fails, the first question is not “Who broke this?”

It is: “What did we actually demand?”

4) LLMs Are Co-Authors, Not Oracles

The model delivers possibilities. You deliver responsibility.

PDD is the method that separates these roles instead of romantically blending them.

5) First the Contract, Then the Implementation

PDD is a return to something old-fashioned:

a Definition of Done that can be executed.

“If my prompt is not testable, it is not a specification.”

Practice: How a Prompt Becomes Testable

A testable prompt specifies:

• goal (why does the feature exist?)


• input/output (what data goes in, what comes out?)


• constraints (performance, security, offline, KISS/YAGNI)


• edge cases (how does it fail correctly?)


• non-goals (what is deliberately not built?)


• acceptance criteria (measurable: what does ‘done’ mean?)

If you only write “just do it,” you will get “just do it” quality back.

And then you will argue for three days about results instead of two hours about requirements.

Anti-Patterns (You Will Recognize Them)

• The novel prompt: too long, too vague, too much world — and not a single hard edge.


• The good-vibes test: “should feel good” — nice, but not executable.


• Tool fetishism: new models, new plugins — but no Definition of Done.


• The hallucination deal: “it’ll probably be right” — until production disagrees.

Why This Matters Right Now

Because AI does not only make code faster.

It also makes failure faster — if we continue to specify in fog.

PDD is not a religion. It is a guardrail.

And guardrails are not sexy. They are what stop you from pushing a “small change” to production at 11:48 pm.

“You want speed? Then stop investing in unclarity.”

Closing

If your prompt is not testable, it is not a specification.

And if you have no specification, you are not building faster — you are just building into emptiness sooner.

If you want to try this: take a mini feature, write the prompt like a contract,

let tests emerge, iterate on the prompt, only then write code.

One round. Then another.

And suddenly “AI development” feels less like gambling.

📌 Publication Metadata

Original Publication:

January 13, 2026

Author: Benjamin Lam (blame76)

Categories: Prompt-Driven Development (PDD)

Original URL: https://benjamin-lam.de/2026/01/13/prompt-driven-development-pdd/

Translated with ChatGPT