AI Writes the Spec. The PM Catches When It's Confidently Wrong.
The spec writes itself now. Here is an honest three-column inventory of what the PM job became: what AI owns first, what got harder, and what nobody had a job description for before.
The PRD arrived on Tuesday morning. Someone had asked an AI to draft it. It covered the right features, used the right format, and had been in the shared folder for two days before anyone noticed it wasn't written by a person. Nobody was sure that mattered.
That is the moment. Not "AI is getting better at writing specs." The moment is: the spec is done, it looks fine, and nobody quite knows whose job it was anymore.
The PM job did not shrink when AI started writing first drafts. It reorganized around different problems, some familiar in a new form, some genuinely new. What follows is an honest three-column inventory: what AI owns first now, what got harder, and what nobody had a job description for before.
The scale of the underlying shift is worth grounding before the inventory. JetSoftPro's May 2026 analysis of AI-first team structures found that traditional teams of 8 to 12 people are being replaced by pods of 3 to 4. [3] That compression changes how work gets divided. Fewer humans means each role has to account for more of what it previously handed off.
What AI Owns Now, and It's More Than the First Draft
Four specific task types now start with AI output rather than a PM's blank page.
First-draft PRDs. User stories and acceptance criteria. Competitive scan synthesis. Research briefs. These are the standard opening moves in most product teams that adopted AI tooling in 2025. The CMU Integrated Innovation Institute put it plainly in January 2026: "AI and vibe coding tools free PMs from routine prototype building, allowing them to focus on what matters most." [2] First-draft generation is routine. The PM who opens a sprint cycle by writing the PRD from scratch is doing something anachronistic.
Agimon sits in this category alongside a growing set of tools that produce first-draft PRDs, mockups, and GTM artifacts from a brief, so teams start from a structured draft rather than a blank doc.
That list of tasks is not the interesting part. What stayed harder is.
The Tasks That Got More Important
When routine production moves to AI, the work that remains is not routine. Two categories got structurally more important, not because AI cannot assist with them, but because the margin for error on each expanded.
The first is knowing what to build. Atlassian's engineering blog stated this directly in January 2026: "The scarce resource in software development isn't engineering capacity anymore. It's knowing what is actually worth building." The same piece went further: "When an AI agent can generate a working prototype in an afternoon... The risk is 'should we build this?'" [1]
When the execution barrier was high, wrong bets had natural rate limiters. They took long enough to build that misalignment had time to surface before it consumed the runway. When AI can generate 50 user stories in the time a PM used to spend organizing a discovery session, wrong direction arrives faster. The cost of building the wrong thing faster is the same cost it always was. The velocity that brings it here is new.
The failure shape is specific enough to name: a PM who approves a 50-story sprint plan the AI generated, doesn't question whether the underlying feature deserves three months of a three-person team's attention, and discovers six weeks later that no user wanted it. That PM did not fail at writing or organizing. They failed at the judgment AI cannot supply: whether the question was worth asking at all.
The second category is stakeholder alignment under uncertainty. JetSoftPro's 2026 analysis listed the human skills that persist at AI-first organizations: "Judgment under ambiguity, architectural decisions, stakeholder relationships, accountability, ethical reasoning, novel problem framing." [3] Every item on that list requires a person in the room, with context, willing to hold a position when it's contested. AI does not hold positions under pressure.
There is one more column in the inventory, and it is the one the existing job description has no language for yet.
The Tasks Nobody Had a Name for Before
This is the column the existing PM job description has no language for.
The first genuinely new task is hallucination supervision. Adrian C. Ott, writing for the CMU Integrated Innovation Institute in January 2026, framed it directly: "Experienced PMs still need to know when an AI model hallucinates and suggests something unrealistic." [2]
The specific hallucination type that trips PMs up is not dramatic. It is the AI that confidently generates a technically coherent user story for a feature that contradicts a platform constraint the PM knew about and the AI did not. The story reads well. It passes a quick scan. It gets added to the sprint. The engineer hits the constraint on day two of implementation. The cost is not the AI being wrong. The cost is confident wrongness passing a review that had no mental model for catching it.
The second new task is context management across AI sessions. Each session starts with whatever context you provide. Decisions made three sessions ago do not carry forward automatically. Someone on the team has to maintain the working product memory: what was decided, what was ruled out, what the current constraints are. That someone is usually the PM, and there was no prior version of this job, because the prior version had the PM doing the decision-writing and therefore doing the remembering. What changes when MCP connects AI to your system of record is the storage layer. Who decides what gets stored is still a PM call.
The third is accountability for AI-generated output. When the PM wrote the spec, ownership was clear. When the AI drafts and the PM approves without interrogating it, the accountability question at the moment something ships wrong is genuinely new. Structuring specs so agents and engineers can both read them addresses the format side of this. But the underlying accountability is still a PM problem, and it did not exist before the first draft stopped being a PM artifact.
That is where the steelman version of this argument earns its hearing.
The Counterargument Worth Taking Seriously
There is a version of this argument worth engaging honestly before dismissing it: this is still the same job with a faster research tool.
The steelman runs like this. PMs have always synthesized inputs from users, engineers, and market data, then made prioritization calls and aligned stakeholders. AI is a faster input synthesizer. The core skills, communication, judgment, prioritization, knowing what's worth building, did not change. What changed is the speed at which routine research and drafting happen. That is an upgrade, not a role redefinition.
That argument holds until it hits three specific breaks.
The accountability break. When the PM wrote the spec and it contained a wrong requirement, ownership was obvious. When the AI drafts and the PM approves, ownership becomes ambiguous exactly at the moment it matters: when the wrong requirement ships. That accountability gap did not exist before.
The craft-training break. First-draft ownership was not just a task: it was a training path. PMs learned judgment through writing: deciding what to include, what to fight for, what to cut. The friction of drafting was also the process of building a mental model of the product. Remove that friction and the model still has to form somewhere. Whether PMs build equivalent judgment through supervising AI output is an open question. It has not been running long enough to know.
The context-management break. Managing a live product context across sessions, explicitly, so that each AI session has what it needs to not contradict the last three, is a new operational skill with no prior description in the job.
Tim Lelek, writing on the Atlassian engineering blog in May 2026, put the implication plainly: "The PMs who thrive won't be the ones who use AI most. They'll be the ones who use it with sharper judgment, who know what's worth building and why." [4] The counterargument's core claim, that the values of the job did not change, is probably right. At the level of what the day looks like, the three breaks above are real.
So what is the job, stated cleanly?
What the Job Is Now
Here is the clearest version: the scarce skill moved from writing the spec to knowing what is worth building and catching when the machine is confidently wrong.
AI owns the first draft. The PM reads it, catches what the AI did not know about the product context, and approves or corrects. The task moved. The judgment required to verify the output did not shrink. It expanded, because the volume of AI-generated output that needs review expanded with it.
Atlassian confirmed in January 2026 that knowing what to build is now the primary constraint in software development. [1] CMU's January 2026 piece put hallucination supervision at the center of what separates AI-assisted from AI-replaced PM work. [2] The parts the job outsourced to AI were not the hard parts. The hard parts are still there, and the list just got three items longer.
If this maps to what you're seeing on your team, send it to someone who's still figuring out where the job went.
References
- Atlassian. "How AI turns software engineers into product engineers." https://www.atlassian.com/blog/artificial-intelligence/how-ai-turns-software-engineers-into-product-engineers . Published 2026-01-15. Accessed 2026-06-26.
- Ott, Adrian C. "How AI and Vibe Coding Transform Product Management." Carnegie Mellon University, Integrated Innovation Institute. https://www.cmu.edu/iii/about/news/2026/how-ai-and-vibe-coding-transform-product-management.html . Published 2026-01-27. Accessed 2026-06-26.
- JetSoftPro. "AI-First Teams: Roles, Skills, and Expectations Shifting in 2026." https://jetsoftpro.com/blog/ai-first-teams-roles-skills-expectations-shifting-2026 . Published 2026-05-20. Accessed 2026-06-26.
- Lelek, Tim. "The future of product craft: Why AI-native PMs build better products." Atlassian. https://www.atlassian.com/blog/how-we-work/the-future-of-product-craft . Published 2026-05-28. Accessed 2026-06-26.