Coding agents write code faster than anyone can explain to them what the product is. So they guess, and the guesses ship. That problem is laid out in AI is writing code for products it doesn’t understand, and why spec-driven development does not solve it in SDD describes the change, not the product.

Today we are releasing pdd-kit, an open-source implementation of Product-Driven Development (PDD). It gives your agent, and your team, one definition of the product to build from and check against.

What you get

A Product Model. A product-model/ folder of Markdown files that says what your product does: who it serves, where they reach it, what it keeps, what it can do, and which rules must stay true. It lives beside the code and changes in the same pull requests. It defines the product, not the implementation, so colors, layout and frameworks stay yours to choose.

Three agent skills for Claude Code, Codex, Gemini CLI and more:

• map reads an existing codebase and drafts the model from it.
• ideate decides the next change with you and writes only what you approve.
• verify checks the code against the model and works through the gaps with you until the two agree, or until something blocks it.

A CLI. pdd-kit lint checks the model's files. pdd-kit view opens the model as a local report that follows your edits.

Blueprints. Reviewed Product Models of common products in a public catalog. Pull one into an empty directory and hand it to your agent.

Every Blueprint is tested the same way: a fresh agent gets the model and the words "build this", and has to ship a working product.

One loop, run on every change

ideate → implement ⇄ verify
  ▲                     │
  └──── next change ────┘

implement: your agent, your way, in phases

Ideate and verify with pdd-kit. Your own agent implements, your way.

Get started

npx @itai-gendler/pdd-kit install

Then start from where you are: existing code, an idea, or a Blueprint.

To see a real model first, run npx @itai-gendler/pdd-kit view itai-gendler/pdd-kit. pdd-kit is developed with pdd-kit, and that command opens its own Product Model.

It is MIT licensed and local-first: no account, no hosted service, nothing to buy. The skills read your code and never run it.

What comes next

This is an early release, and the open issues are the roadmap:

• More Blueprints across different kinds of product, such as a storefront, a booking app, a project tracker and an API service.
• Review model changes as product changes. A compare mode in the report that shows what a branch changes in the product, not just in the Markdown.
• Products that don’t fit one repository. One product spread across several repositories, and several products in one repository.
• KPIs in the model, so it can say how the product's value is measured.
• GitHub issues linked to the model, so tracked work keeps its product context.
• Talk to your agent from the report, without switching back to the terminal.

Try it on a repository you know well and compare the model it drafts with the one in your head. Where they disagree, and where pdd-kit gets in your way, open an issue. Contributions, Blueprints included, are welcome through pull requests on itai-gendler/pdd-kit.

Spec-driven development works. If you use OpenSpec, spec-kit or Kiro, you know the shape: describe the change before you build it, plan it, break it into tasks, and let the agent work against a written target instead of one sentence in a chat. This post is not an argument against it. It is about where it falls short, and what it does not cover properly: the product.

What these tools keep

None of them throws the work away when it ships.

• OpenSpec keeps openspec/specs/ as the source of truth for how the system behaves today. Each change carries a proposal, a design, tasks, and delta specs. Archiving merges the deltas into the main specs and files the rest under changes/archive/.
• spec-kit gives each feature its own directory with spec.md, plan.md and tasks.md, plus a project constitution. Whether those files stay living or become history is left to each team.
• Kiro writes requirements.md, design.md and tasks.md for each feature, and keeps product.md, tech.md and structure.md as steering files that every conversation reads.

So the files stay. The question is what they hold.

The product gets mixed with the build

What usually steers these frameworks is the technical side: the design, the plan and the tasks. The product requirements are rarely discussed in full, and what is covered ends up mixed into the technical artifacts the framework produces.

And the product never sits in one place. It is spread across feature and change folders, so nothing describes the whole of it.

That matters. When the two are mixed, you can no longer tell what the product must do from how it happens to be built today.

The specs drift

A spec is only as true as the last time someone updated it. A hotfix, a refactor, a change made outside the workflow, and it quietly stops matching the code. spec-kit's own docs name the risk: silent divergence.

Keeping them current is a chore nobody owns. Every change means touching the proposal, the design and the specs, and the more files pile up, the more work each change costs. So it gets skipped, and the next agent builds from a spec that is no longer true.

Splitting the product from the implementation changes that. The product lives in one place, so a product decision is written once, not restated in every spec it touches. A purely technical change, like a refactor or a new library, never has to touch it. And that one record serves every change, every agent and every person on the team.

Draw the line

PDD draws the line between product and implementation, in one place. A Product Model holds what any rebuild of the product would have to keep, and nothing a rebuild is free to change:

Because it is kept apart, the model can also be checked against the code on every change, so drift shows up when it happens instead of a year later.

SDD describes the change. PDD describes the product.

Spec-driven development is good at what it was built for: planning and building a change. It was never meant to hold the product. Give the product a home of its own, kept apart from the technical artifacts and checked against the code, and your specs can go back to doing what they do best: describing the build.

Nothing else has to move. Keep the spec-driven framework you use, or use none at all. The product just gets a place of its own.

For the problem this comes from, read AI is writing code for products it doesn’t understand.

Coding agents can read code, tests, and tickets. Without a reliable product definition, they still have to reconstruct what the product is supposed to be.

We are giving AI control of the codebase without giving it a reliable definition of the product.

Ask a coding agent to change what happens when a free trial ends. Should the workspace become read-only? Is there a grace period? Can users export their data? Do scheduled actions keep running? What happens to invited teammates?

The agent can find the relevant code and tests. What it cannot find is which of those answers represent the product's current intent.

Evidence is not a product definition

The answers are usually scattered across the pricing page, an old launch ticket, billing and permission logic, tests, a support playbook, and somebody's memory. Every source is useful. None defines the current product as a whole.

Trial expiration crosses billing, permissions, collaboration, data retention, exports, and automations. Each system can behave consistently while producing a customer experience nobody deliberately defined.

The agent does not discover the product. It reconstructs one, filling every gap with a product decision nobody explicitly made—then writes code as if that reconstruction had been approved.

Code is the closest evidence of what shipped, but it cannot explain what the behavior means. A temporary workaround looks much like a deliberate business rule. Tests confirm what happens, not why it must happen.

Better documentation is not enough

Wikis, design documents, and decision logs are good at authoring. Their shared weakness is that they cannot tell us when they have become false. When behavior changes underneath a document, nothing fails; it quietly stops being true.

The problem is not that a product definition is hard to write. The problem is that a written product definition has no way of knowing it is now wrong.

Agents turn ambiguity into action

People reconstruct the product from the same fragments. Coding agents simply do it faster—and then act on the reconstruction.

More context helps it see more evidence. It does not create the missing decision that only lived in a conversation or distinguish an intentional constraint from a historical accident.

The result can be reasonable code for a subtly incorrect product. Reviewers catch some of it. The rest ships.

What a durable product definition requires

Simply documenting the product more clearly is not enough. A durable product definition must be:

• Current and centralized: one shared definition of how the product should work, updated as the product changes.
• Versioned with the code: changing in the same history as implementation.
• Readable by people and agents: structured without becoming opaque.
• Organized around product definition: who it serves, where they reach it, what it keeps, what it can do, and which rules must stay true.
• Tied to evidence: making drift visible when implementation and intent diverge.

Call it a Product Model or a product definition. The name matters less than the property: it cannot quietly become fiction.

With that definition, people can understand the current product without archaeology, and agents can build from explicit decisions instead of inventing the missing ones.

Over the past few weeks, I have been working on an open standard for product definitions and an open-source implementation of it. I am planning to release them soon.

Where does your product definition live today? Have you run into this problem? How does your organization handle it?