Spec-Driven Development Is Live — Here's What Changes for PMs This Sprint
The Workflow That Shipped This Week
A PM at Notion opens a task doc, writes four sentences, attaches a screenshot, and @mentions Codex through an internal system called Boxy. Twenty minutes later she has a PR, UI verification screenshots, and a preview URL. This is not a sandbox. It is how Notion ships. In a different building, Jarred Sumner pointed AI agents at Bun and had them rewrite 960,000 lines from Zig to Rust in 6 days, passing the Linux test suites. The common constraint in both stories: the human owned architectural judgment, the agent owned execution speed. Separate the thing being pitched ("agents ship features") from the thing being done ("a human with a clear spec delegates bounded work").
What the Spec Must Contain
The four sentences that actually work name the user problem, the success condition, the constraints the agent should not violate, and the edge cases that matter. Notion keeps Markdown spec files in the repo written in plain English with code pointers and verification steps. Those specs are what the agent reads. They are the source of truth now, not the code. Vague requirements used to produce a conversation with an engineer. They now produce a shipped feature that is wrong in 20 minutes.
The PM skill of thinking clearly about what a feature should do became directly executable. Spec quality now determines shipping velocity in a measurable way.
The Infrastructure Dependency Most Teams Miss
Notion is cutting CI time to 25% of current because agents idle during CI. The arithmetic is blunt. A 60-minute CI run means one iteration per hour. A 3-minute run means 20x more iterations. CI investment stops being a developer-happiness line item and becomes a product-velocity line item. That is the framing PMs should bring to the prioritization meeting.
The Maintenance Question Nobody's Answered Yet
Here is where teams tell themselves a comforting story. Notion reports specs producing shippable code at high rates. DevOps research shows AI-assisted code carries higher flaw density than legacy code, and the per-commit maintenance cost of merged AI work is a metric almost nobody tracks. The honest diagnostic is time-to-second-touch: how long between a merge and the next change to the same file for the same reason. If that number trends down while AI commit volume trends up, the velocity chart is debt wearing a speed costume.
Where This Works vs. Where It Breaks
The 2x2 to take into Monday's planning. One axis: is the feature bounded (one screen, known data model, clear success state) or unbounded (billing, auth, anything litigable). Other axis: does the team have review infrastructure (tests, staging, rollback) to catch confident-but-wrong output. Bounded plus review infrastructure is the only cell where four-sentence specs earn their keep. Every other cell ships bugs to production at machine speed.
What to do
Identify 3 features on your current roadmap that are bounded (single screen, known data model, clear success state) and pilot spec-driven development on them this sprint
Add three fields to your PRD template: verification steps, code pointers to existing patterns, and acceptance screenshots — model after Notion's Markdown spec format
Propose a CI speed improvement initiative to your eng lead, framed as agent productivity multiplier (cite: 20x iteration gain if CI drops from 60min to 3min)
Instrument time-to-second-touch on AI-assisted commits before the next planning cycle