When a Product Manager Ships Code, Who Owns the Outage?

Listening to organizations that build software with AI, one thing stands out: the set of people who write code is changing. Product managers build features directly, and several agents work in parallel. That forces a second question about the development team. Beyond who is allowed to write code, who checks what on the way to the customer?

The question in the title is not about picking someone to blame after an incident. It is about defining the scope of responsibility before a change that affects production exists at all. Responsibility here means an operational role, not a verdict.

Why is a demo not the same as a deploy?

Because between "it works in the demo" and "it is safe to ship" sit several questions that no screen shows. Take a hypothetical, purely for illustration. A product manager builds an admin page with AI. It works in the demo and displays the right information. Then the deploy conversation raises a different set of questions.

• Can someone without permission read data through this page?
• Does it handle the edge cases in existing customer data?
• If it fails, what exactly has to be rolled back?

Having implemented the page does not answer any of these. That is true regardless of who wrote it.

Does AI-written code eliminate review and approval?

No. There has to be a standard for evaluating a change that is independent of who wrote it, and someone has to own that standard. Whoever defined the business need explains which user problem it solves. A reviewer checks the implementation and its risks. Whoever runs operations understands the conditions for deploying and recovering. One person can hold several of these roles. The state to avoid is one where no role has an owner.

This separation of roles did not appear because of AI. NIST SSDF 1.1 treats defining roles and responsibilities for secure development (PO.2) and reviewing or analyzing source code (PW.7) as distinct practices. My reading is that even when AI writes the code, the organization still decides how those practices get carried out.

Does every change need the engineering team?

No. Routing every change through one engineer does not hold up for long. A copy fix and an authentication policy change do not have the same blast radius.

My proposal has two lanes. Low-risk, easily reversible changes go through a verified fast path. Changes that touch data, permissions, or external integrations get the reviewers they need. A fast path only works if its boundaries are explicit. The sentence "changes like this may be self-deployed" has to exist in writing before the fast path is real.

What should the person pressing Approve actually see?

Exactly what they are approving. Is it the latest code, or the artifact that will actually be deployed? Which tests and security checks ran against that artifact? Which items could not be verified? A button pressed without knowing what it approves makes accountability hard to establish.

I pay particular attention to code changing after approval. If version A was approved and version B is what runs, someone has to confirm that the judgment about A still applies to B. SLSA provenance, which records where a build artifact came from, exists to make exactly that kind of origin verifiable. Deployment approval needs the same discipline of identifying its target precisely. I wrote about what that costs on the supply-chain side in the real cost of SLSA.

After an outage, do we go find the author?

Before the author, look at what the verification and approval steps missed. The Google SRE postmortem culture describes understanding the conditions that contributed to an incident and building recurrence prevention, rather than blaming individuals. Applied to an organization, that means asking, alongside who wrote it, at which stage the risk should have been visible. Responsibility after an incident should turn into recovery and learning.

Honestly, this principle applied just the same when the author was a developer. Widening the set of authors changes nothing about it.

What the engineering team gains

The engineering team gets one more important job: designing verifiable execution paths so that more people can build software. Everyone should be able to tell which changes they can ship on their own and which ones need an expert alongside. How far agents should reach into production is a question I continued in agents and production authority.

This is also why I focus on Change and traceability at CollabOps. Whoever wrote it, with whatever tool, a change that reached production should be explainable by its intent, exact code version, artifact, verification evidence, approval, and deployment history. When the repository, change requests, pipelines, and deployment records live on one plane, "what was approved" stops being an investigation and becomes a byproduct of doing the work. As the set of authors widens, the scope of what we can be accountable for together has to be designed just as deliberately.