Who Is Accountable for AI-Generated Code?

Most days now I build software with AI agents, and I am the one who signs off on what they write. On my own game, the agent produces a chunk of code, I accept it, and if it ships broken there is nobody to point at but me. That clarity is a luxury of working alone. On a team it gets murky fast.

Here is the version I watch for. A change lands in production and breaks something. Someone pulls up the pull request to find out who to talk to. The code was generated by an agent, accepted with a quick glance, approved by a reviewer who was moving fast, and merged. Every person in that chain assumed someone else had really checked it. Nobody had. The gap there is not in the testing. It is in ownership, and AI-assisted development opens it faster than anything else I have seen.

AgentGenerateswrites the code

›

DeveloperAcceptsa quick glance, assumes the agent got it right

›

ReviewerApprovesmoving fast, assumes the author checked

›

ProductionBreaksnobody can answer for it

Whether AI-generated code is risky, and how QA gates it, I cover in full in QA is the control layer for AI-assisted development. This piece sits underneath those gates. When a tool wrote the code, who is accountable for it being right, who actually signs off, and how does a team make that ownership explicit instead of letting it dissolve. The controls only work if a named person owns the outcome. Skip that and you have a green pipeline with nobody who can answer for what shipped.

Generating code is not the same as owning it

A lot of AI-assisted workflows carry a quiet assumption: whoever prompted the agent owns the result. That falls apart the moment you look at what owning the result actually takes.

When I write a function by hand, authorship and accountability arrive together. I understand the code because I built it line by line, so when it breaks I can say what it was supposed to do. When an agent writes that function, the two come apart:

• Authorship moves to the tool. The developer authored the prompt, not the logic.
• Reading is optional. They may not have read every branch the agent produced.
• The author is gone at failure time. The agent will not be in the room when the thing breaks.

So accountability has nowhere to land unless a person deliberately picks it up.

This is the part I want to be exact about. Accepting a suggestion is a click. Owning it means you can answer for it. You understand what it does, you decided it was correct, and you are the person the team comes to when it is not. A tool can produce code. It cannot be accountable, because accountability needs someone to hold responsible, and you cannot hold a model responsible. So the real question is never “did the AI write good code.” It is “which human is standing behind this change,” and on a lot of teams right now the honest answer is nobody in particular.

A tool can produce code. A tool cannot be accountable for it.

Why “the developers will catch it” is not an ownership model

The reflex answer is that review handles this. Someone approves the pull request, so accountability lives with the approver. In practice that describes a hope, and it fails for a reason that has nothing to do with how careful anyone is.

“The developers will catch it” spreads responsibility across everyone and lands it on no one. Social psychology has a name for it, diffusion of responsibility: the more people who could act, the less any single person feels they must. AI makes it worse. The author quietly assumes the agent already got it right, and the reviewer quietly assumes the author checked. Two people both believe the code has an owner. It has none.

It gets sharper when you ask what the approval even meant. A reviewer skimming a clean, idiomatic diff under delivery pressure is approving that the code looks right, not that they checked it is right. Generated code is very good at looking right, and that fluency is exactly what lowers scrutiny. A green review can mean two very different things:

• “I read this and I stand behind it.”
• “This looked fine and the tests passed.”

A thumbs-up icon does not tell those apart. And if the approval was really resting on a passing suite, the ownership rested on the tests, and AI-written tests tend to confirm what the code already does instead of challenging it. That is how a green suite can be confirming a defect rather than catching one.

You do not fix this by asking people to try harder. You fix it by making ownership a named, recorded thing instead of an assumption everyone makes about someone else.

Name an accountable owner for every AI-assisted change

Borrow the spirit of a RACI matrix and point it at AI-assisted work. One rule carries all the weight: exactly one Accountable person per change, never a tool and never a committee. Plenty of people can be Responsible for doing parts of the work. Only one name answers for whether the change was right to ship.

Here is who owns what when an agent wrote the code. Responsible does the work, Accountable answers for the outcome, Consulted gives input, Informed gets told.

Activity	Developer (prompter)	Reviewer	QA / Quality	Tech lead
Generate and accept the code	R	·	·	·
Understand what the change actually does	A	C	C	·
Confirm it solved the right problem	A	C	C	·
Verify the tests would fail on a real bug	C	C	A	·
Sign off that risk is acceptable to ship	C	R	A	I
Own the rollback if it breaks in production	A	·	C	I
Own the policy for how AI is used here	C	·	C	A

R/A responsible or accountable   C/I consulted or informed   · not involved

Read across the rows and the model is concrete:

• The developer who prompted the agent is accountable for understanding the change. Acceptance without understanding is the original sin here.
• QA is accountable for signing off that the risk is acceptable, because that is the judgment no one else in the chain is positioned to make.
• The agent appears nowhere in the table, because a tool cannot hold a letter. Every box belongs to a person.

The exact role names matter less than the discipline. One accountable human per change, and that human can pass an honest test before they sign their name to it.

The “can I sign off” test

Accountability becomes real at the moment a person says, out loud or in writing, “I own that this is right.” Before I put my name on an AI-assisted change, I want a yes to each of these. If you cannot get there, you are not the owner yet, you are the person who clicked accept.

1. Can I explain what this change does in one honest paragraph, without re-reading the agent’s summary?
2. Do I know what problem it was meant to solve, and can I say why this solves it and not a plausible neighbour?
3. If this breaks at 2am, am I the person who gets called, and could I start debugging it?
4. Is there at least one test here that would actually go red if the behaviour were wrong?
5. If a teammate asked me “are you sure this is right,” would my answer be evidence, or a shrug?

That last one carries the most weight. What does this actually prove is a question a good owner can always answer about their own work. If the most honest answer you have is “the agent seemed confident and the build was green,” the change does not have an owner yet. It has a hopeful bystander. A diff that looks right, backed by nothing you personally checked, is not evidence, and a thumbs-up icon on it does not turn it into evidence.

Record the sign-off where the change lives

Ownership that lives only in someone’s head evaporates the moment they go on leave. Put it in the artifact. You do not need a heavy process or a new tool. You need the pull request to carry, in writing, who owns what. A short, required block in the template does it:

## AI-assisted change

- Generated with: <agent / tool>
- Accountable owner: @name  (understands the change, owns the rollback)
- What it does (in my own words): ...
- Risk if it is wrong, and who it affects: ...
- Evidence it works: <link to a test that would fail on a real bug>
- QA sign-off (risk acceptable to ship): @name
- If unverifiable before release: monitor + owner + rollback plan

Three things make this block earn its place:

• It makes the owner write the change in their own words, which is the cheapest test I know of whether they understand it.
• It separates the developer’s accountability for the code from QA’s sign-off on the risk, so a green pipeline can never quietly stand in for either.
• It leaves a record, so when something breaks the team reads a name and a paragraph instead of guessing from a commit hash.

When a problem does reach production, that record turns a blameless postmortem from “how did this get through” into “our sign-off step missed this specific risk, here is how we tighten it.” The first is a witch hunt. The second is a team getting better.

Ownership has to scale to the volume, not the line

The honest objection is that this cannot keep up. If a team generates ten times the code, a named owner reading and standing behind every change becomes the bottleneck AI was supposed to remove. That objection is right, and it points at the real shape of the answer.

You do not scale ownership by making one person read more. You scale it by sizing the ownership to the risk. A copy tweak and a change to payment-handling code do not deserve the same sign-off, and treating them the same is what makes the whole process feel unaffordable. Tie the weight of ownership to the blast radius:

• Low risk (copy, styling, internal tooling): the accountable owner is the developer who accepted it, full stop. No second sign-off. Speed is the right call here.
• Medium risk (a new feature path, a changed query, anything user-facing): named developer owner plus a real review, where “real” means the reviewer can answer the can-I-sign-off test too.
• High risk (auth, payments, data integrity, anything that loses money or trust when it is wrong): named developer owner and an explicit QA sign-off on risk, recorded in the pull request, before it merges.

This is the same instinct behind a good code-ownership setup, where the people accountable for a sensitive area are required reviewers on anything that touches it. GitHub’s CODEOWNERS does exactly that mechanically. It routes changes in a path to the humans who own that path. Point it at your high-risk directories and accountability stops depending on anyone remembering to add a reviewer. The volume can climb as high as the tooling allows. What does not get to climb is the number of high-risk changes that ship without a name attached.

Where this leaves you

AI changed who writes the code. It did not change who has to answer for it. AI is uneven. Hand it the data and the analysis, and it is genuinely strong there. The judgment about whether a change is right to ship is the part it cannot hold. The teams that get into trouble are not the ones generating the most code. They are the ones who let authorship move to the tool and forgot to hand accountability to a person. The teams that do well keep ownership explicit: one accountable name per change, a sign-off sized to the risk, and a record that lives where the change lives.

If you make one move this week, add the AI-assisted block above to your pull request template and require a named accountable owner on anything touching auth, payments, or data. It costs almost nothing, and it turns “someone approved it” into “this person owns it.” That is the difference between a team that can answer for what it ships and one that finds out who was responsible only after it breaks. To fit that into a fuller approach, the test strategy builder helps you decide which changes need which level of sign-off.