Dmitry Yurkin

I see product memory as a product model, maintained separately from implementation. In my experience, that works better than letting the coding agent curate its own product memory. The model is a graph of small, connected specs: requirements capturing intent, UI specs, API operations and data entities. A person initiates a change with an intent or feature request. An analyst agent sees both model and code, but its editing scope is the model. Agents then help with three steps: update the model, bring the code into line with it, and verify the implementation against the model. We've built this separation into Reqode. The coding agent reads the model through MCP and can report inconsistencies or other issues as Findings through the same interface, without editing the specifications.

In our experience, living specs work better as a versioned source of truth for how the product should behave. A change proposal describes the delta, while the living specs describe the resulting system. Revision history makes changes easier to manage and helps the agent understand exactly what changed. Verifying against incremental specs alone is harder because they leave the behavior that should remain unchanged to be reconstructed. With a maintained current specification, we can verify the affected code against that source of truth after each change. That's the approach we've built into Reqode.

I'd scope the spec to the behavior being changed and the contracts it must preserve. In your caching example, a rule such as "reads may be 30 seconds stale, but a successful write invalidates the entry" gives the agent a boundary while leaving implementation choices open. Decisions that change those boundaries need review and a corresponding specification update. In Reqode, we've made the change itself the handoff: a Change Request groups affected specification revisions, and the coding agent retrieves the relevant context through MCP. The task can stay short because it points to the agreed specifications.