Who's Accountable When the Agent Ships the Bug?

The first time something broke in production and someone said well, the agent wrote that part, I felt the ground shift a little.

It was said reasonably, not as an excuse. The code that failed had been generated by an AI agent, reviewed quickly, and shipped. The person saying it was not dodging anything; they were describing what had happened. But the sentence did something to the room. For a second there was a genuine question nobody had needed to ask before: whose fault is this, exactly?

That question is going to come up more and more. It is worth being clear-eyed about it now, before it becomes a habit, because the easy answers are all wrong in the same direction.

The AI wrote it is not an account of what went wrong. A tool cannot be accountable. You can't put it in front of a client, it can't take responsibility, it can't carry the lesson into next time in the way that matters. It just produces the next output. When a hammer bends a nail, nobody holds the hammer responsible. What changed with AI isn't that the tool got good enough to blame; it is that it got good enough that we are tempted to.

And that temptation is the actual risk. Not the bug, bugs have always happened and always will. The risk is quieter: that the agent did it becomes the place responsibility goes to disappear. It joins the process failed and there was a miscommunication, the phrases people reach for when they would like a problem to have no owner. Each is often true. None of them is a person. And a bug with no owner doesn't get truly fixed. It gets patched, and it comes back wearing a different hat.

Here is the shape of it, because it is worth seeing clearly. Responsibility diffuses the moment there is a plausible non-human to hand it to.

Take the incident I mentioned. The change was prompted by a developer, generated by an agent, skimmed in review because it "looked like standard code," and merged. When it broke, there were four honest half-answers available. The developer only prompted it. The reviewer only glanced, because the agent usually gets this right. The agent, well, the agent is not a who. And I had not set a rule that agent-generated changes to anything sensitive get a real review rather than a glance. Four people each holding a quarter of the responsibility is functionally the same as nobody holding it. The bug had no owner, and a bug with no owner is a bug you will see again.

None of that is anyone being lazy. It is what happens by default when a capable non-human enters the chain and everyone, reasonably, assumes it carries some of the weight. It doesn't. It can't. The weight just quietly falls on the floor.

The tell is in the language. Listen for the passive voice creeping into your incident reviews. The change was merged. The check was skipped. The output was trusted. Every one of those had a person doing it, and the passive voice is how the person quietly exits the sentence. When your postmortems start reading like weather reports, things that simply happened, you have already lost the thread.

This is where the job quietly gets more important, not less. Someone has to make sure every outcome, including the ones an agent produced, still has a human name attached to it. Not to hand out blame, to keep the loop honest.

The developer who prompted it and shipped it owns it. The review that waved it through owns its share. And I own the fact that the system let it reach production without a real check. The agent sits in that chain, but it is never the end of it. The chain has to terminate in a person, or it isn't a chain, it is a way for the buck to keep moving until everyone has forgotten who was holding it.

In practice that means the human in the loop can't be a checkbox. If an agent's output goes out under your team's name, someone signed off on it, and that someone is answerable for it. The moment the answer to who approved this becomes the agent, you don't have a process anymore. You have a way to launder mistakes.

Agents don't remove accountability. They make it easier to misplace, which makes guarding it a bigger part of the job, not a smaller one. The PM's oldest function, making sure the buck stops somewhere real, matters more in a world where the work has one extra place to hide.

This is not about being harsh. The most accountable teams I have worked on were also the calmest, precisely because everyone knew where the lines were. Clear ownership is not blame culture; it is the opposite. Blame culture is what fills the vacuum when ownership is vague, because when nobody is clearly responsible, everybody is a little bit suspect. A name on the outcome protects the team as much as it protects the client.

So when an AI-generated change breaks something on your team, ask where the responsibility actually lands, and whether that is on purpose or just where it rolled to.