Who is accountable for an AI-assisted change once it merges, and what follows for the author?
answer
- Nothing about ownership moved
- A tool cannot be asked why
- Ownership follows the submit button
- Cannot explain it, cannot submit it
basics
~20 sThe people, not the tool: the author owns the change they submitted and the reviewer owns the approval, exactly as before. What follows is a bar at submission - do not send code you cannot explain.
solid answer
~50 sAccountability does not move, because the tool cannot hold any. You can ask it why a branch is there, but nothing makes that answer accountable: it was not present when the decision was made, it cannot be on call, and it cannot be corrected in a way that persists. So the author owns the change once it merges and the reviewer owns the approval, the same as for hand-typed code. The practical consequence is a bar at submission: if you cannot explain why each part of a change is there, it is not ready for someone else's time. "The assistant produced it" is not an answer in review, and it is worse during an incident, when what is needed is the model of the system the author never formed. None of this is about blame - it is about who can reconstruct the reasoning.
go deeper
Say plainly that you own what you submit, whoever or whatever typed it, and that you read every line before asking another person to spend time on it.
Explain why the tool cannot hold responsibility: it cannot be asked about the change later, cannot be on call, and cannot be corrected in a way that persists into the next change.
Show what the bar costs under deadline pressure - what you actually do when a change is large, plausible, and there is one section you have not understood yet.
Own how the team states this in writing, so the argument does not happen for the first time during an incident and does not curdle into blame or a tool ban.
## Why accountability cannot move Responsibility attaches to the party who can answer for a decision, and a drafting tool can do none of the things that answering requires. It can be *asked*, six months later, why a particular branch exists, and it will produce something - but nothing connects that answer to the change that was actually made. It cannot be on call. It cannot be corrected in a way that sticks across the next change. It has no duty to your users and no stake in your system. So the ownership question has a dull answer, and the dullness is the point: **the author owns what they submitted, the reviewer owns the approval, and the origin of the text changes neither.** This is the same answer teams already give for code copied from a public answer site, a vendor sample, or a colleague's branch. ## What the author actually owes The interesting half is not the principle but what it costs to hold. 1. **Read every line you are asking someone else to merge.** Not skim for shape - read, because plausibility is what a suggestion is best at producing and skimming tests for exactly that. 2. **Be able to explain why each part is there.** If the answer to "why this early return?" is "that is what it produced", the change is not ready to be reviewed. 3. **Cut what you cannot explain.** The cheapest resolution is usually the author's own: rewrite the section by hand, shrink it, or drop it from the change. That bar is stated in terms of understanding, not in terms of tools, which is what makes it durable. It applies unchanged to a completer's single line, to a long generated block, and to code lifted from anywhere else. ## Where the reviewer stands The reviewer owns the approval exactly as before, and nothing about a change's origin raises or lowers that. What does not follow is that the reviewer becomes the change's *first* reader. Review is a second opinion, and it degrades badly when it is used as a first one - the reviewer has less context than the author, not more, and cannot supply understanding the author never formed. | The claim | What it gets right | Where it fails | |---|---|---| | "The tool wrote it, so the tool is responsible" | The text did not originate with a person | Nothing can be asked of the tool afterwards | | "The pipeline passed, so ownership moved to CI" | The checks did their job | A check enforces what someone encoded, not judgement | | "It was approved, so it is the reviewer's now" | Approval is a real commitment | Approval adds an owner; it does not remove one | | "I could not have caught that anyway" | Reviews miss things, always | The author was in a position to read it first | ## The situation this gets argued in The week after an assisted change ships a bug, a team discovers it has never said any of this out loud. The conversation then happens under pressure, with someone's name attached to the incident, and it curdles into blame or into a rule banning a tool. Both outcomes are worse than the sentence the team could have written in advance: *we own what we merge, whoever or whatever typed it.* Writing it down beforehand does two things. It makes the submission bar legible, so an author who does not understand a section knows what is expected of them rather than guessing. And it separates ownership from fault: owning a change means you are the one who can explain and fix it, not that you are the one to be punished for it. ## The pressure that actually breaks this The honest failure mode is not ignorance of the principle - almost everyone agrees with it when asked. It is a deadline, a large plausible change that mostly works, and one section the author has not understood. The bar is only real if there is an answer for that moment, and the workable answers are small: - **Shrink the change** so the part you have not understood is simply not in it. - **Rewrite that section by hand**, which is often faster than defending something you did not write. - **Say so in the request** - name the part you are least sure of, so the reviewer's attention starts where your understanding stopped. The last of these is the honest version of asking for help, and it is a very different act from staying quiet and hoping. ## What an interviewer is listening for A strong answer is short on principle and long on consequence. It states that ownership sits with the people, explains why the tool cannot hold any, and then moves straight to the submission bar and what happens when a deadline makes it inconvenient. A weak answer either hedges about shared responsibility with the vendor, or states the principle with such force that it becomes a reason not to use the tools at all - which is a different question, and not the one being asked.
- An author says they do not understand one function in their own change. What now?The change is not ready, and the cheapest fix is the author's. Rewrite that function by hand, or have the tool explain it and verify the explanation against the code, or cut it from the change. Passing it on and hoping the reviewer works it out moves the work to the person with less context, not more.
- Does this mean the reviewer is off the hook for an assisted change?No. The reviewer owns the approval exactly as before, and the change's origin does not lower that. What it does not mean is that the reviewer becomes the first reader. Review is a second opinion, and using it as a first one is how a change nobody has understood reaches production with two names on it.
- How is this different from merging code copied from a public answer site?In principle it is not: both put code in your repository that you did not reason your way to, and both leave you answering for it. The difference is volume and fit. Assistance produces far more of it, shaped to your naming and style, so the moment where you notice you do not understand it is much easier to skip.
saying these in an interview costs you the question
- Says the tool's mistakes are the tool's responsibility
- Treats an approved change as no longer the author's problem
- Thinks a passing pipeline transfers ownership to CI
- Believes it is fine to submit code the author has not read
- Says assisted code needs no explanation because it looks standard