Agile Delivery

Agile Delivery

Delivery Leadership

Delivery Leadership

IT Project Management

IT Project Management

Scrum Master

Scrum Master

Who owns the bug the AI agent wrote?

ESTIMATED TIME

12

mins

Written by

Rajveer Prasad

Published on

Authorship can be automated. Accountability can’t. Name the owner before the agent commits.


The page lands at 2:14 am. Checkout is failing for about a fifth of traffic. The on-call engineer rolls it back by 2:40, and on Thursday the team sits down for the postmortem, which begins the way these things begin: polite archaeology. Someone pulls up the deploy. Someone isolates the diff. Someone asks the oldest question in the building. Who wrote this?

The commit author is agent-runner[bot].

The room goes quiet in a way it never used to. The old follow-up, “walk us through your thinking,” has nowhere to land. There’s no thinking to walk through. The author is a service account. After a pause that runs slightly too long, somebody says the sentence the whole meeting has been circling.

“The AI introduced a regression.”

Here’s the thesis I’ll spend the rest of this piece defending: accountability doesn’t compile. You can’t generate it, prompt it, or install it as a dependency. “The AI wrote it” is the new “the contractor wrote it,” and it fails in the incident review for exactly the same reason the old excuse did. Ownership has to be assigned before the agent commits. If you’re litigating it after the outage, you’ve already lost the only version of it that matters.

The contractor defense, rebuilt with better autocomplete

We’ve run this experiment before. Companies have shipped code written by outsiders for decades: contractors, agencies, offshore teams, the consultancy nobody names in the retro. And every serious engineering organization converged on the same rule, because every other rule kept producing disasters. You can outsource authorship. You can’t outsource ownership. The vendor wrote it; you shipped it. Different verbs, different jobs.

No functioning postmortem has ever accepted “the contractor wrote it” as a root cause, because it isn’t one. It’s a confession with the pronouns changed.

An AI agent is a contractor with three upgrades and one catastrophic downgrade. It types faster, it never sleeps, and it doesn’t bill by the hour. But a contractor can be questioned. A contractor can explain a tradeoff, defend a shortcut, get embarrassed, get better. An agent can produce something shaped like an explanation, on demand, in any tone you like. What it can’t do is own a consequence. There’s no reputation at stake, nothing to lose, nothing that hurts. A bot account can hold a commit. It can’t hold a pager.

Which means every line it writes arrives ownerless. Not badly owned. Ownerless. And ownerless code doesn’t stay that way. It waits.

Authorship is booming. Stewardship is in recession.

If agent-written code were a rounding error, this would be a philosophy seminar. It isn’t. The 2024 DORA report found that as AI adoption climbed, individual productivity, flow, and job satisfaction went up, while software delivery stability and throughput went down {Google Cloud DORA, Accelerate State of DevOps 2024}. Faster hands, shakier ship. That’s not a paradox. That’s what you’d expect when generation speeds up and verification doesn’t.

The composition of the code is shifting too. GitClear analyzed 211 million changed lines of code from 2020 through 2024 and found that copy/pasted lines rose from 8.3 percent of changed lines in 2021 to 12.3 percent in 2024, while changes linked to refactoring fell from 25 percent to under 10 percent {GitClear, AI Copilot Code Quality 2025}. Read that as a culture metric, not a code metric. We’re writing more and tending less.

Swimlane map of AI generated code accountability with prompted, reviewed, merged, and on call lanes where the gold owner chip sits with humans

And the humans in the loop are getting more confident, not more careful. In a Stanford user study, participants working with an AI assistant wrote significantly less secure code than those working alone, and were more likely to believe they’d written secure code {Perry et al., Stanford University, CCS 2023}. More output, less scrutiny, higher confidence. In delivery terms that isn’t a productivity curve. It’s a pre-incident report.

None of this says the tools are bad. It says the drafts are now good enough to disarm doubt. Nobody skims the obviously shaky intern’s work. It’s the plausible draft that walks through review with a nod.

So when a postmortem says “the AI introduced a regression,” run the translation: nobody reviewed what shipped. That’s the whole sentence. The agent didn’t sneak in at night. A human pointed it at a ticket. A human, or a green pipeline standing in for one, let it merge. A human organization decided that was normal. The regression had owners all the way down. They just weren’t the name on the commit.

The job is making ownership legible

Here’s the uncomfortable truth: most teams aren’t confused about who owns agent code. They’re quietly relieved not to know. A bot byline feels like it absorbs a little blame on everyone’s behalf, and ambiguity feels like protection right up until 2 am, when it condenses onto whoever holds the pager, retroactively and alone.

Blame is what you discover after the outage. Ownership is what you assign before the commit. If it takes a meeting to find out whose change it was, you didn’t have an owner. You had a suspect pool.

So the delivery lead’s job in the agent era isn’t writing prompts, and it isn’t personally reviewing every diff. It’s making ownership legible. Four moves, none of them exotic:

  • A named human owner on every change. Before the agent’s work merges, a person puts their name on it: the one who answers questions about it, triages its defects, and carries its consequences. Not “the platform team.” A name. If nobody will put their name on a change, that’s not an admin gap. That’s a review verdict.

  • Review gates that scale with blast radius. A copy tweak and a payment-path change shouldn’t share a review policy. Tier it: low-risk changes get automated checks and sampling, high-blast-radius changes get a real human read, no matter how confident the diff looks. Depth of review follows what a change can break, never who or what wrote it.

  • Provenance on the record. Which agent, which model, prompted by whom, reviewed by whom. That’s not ceremony. It’s instrumentation. A postmortem that can’t see provenance isn’t doing five whys. It’s doing vibes.

  • On-call unmoved by authorship. If you own the service, you own its diffs, whoever typed them. The pager doesn’t read git blame.

Bar chart of GitClear data showing copy pasted code rising from 8.3 to 12.3 percent of changed lines while refactoring linked lines fell from 25 to under 10 percent

Notice what’s missing: nothing here slows the agent down. It can still open forty pull requests before lunch. The rule isn’t “humans must type more.” The rule is that the owner chip lands on a human, every change, before the merge. Authorship can be automated. Accountability can’t.

The two best objections, taken seriously

Objection one, in its strongest form: human review of machine volume doesn’t scale. If agents write ten times the code, a policy of deep human review for all of it is nostalgia wearing a governance badge.

Correct as stated. Which is why nobody serious should ask for uniform review. Tiering by blast radius is the concession to scale: read the dangerous ten percent like it’s radioactive, sample the safe ninety, let machines check machines at the bottom tier. And if honest tiering still says you can’t review what you’re merging, that isn’t an argument against review. That’s your first real capacity signal. You’re merging faster than you can be responsible for, and the constraint didn’t appear with the agents. The agents just found it.

Objection two: vendor liability will mature. Contracts, indemnities, insurance products. Eventually the model provider will stand behind the code the way cloud providers came to stand behind uptime.

Partly right, probably. But liability and operational ownership are different products, and confusing them is how you end up well compensated and still down. Liability settles who pays after the damage. Operational ownership settles who acts during it. An indemnity clause has never rolled back a deploy. When checkout is failing, your vendor’s SLA credit is not in the war room. Even in the best future for vendor accountability, money will move and nobody at the vendor will get paged. The 2 am problem stays yours. It always stays yours.

And let me scope this honestly, because an argument that overclaims is just a different kind of bug. I’m not saying agents caused your last outage. I’m not saying human review catches everything; humans wrote legendary outages long before autocomplete got ambitious. The claim is narrower and harder: when the bug comes, and it will, the difference between a bad night and a bad quarter is whether ownership was assigned in advance or improvised in the incident channel.

Name the owner while the change is still cheap

Go back to that Thursday room. The silence after “who wrote this” wasn’t confusion. It was a policy gap becoming audible.

If you lead delivery, you can close it this week without buying anything. Pick your riskiest surface and write the tier table: which changes always get a human read, which get sampled, which the machines may wave through. Add an owner field to the change template and make it hold a person, not a team name. Record provenance where the postmortem will go looking for it. Then put one line in the runbook and mean it: every change has a named human owner before merge, and authorship never moves the pager.

The agent will write the next bug. It will never own it. Someone will, either on purpose in daylight or by elimination at 2 am. The whole argument is that you get to choose which, exactly once, and the moment to choose is before the commit.

Sources
Google Cloud DORA, Accelerate State of DevOps Report 2024.
GitClear, AI Copilot Code Quality: 2025 Look Back at 12 Months of Data, 2025.
Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh (Stanford University), Do Users Write More Insecure Code with AI Assistants?, ACM CCS 2023.
Small gold bug resting on a large dark green open palm, a metaphor for AI generated code accountability landing in human hands

Subscribe to the Newsletter

Join our growing community and get alerted first on our every article.

*By subscribing, you agree to send your information to our Company who agrees to use it according to their Terms and conditions and Privacy Policy

About the author

With 20 years guiding high-stakes Agile transformations, I turn theory into action at Oaktreeuni—mentoring aspiring Scrum Masters to think critically, adapt fast, and lead beyond frameworks. The payoff? You step into a high-paying Scrum Master or Agile PM role already equipped to excel.

Who is responsible when AI writes bad code?

The organization that shipped it, and inside it, the named human who owned the change. Assign that owner before the merge. Vendor liability may pay for damage later, but it never operates your system during an incident.

Should AI generated code get a different review process?

Review depth should follow blast radius, not authorship. Low-risk changes can ride automated checks and sampling; payments, auth, and data migrations get a full human read even when the diff looks clean.

Can an AI agent be accountable for a production bug?

No. An agent can author a change and even explain it, but it can’t carry consequences, hold a pager, or answer in an incident review. Accountability stays with people, so name the owner up front.

Comments

OAKKTREEUNII

30 N Gould St, STE N, Sheridan WY 82801

Are you still waiting for the right time to get started?

While you hesitate, others with fewer skills are cashing 50% more than you. Act now!

© 2026 OAKKTREEUNII | All rights reserved.

OAKKTREEUNII

30 N Gould St, STE N, Sheridan WY 82801

Are you still waiting for the right time to get started?

While you hesitate, others with fewer skills are cashing 50% more than you. Act now!

© 2026 OAKKTREEUNII | All rights reserved.

OAKKTREEUNII

30 N Gould St, STE N, Sheridan WY 82801

Are you still waiting for the right time to get started?

While you hesitate, others with fewer skills are cashing 50% more than you. Act now!

© 2026 OAKKTREEUNII | All rights reserved.