Specs Written From Memory

A product manager writes a spec. Support tickets read, two customers interviewed, the friction clear. An objective, three outcomes, a couple of edge cases. The spec is good. It gets approved.

Three weeks later, the engineer assigned to ship it sends a Slack message:

"Hey — most of this already exists in the export pipeline. Are we re-doing it, or extending it?"

The PM doesn't know. They drafted the spec in a context where this part of the product was a concept, not a codebase. The spec is technically correct, but it's answering the wrong question. The right question wasn't "what should we build?" — it was "what already exists, and what changes about it?"

This pattern is older than AI. PMs have always drafted specs without a complete picture of the surface area they're touching. The traditional fix was discovery — a few days of back-and-forth with engineering before the spec hardens, mapping intent onto the existing product surface.

What's changed is that the time between spec and executable artifact has collapsed. An approved spec used to sit in a backlog for weeks before anyone wrote a line of code. The team had time to discover. Now an approved spec can be on its way to a PR within hours. The discovery phase didn't get more efficient — it got skipped.

So a spec that's mostly correct in product terms but wrong about the existing surface area gets converted into code, and the mismatch becomes much harder to unwind.

The deeper move here isn't about specs being more rigorous. It's about where the rigor comes from.

A traditional rigorous spec asks the PM to think harder up front. List more outcomes. Define more edge cases. Anticipate more failure modes. This works — to a point. The PM has finite knowledge, and the parts they don't know are the parts that bite them.

A grounded spec asks something different. It interrogates the existing product — not in the implementation sense (how to build it; that's the engineer's job) but in the existence sense. Four questions a spec written from memory can't answer:

• What already exists? Is there a place this feature would live — code that already does part of it?
• What changes? Not how to refactor it. Only that this is an edit to something, not a thing appearing from nothing.
• What must not break? Which shipped decision does this outcome sit next to?
• What did we already decide here? If three features touched this surface, they settled something — find out what.

Code is not the source of truth — intent is. But code is the most reliable record of which intents the team has already committed to. Ignoring it isn't ignoring "what's there." It's ignoring what the team already decided.

Those questions don't require the PM to think harder. They require them to read evidence they didn't write. The same move a support agent makes when they check the customer's history before drafting a reply — answer grounded in what already exists, not what the responder personally remembers.

This does not mean the PM needs to become the implementation owner. A grounded spec should not tell the engineer how to refactor the export pipeline or which abstraction to use. It should know enough to avoid pretending the export pipeline does not exist.

The risk in writing a spec from memory isn't that the spec is wrong. It's that the spec is unverifiable until it ships. The PM has no way to know whether outcome #2 is already partially shipped, or whether constraint #4 is contradicted by a decision the team made in last quarter's refactor. The cost of finding out used to be a meeting. The cost of finding out now is a half-built feature.

The version of this that worries me most isn't a spec written by a careless PM. It's a spec written by a good PM who has done all their qualitative work — interviews, friction logs, north-star alignment — and whose only missing input is the one they were never expected to have: what the code already says about their question.

We've been treating that gap as a soft skill. "Talk to your engineers more." That works in small teams. It does not scale to AI-agent-paced execution. The gap has to close at the artifact level — in the spec itself, drafted against what the product already decided, not what the author remembers.

That's the bet behind Implementation Context: Pathmode reads your repository while you draft, so the spec starts from what already exists instead of from what you guessed.

The hard part is not only tooling. The hard part is acknowledging what specs are for, in a world where they're load-bearing for both humans and agents.

A spec used to be a document. Now it's a contract. The contract has to be honest about what it's a contract against — not just the desired future state, but the existing present state that the future has to grow out of.

A spec that doesn't know what exists isn't really intent. It's a wish.

The shift coming for product work isn't going to be about AI writing better specs. It's going to be about specs that know enough to be worth writing in the first place.