2026-09-21 · Note
The AI-native SDLC is really a product management playbook
Anthropic wrote a framework for engineering leaders. Read as a PM, it's a specification for what product management becomes when agents write the code.
Anthropic recently published their AI-native SDLC playbook. It's addressed to engineering leaders — how to restructure development when agents can write most of the code faster than humans can review it.
I read it as a PM. It reads differently from that seat.
The document is a specification for what product management becomes over the next few years. Anthropic didn't set out to write that, but they did.
intent.md is not eliminating PMs. It's raising the bar.
The proto-spec — where the originator writes their own version of what they want before anyone in product formalises it — is the interesting handoff. In traditional cycles, half a PM's job is translating vague requests from stakeholders into something engineers can commit to. That translation phase disappears. Good.
What replaces it is editing. The originator ships a rough intent.md; the PM's job is to sharpen it, catch the wrong problem framing early, and route flagged concerns to the right owners. That's the difference between being a note-taker and being an editor. One is displaceable. The other is not.
spec.md exposes wishful thinking.
Requirements and design collapse into one session, with organisational skills applied — brand, security, compliance, UX policy — automatically. If the requirements don't survive contact with the policies, that's revealed in an afternoon instead of six weeks into the build.
This is uncomfortable in a specific way. A lot of specs in regulated domains work because nobody carefully checks the requirements against every constraint until much later. That slack is where wishful thinking lives. When the constraints run in the same session as the requirements, the slack is gone. Some specs won't survive the day.
That's a feature.
plan.md turns the audit trail into a product asset.
In fraud, payments, embedded insurance — anywhere with real compliance overhead — the paperwork is expensive to produce and produces almost nothing anyone wants to read. Git-committed intent.md → spec.md → plan.md → review policy is a chain a regulator can follow. The trail is a byproduct of doing the work, not a separate stream to be reconstructed after.
For a PM in a regulated space, this is close to a gift. What was overhead becomes free.
What the playbook can't fix: taste.
The whole pipeline compresses to the speed at which humans can still tell good from bad. If the PM can't judge whether spec.md is answering the right question, the machine just produces higher-fidelity wrong specs, faster. If the tech lead can't judge whether plan.md is a good plan, the engineering team ships confidently wrong code at three times the pace.
The playbook is not a promise that judgment scales. It's a promise that everything below judgment scales. That leaves judgment as the constraint.
Which, honestly, is where PMs like to say the value is anyway. Now we get to find out if it is.
The playbook is right. And it's a bigger change for product than for engineering.
The good news for PMs is that the boring parts of the job — translation, formatting, chasing sign-offs — are going away. The bad news is that what's left is the part everyone claims to be good at but few actually are: framing the right problem, judging tradeoffs under real constraints, and knowing when to stop.