Who's accountable when an AI-drafted spec ships a bug — the PM, the prompt, or no one?

The shift

Producing a detailed, plausible spec — edge cases, acceptance criteria, user flows — goes from scarce (bounded by one PM's drafting hours) to abundant (a model generates it in seconds, at any length, on demand). Verifying that spec against how the real system and real users actually behave stays exactly as scarce as before, except there's now more spec to verify and less time spent producing it to build in that verification along the way.

The axioms

• A spec's author is who takes the blame when it ships wrong — rests on authorship being traceable to a single scarce drafter.
• Writing a spec was slow, so the act of writing it doubled as the act of thinking it through — rests on drafting time being scarce enough that thoroughness and authorship were the same motion.
• A shipped bug traces back to one identifiable gap a human read past — rests on specs being short and sparse enough that a human plausibly read every line.
• Review is cheap relative to writing, so a reviewed spec is a vetted spec — rests on review effort being sized to a human-paced draft.
• The PM owns the call because the PM is the one who decided what to build — rests on judgment and goal-setting being a scarce, singular human act.
• "The prompt" can't be held accountable because it isn't an entity with standing — rests on accountability requiring a body that can be answerable, sanctioned, or sued.

Invalid axioms

1. Writing the spec and thinking it through are the same act. Drafting used to force a PM to reason through every case by hand, so the act of writing was also the act of catching gaps. AI collapses drafting to near-zero cost, so a spec can now look thorough without anyone having reasoned through it line by line. The habit-trap: orgs still treat "the spec is written" as evidence that thinking happened, and route sign-off as if length or polish signaled rigor.
2. A bug means someone missed a line they should have caught. When specs were short because drafting was expensive, a human plausibly read and reasoned about every sentence, so a missed edge case was a legible personal lapse. AI-drafted specs are often longer and more exhaustive-looking than any human would have produced by hand, past the point where line-by-line human reading is realistic. The habit-trap: post-mortems still ask "who read this and missed it" as if reading were the same activity it was at the old spec length.

Unchanged axioms

1. Someone specific has to own the decision to ship. A model can generate the spec, but deciding this feature, this scope, this tradeoff is worth building is a judgment call under real stakes, and that call still sits with a person — usually the PM, sometimes jointly with an engineering lead. Cheaper drafting doesn't make that decision cheaper or transferable to the tool that helped write it down.
2. Accountability requires a body that can answer for the outcome, and a prompt isn't one. "The prompt" is a category error, not a candidate — it has no standing, can't be reviewed for judgment, can't improve under consequence the way a person can. The either-PM-or-no-one framing in the question is closer to right than either-PM-or-prompt: the real fight is whether it's the PM alone, or the PM plus whoever approved and shipped without verifying.
3. Verifying a spec against how the system and users actually behave is still a scarce, human-paced act. AI can draft acceptance criteria; it can't verify against ground truth it doesn't have — actual system constraints, actual user behavior, actual edge cases in production data. That verification is exactly as slow and expensive as before, and specs generated at higher volume now have more of it to do, not less.

New axioms

1. When a spec looks complete, who's supposed to still doubt it. A spec that reads as exhaustive suppresses the instinct to probe it — thoroughness of appearance now decouples from thoroughness of thought, and nothing in the current review process flags the gap. Orgs need some replacement for "this looks too sparse, ask more questions" now that sparseness isn't the tell.
2. Diffusion of authorship across PM, model, and reviewer makes single-point blame technically incoherent even when it's organizationally necessary. If a PM prompts a model, edits half of it, and an engineer implements from it without flagging an ambiguity, the bug has three plausible originating points and no clean causal chain — but the org still needs to name one owner for the retro and the next decision. Nobody has a working definition of what counts as "authored" a spec once drafting is assisted.
3. The cost of generating alternative specs and edge-case coverage is now near-zero, but nobody has resized the verification budget to match. Teams can generate ten versions of acceptance criteria for the price of one, but review headcount, review time, and QA capacity are still sized to the old, slower drafting cadence — the new volume of plausible-looking spec surface has no matching increase in checking capacity.

Where it breaks

"The spec looks thorough, so review can be lighter" (invalid habit, carried over from when thoroughness correlated with human effort) collides directly with "verification is still scarce and now has more surface to cover" (new problem) — teams are shipping AI-drafted specs through the same or lighter review gates that were calibrated for shorter, human-drafted ones, exactly when the review gate needed to get heavier. The bug that ships isn't a failure of the PM's judgment or the model's competence — it's a review budget that never moved when drafting cost did.

ai-axioms.vercel.app/axioms/product-management/product-eng-boundary-accountability-ai-axioms