There's a document sitting in your Notion workspace right now. It describes a feature. A PM wrote it three weeks ago. An engineer read it once, asked four clarifying questions in Slack, then built something adjacent to what was described.
The spec was a starting point. Everyone knew that. The real product definition happened in the conversation around the spec—in standups, in Slack threads, in code review comments. The document was a catalyst, not a contract.
That worked when humans were on both sides of the handoff.
It breaks completely when one side is an AI agent.
The Translation Layer is Compressing
For years, the PM sat between customer needs and engineering capacity. The workflow was predictable:
- Talk to customers.
- Synthesize problems into a spec.
- Hand the spec to engineers.
- Answer questions when the spec was unclear.
Step 4 was where the real work happened. The spec was deliberately incomplete—a compression of a complex problem into a readable narrative. Engineers decompressed it through conversation. The PM's value wasn't in the document. It was in being available to clarify it.
Shubham Saboo captured this shift well: when agents can take a well-formed problem and produce working code, the PM is no longer translating for engineers. They're forming intent clearly enough that agents can act on it directly.
The spec stops being a conversation starter. It becomes the product definition itself.
Why This Changes Everything
An agent doesn't walk over to your desk. It doesn't ask "what did you mean by 'handle errors gracefully'?" It reads the spec, interprets it literally, and executes.
This means every gap in the spec becomes a gap in the product. Every ambiguity becomes an assumption the agent makes silently. Every missing edge case becomes a production incident waiting to happen.
| What the Spec Says | What a Human Engineer Does | What an Agent Does |
|---|---|---|
| "Add a checkout flow" | Asks 20 clarifying questions | Builds the happy path, guesses the rest |
| "Handle errors gracefully" | Looks at existing patterns, asks QA | Adds a try/catch and a generic message |
| (nothing about rate limiting) | Probably adds it from experience | Doesn't add it—it wasn't in the spec |
The human decompresses ambiguity through context and judgment. The agent fills it with the most statistically likely completion. These are not the same thing.
This is why Jira tickets fail AI agents. The ticket was designed to trigger a conversation. The agent treats it as a complete instruction set.
The Spec as Contract
When the spec is the product definition—not a precursor to it—it needs to carry the weight of a contract. Not more prose. More structure.
A narrative spec describes what to build. A contract spec defines what success looks like:
- Objectives replace feature descriptions. "Reduce cart abandonment from 23% to 15%" instead of "improve checkout UX."
- Constraints are explicit. "Must work without JavaScript" isn't tribal knowledge—it's in the spec.
- Edge cases are enumerated upfront. "Payment declined → show retry with alternative method" isn't discovered in QA.
- Success criteria are verifiable. The team—and the agent—knows what "done" means before the first line of code.
This is the difference between a document that says "build this" and one that says "here is the contract the output must satisfy." The first produces code. The second produces the right code.
Intent Formation is the New Craft
This is not a demotion of the PM role. It's an elevation.
Writing a handoff document is a communication skill. Forming clear intent—defining preconditions, success criteria, constraints, and edge cases with enough precision that a machine can execute against them—is an engineering discipline.
Clarity is harder than verbosity. Precision is harder than prose. Enumerating what shouldn't happen is harder than describing what should.
The craft that used to live in implementation—the careful thinking that engineers did while writing code—now needs to happen before the agent starts. Someone has to do that thinking. Increasingly, it's the PM, the designer, and the engineer working together to form intent, not to write code.
We explored this in The Disappearing Middle: when the middle collapses, the work concentrates at the ends. The spec is the front end of that equation.
The Tooling Gap
If the spec is becoming the highest-leverage artifact your team produces, then the tooling for creating specs matters more than ever.
Most teams today use:
- Docs (Notion, Google Docs) for specs—unstructured, unversioned, not machine-readable.
- Diagramming tools (FigJam, Miro) for journey maps—visual but disconnected from execution.
- Task trackers (Jira, Linear) for work coordination—designed for humans, opaque to agents.
None of these produce structured, machine-readable intent. You end up with a Google Doc that a PM reads to an agent through a prompt. The spec exists, but it can't be consumed programmatically. It can't be verified against. It can't be versioned alongside the code it defines.
That's the gap the Intent Layer fills—not another doc tool, but a system that makes the spec a first-class artifact in your development workflow: structured, versioned, and executable.
The spec is becoming the product. Not because documents suddenly matter more, but because the conversation that used to fill the gaps no longer happens.
The question is no longer who writes the code. It's who defines the contract the code must fulfill.
Don't Just Write Code. Define Intent.
Turn user friction into structured Intent Specs that drive your AI agents.
Get Started for Free