PRD-driven development

In the past few weeks, we have been able to churn out features and production-grade code using Claude. One of the ideas that helped us ship with confidence is a process we call PRD-driven development.

The issue with vibecoding without a plan is that the layers of changes made to a project compound into exponential tech debt. This is a real problem with AI-driven development. A junior engineer can ship a complex TCP proxy and be happy with it the moment it works — but they have no idea what is happening behind the scenes, or how they arrived at the solution. The agent has the same problem in reverse: it will keep editing a codebase it does not actually understand, and each round of edits buries the original intent a little deeper.

To tackle that, we built a process where we generate a PRD for every task. Every time the agent updates the code, it also updates the PRD to reflect how it arrived at the solution. The PRD is not a one-time spec; it is a living document that drifts forward with the code. When something breaks six weeks later, the why is sitting right next to the what.

The payoff is twofold. First, you accumulate documentation as a side effect of building, which is exactly when documentation is cheapest to write and most accurate. Second, the PRD becomes context for the next prompt — the agent reads what it decided last time before deciding again, which makes the work far less likely to contradict itself. In principle, project understanding compounds rather than decays. Both the developer and the agent end up with more context than they started with.