A bad deploy goes out on a Friday. Checkout starts failing. Someone pulls up the pull request that caused it, and the description reads clean, the tests were green, the diff looks reasonable. Then someone notices the branch was written end to end by an agent, and the room goes quiet for a second. Not because anyone is confused about how to roll back. Because for a moment, nobody is sure whose name is on this.

That pause is the whole problem with AI accountability in software development, and it is worth resolving before the incident, not during it. The short answer is that responsibility did not go anywhere. It never transferred to the agent, because it cannot. The longer answer is about why, and about how to structure your process so the pause never happens.

Accountability is not a task you can delegate to a tool

We delegate work to tools constantly. A compiler generates machine code and we do not hold the compiler responsible for a crash. A linter reshapes our source and we do not blame the linter for a bug it introduced. The reason is not that these tools are infallible. It is that a tool is not a party that can be accountable. Accountability is a relationship between people and consequences, and a tool sits outside it.

An AI agent is a more capable tool, not a new kind of legal or moral actor. It can produce a pull request that looks like a competent engineer wrote it, which makes it tempting to treat it like one. But "the AI did it" is not an answer anyone downstream will accept, the same way "the compiler did it" is not. A customer whose data was exposed, a regulator asking who approved a change, an on-call engineer at 2am: none of them can hold an agent responsible, because there is nothing there to hold. The responsibility lands on whoever put the change into production, whether or not that was made explicit beforehand.

So the question is never really "is the human or the AI responsible." It is "which human, and did they know they were on the hook." The failure mode is not misplaced blame. It is diffuse blame, where the agent becomes a place for responsibility to quietly evaporate.

The two decisions that own the outcome

For code that ships, two moments carry the responsibility for liability from AI agents, and both are human by necessity.

The first is the merge. Someone accepts the change into the codebase. Even if an agent wrote every line, a person decides that this diff is good enough to become part of the product. That decision is an act of authorship in the sense that matters: you are vouching for it.

The second is the deploy. Someone decides this goes to production now, with this risk, in this state. That is a risk-acceptance decision, and risk acceptance is exactly the kind of thing that cannot be handed to a process that has no stake in the outcome.

If those two decisions have named humans attached, your accountability story is intact no matter how the code was produced. If they do not, you have a gap, and the gap does not announce itself until something breaks. The uncomfortable version of this: if your answer to "who approved the deploy" is "the pipeline did, automatically," then you have not removed the human from the loop. You have removed the accountable human from the loop, which is worse, because now the responsibility still exists but has no name.

This is the same argument that sits under what "a human approved this" should actually mean, seen from the consequences end. An approval is not a formality. It is the moment a person takes responsibility for what follows.

Responsibility without a record is just an argument

Naming the responsible human is necessary but not sufficient. When the incident happens, you need to be able to reconstruct what they were deciding and what they could see at the time. Otherwise the post-incident conversation degrades into memory and defensiveness, which helps no one and fixes nothing.

This is where accountability and record-keeping meet. A durable trail of who approved what, when, and on the basis of what information turns a blame argument into a factual review. It also protects the humans involved: an engineer who approved a change based on green tests and a clean impact summary made a reasonable decision, and the record shows that, even if the change turned out to be wrong. Without the record, they are just the last person who touched it. This is why the audit trail is the product, not a feature, and why reconstructing an AI decision after an incident has to be possible by design, not by luck.

The goal is not to build a paper trail for its own sake. It is to make sure that when responsibility is exercised, it is legible afterward. Accountability you cannot reconstruct is accountability you cannot learn from.

What this does not mean

It does not mean the human is a rubber stamp who absorbs blame for a machine's mistakes. That would be its own kind of theater, and engineers see through it fast. The point of keeping a human accountable is that the human is actually deciding, with enough context to decide well: the diff, the tests, what the change touches, the risks. Accountability without the ability to exercise real judgment is just liability transfer, and it will not survive contact with a serious incident or a serious engineer.

It also does not mean humans catch everything. They do not. A responsible reviewer will still approve changes that later break, because that is what it means to make decisions under uncertainty. Responsibility is not a promise of perfection. It is a commitment that a named person weighed the risk and can be answered to, which is the thing that lets an organization improve instead of just assigning fault.

The honest limitation

Keeping responsibility human does not make the bugs go away, and it does not make the hard calls easy. It adds a person into a path that could, technically, run without one, and that person is fallible, occasionally slow, and sometimes wrong. That is the cost. The benefit is that when something breaks, there is a real answer to "who decided this," a real record of what they knew, and a real path to doing better. The alternative, an agent shipping to production with no accountable human at the merge or the deploy, does not remove the risk. It just removes the person who was supposed to own it, and leaves the responsibility floating until an incident forces the question.

At Loopsfinity, this is a deliberate stance rather than an oversight: the decisions that carry real consequences stay human, because "the agent did it" was never going to be an answer anyone could stand behind. Speed is worth a lot. Speed with a name attached to it is worth more, and it is the only version that holds up when the deploy goes wrong. For the fuller picture of what it takes to trust an agent with production, start with the pillar on trusting an AI agent to ship.