Who Owns the Consequences of AI-Written Code?

START WITH THE MECHANISM

Interactive companion and laboratory update: 12 November 2026. The editorial date places the topic on the timeline; this current explanation and its measured evidence retain their actual preparation and execution dates.

THE FULL INVESTIGATION

Who Owns the Consequences of AI-Written Code?

Dates and technology context

This is a retrospective editorial timeline. Topic context: 12 August 2025. First publicly available: 12 November 2026. Current text, visuals and laboratory revisions were prepared on 12 November 2026.

The contemporary completion and recovery laboratory discussion belongs to November 2026 and must remain separate from the August 2025 accountability argument.

Prepared on 12 November 2026, this retrospective essay examines responsibility from the perspective of 12 August 2025; it does not claim an earlier publication.

A generated function cannot attend an incident review. It cannot authorize compensation, decide whether a service should remain unavailable, or explain to a customer why a promise was broken. People and organizations must do those things.

This observation sounds obvious until a defect passes through a workflow in which everyone can point to someone else. The developer used an approved assistant. The reviewer saw passing tests. The manager encouraged faster delivery. The platform team supplied access to the model. Each statement may be true. Together, they can still leave an unanswered question: who was responsible for deciding that the change was safe enough to release?

AI does not create this organizational problem from nothing. It gives an existing problem a new and persuasive place to hide. A plausible explanation of how code was produced can be mistaken for an explanation of why it was accepted.

My position is that delegating generation changes the work of engineering without transferring the organization's responsibility for its effects. The practical response is to connect consequential decisions to people who have both the authority and the information to make them.

Follow the change, not the prompt

Consider a hypothetical application that processes refunds. A developer asks an assistant to simplify the retry logic around an external payment call. The resulting code handles timeouts more neatly and passes the existing tests. It is reviewed and released.

Later, an ambiguous timeout leads to a repeated request. In this invented scenario, the external system has already processed the first request, while the application believes that it failed. The repeated action creates an incorrect effect.

It would be easy to frame the incident as a model error. Perhaps the generated code did not preserve an important condition. But that explanation is incomplete. A consequential behavior changed, and the organization's acceptance process did not reveal the difference.

The useful investigation follows the decision through its boundaries. Who defined the meaning of a retry? Which contract described what the external service could guarantee? What did the tests establish? Who could approve a change in the treatment of ambiguous outcomes? What would have stopped the release if that guarantee remained unknown?

These questions do not imply that a human author would have avoided the defect. They identify the controls the organization needs regardless of who or what proposed the implementation.

They also prevent a misleading response: replacing one assistant with another while leaving the acceptance process unchanged. A better generator may reduce some errors. It does not eliminate the need to decide which effects the system is permitted to produce.

Accountability needs a useful object

01 / See the idea

Responsibility attaches to a decision

Enlarge diagram

Telling developers that they are responsible for everything they submit is emotionally clear and operationally weak. No individual understands every dependency, every business rule, and every consequence of a large system. Responsibility that exceeds available authority becomes a way of assigning blame after the fact.

The object of accountability should therefore be a decision a person can actually make. A developer can own the accuracy of a change description and the evidence they present. A reviewer can own an assessment within an agreed scope. A service owner can decide whether the residual risk is acceptable for release. A business owner may need to authorize a change in customer-facing behavior.

These responsibilities can overlap without becoming interchangeable. A reviewer who checks concurrency correctness is not automatically authorizing a new refund policy. A manager who approves a deadline is not necessarily equipped to decide whether a database migration is reversible.

The NIST AI Risk Management Framework provides a relevant governance principle: roles and responsibilities should be clear, and executive leadership should take responsibility for decisions about AI-related risks. It is a voluntary framework, not a statement of legal liability. Its relevance here is organizational clarity. NIST AI RMF 1.0, published 26 January 2023.

Applying that principle to generated code means naming the decision, the evidence needed, and the authority that can accept or reject it. A signature without those conditions is merely a recorded gesture.

The reviewer must be allowed to stop

Imagine another hypothetical team that requires human review of every generated change. The policy sounds reassuring. In practice, the reviewer receives a large diff, an enthusiastic summary, and a deadline that leaves little time for investigation. Asking for more evidence is treated as resistance to productivity.

There is a human in the process, but the process has not made human judgment usable.

For review to carry responsibility, the reviewer needs a manageable object. That may mean smaller changes, a clear statement of altered behavior, and evidence tied to the important boundary. It also means permission to say that the available information is insufficient.

A change can be syntactically simple and operationally consequential. Replacing a condition, removing a timeout, or widening a data filter may deserve more scrutiny than a large amount of repetitive code. Review effort should follow the effect of the change rather than its visual size or the confidence of the generated explanation.

There is no need to inspect every line with equal intensity. The reviewer should understand which assumptions are dangerous to get wrong and choose checks accordingly. In the refund example, the central question concerns repeated effects after uncertainty. Formatting consistency cannot answer it.

This is also why the assistant's own explanation should be treated as a proposal for what to inspect. It can be helpful, but it cannot independently establish the adequacy of the work it describes.

Blame can make the system less accountable

02 / A concrete example

A timeout does not establish the outcome

Enlarge diagram

One objection to this approach is that explicit ownership will discourage people from using AI. If every generated defect becomes a personal failure, developers may conceal assistance or avoid useful experiments.

That objection is valid when accountability is implemented as punishment. It is not an argument for leaving decisions unowned.

A constructive process separates the person who must help correct a problem from the claim that the person acted negligently. Someone must coordinate the response, explain the decision record, and ensure that the system improves. Whether misconduct occurred is a separate question requiring its own evidence.

This distinction matters because useful incident information often comes from people admitting uncertainty. A developer who says they did not understand an external guarantee gives the organization a chance to address a missing contract or training need. A process that rewards confident explanations after the fact makes that information harder to obtain.

The same principle applies to managers. If a delivery policy systematically removes time for verification, responsibility cannot be confined to the person who clicked merge. Organizational accountability includes the conditions under which technical decisions are made.

The goal is a system that can learn from failure while keeping decisions traceable. Blame without learning creates fear. Learning without ownership can produce excellent reports and repeated failures.

Evidence should travel with the decision

The record attached to a consequential change need not be long. It should answer the questions that a future maintainer or incident responder would otherwise have to reconstruct.

What behavior changed? Which assumption makes the change acceptable? What was checked? What was not checked? Who accepted the remaining uncertainty, and within what scope?

In the hypothetical refund change, this record might identify the external operation's idempotency contract, the test covering an ambiguous timeout, and the decision to stop automatic processing when the result cannot be established safely. These are illustrative artifacts, not claims that a particular implementation has been validated.

The record should not be padded with every prompt, intermediate thought, or generated file. More material can make the important evidence harder to find. A transcript may help an investigation, but it is not automatically an acceptance record.

Nor should evidence be treated as permanent merely because it was once valid. If a dependency changes its behavior, a workload grows, or a business rule is revised, the relevant assumptions may need review. Good ownership includes knowing what would reopen the decision.

This turns documentation into an operational tool. The record tells the next person where to look and what condition would justify changing course. It does not ask them to trust a previous person's confidence indefinitely.

There is a boundary to delegation

03 / Watch the mechanism

A proposal crosses an authorization gate

Enlarge diagram

Static view. Play to see how the mechanism unfolds.

Some decisions are easy to delegate because their outcomes are cheap to inspect and reverse. Other decisions combine uncertain evidence, significant effects, and expensive recovery. The same assistant can be appropriate in both settings, but its authority should differ.

For a disposable internal script, a small check may be enough. For a change that affects customer money or access to data, the acceptance boundary should be more demanding. This is a proportionate engineering judgment, not a claim that all generated code is unusually dangerous.

The organization should also distinguish recommendation from authorization. An assistant can propose a migration. That does not mean it has permission to apply it to production. It can identify a possible refund. That does not mean it should execute the payment without the required business approval.

Keeping these boundaries explicit allows useful autonomy inside them. Excessively broad restrictions can make tools cumbersome, while excessively broad permissions can make mistakes consequential. The design task is to grant enough authority to complete a bounded job and preserve a clear route for decisions outside it.

One change contains several decisions

01 / See the idea

One change contains several decisions

Enlarge diagram

The hypothetical refund incident becomes more useful when we resist treating release as one indivisible act. A developer decides how to represent an uncertain timeout. A reviewer decides whether the evidence supports the proposed behavior. A service owner decides whether the remaining uncertainty is acceptable in operation. A business owner decides what promise the organization makes to a customer when the outcome cannot immediately be established.

These people may be the same person in a small company. The decisions are still distinct. Combining roles does not make the technical and commercial questions identical.

Suppose the developer implements a state that preserves uncertainty instead of issuing another refund. That may be technically prudent. The customer-facing process still needs to explain what happens next, who investigates, and how a delayed outcome is communicated. A correct refusal to guess can become an unresolved customer problem if nobody owns the next step.

Conversely, a business desire for an immediate answer does not establish that the system can know the answer. The organization must choose a promise compatible with the evidence its systems can provide. Asking an assistant to write a more reassuring message cannot repair that mismatch.

Accountability becomes practical when each decision has an object that can be reviewed. The developer presents a behavior change. The reviewer presents an assessment of the relevant checks. The service owner accepts an operating condition. The business owner accepts the consequence for the customer.

This is not an argument for multiplying approval meetings. In a routine case, several decisions may be made quickly. The value is that a consequential question cannot disappear merely because another part of the change was approved.

When an incident occurs, this separation also makes learning more precise. The problem may be an incorrect implementation, insufficient evidence, an unrealistic service promise, or a missing recovery responsibility. Each requires a different correction.

Authority without usable time is a paper responsibility

A reviewer may technically possess the right to block a release while lacking a realistic opportunity to investigate it. If the organization schedules review as a brief administrative step after all commitments have been made, rejection becomes socially and commercially expensive.

That pressure should be part of the analysis. A policy saying that reviewers are responsible does not create the time, information or alternative delivery plan they need. It can instead move the visible burden to the person least able to change the surrounding conditions.

Consider a hypothetical team that receives a large generated change shortly before a promised launch. The summary says that error handling has been improved. The reviewer notices that retries now surround a larger operation, but no test shows what happens after a partial effect. They can ask for evidence, yet doing so is described as delaying the project.

The organization has already shaped the decision before the review begins. It cannot reasonably interpret a rushed approval as equivalent to an unconstrained technical assessment.

The repair is not always more time. It may be a smaller change, earlier review of the consequential boundary, or agreement that a missing recovery guarantee changes the launch scope. These measures make judgment possible at the point where it can still influence the work.

They also make responsibility fairer. A reviewer should be answerable for the assessment they were authorized and equipped to make. A manager should remain answerable for the conditions that determine whether that assessment can be useful.

This is where accountability differs from a blame chain. A blame chain asks who last touched the artifact. An accountable organization asks which decisions and constraints produced the accepted behavior, and who can change them now.

Correction is part of ownership

Responsibility does not end when the change is accepted. The organization needs someone who can reconnect the result with the decision if an assumption fails later.

In the refund example, that might mean distinguishing an actual duplicated effect from a reporting error. It might mean determining which customers require follow-up and which operations remain uncertain. The correction process has technical, operational and communicative parts. A patch can stop new failures while leaving earlier cases unresolved.

This is another reason to preserve a useful decision record. The record should help the responding team identify the assumed guarantee, the evidence used at release and the condition now believed to be different. It should not merely preserve a list of people who clicked approval buttons.

An organization can then ask whether the same assumption appears elsewhere. Perhaps several services treat a timeout as proof of failure. Perhaps the problem is confined to one integration. The answer changes the scope of the response.

AI assistance can help search code, organize candidate cases or draft an explanation. Those activities remain proposals until checked against the relevant evidence. The speed of producing a list does not establish that the list is complete, and a confident incident summary does not settle an unresolved external state.

The owner of correction should therefore be able to distinguish containment, diagnosis, repair and reconciliation. Each can make progress without pretending that all the others are complete.

This distinction makes accountability sustainable. Nobody can guarantee that every future assumption will remain true. The more useful commitment is to preserve enough evidence and authority to respond coherently when it does not.

A later laboratory shows why stopping is not completion

Contemporary laboratory note, prepared 12 November 2026. The following technical evidence postdates the essay's August 2025 context.

The buffer-ownership laboratory distinguishes requesting cancellation from the consumer actually terminating. Its controlled test keeps the consumer active, requests cancellation, and checks that the owner has not returned the buffer early. This narrow result is relevant to a broader habit of thought: a statement that work should stop is not evidence that the obligations created by the work have ended.

The reusable asynchronous-source laboratory makes a related distinction between publishing a result and consuming it. Its educational provider prevents reuse while an earlier result remains unconsumed. That is a concrete software contract, not a model of moral or legal responsibility.

The analogy has a limit. Organizations are not state machines, and a passing code test cannot demonstrate that a company's allocation of responsibility is fair. What the laboratories supply is a precise example of why neighboring milestones should not be collapsed merely because they sound similar.

For the refund process, the comparable questions are whether an action was requested, whether the external effect occurred, whether that effect was confirmed, and whether the customer-facing obligation has been resolved. A report should identify which of those facts is known.

This connection keeps the essay grounded without converting it into a programming tutorial. The software examples test their own contracts. The organizational argument asks people to apply the same care when defining the decisions and obligations they accept.

Proportionate control needs an explicit boundary

The objection that this approach creates bureaucracy deserves a practical answer. Not every generated line of code needs a new committee, and not every routine change needs a bespoke evidence dossier. A low-consequence, reversible modification can often use established checks and ordinary review.

The distinction should follow the effect of the change. Does it alter who may access information? Can it repeat an external action? Does it change the interpretation of a business result? Is recovery difficult? These questions identify where a familiar implementation may carry an unfamiliar consequence.

Established controls should make routine work easier by defining what evidence is normally sufficient. They should also make exceptions visible. A reviewer who sees that the change crosses a new boundary can then explain why the ordinary check is incomplete, rather than appealing to generalized anxiety about AI.

That explanation matters for trust within the team. People are more likely to understand a request for additional evidence when it names the unresolved behavior and the decision it affects. A vague demand to be safer gives them little way to finish.

An accountable process therefore needs a stopping rule as well as a gate. Once the agreed evidence is present and the authorized owner has accepted the remaining uncertainty, the team should proceed. Reopening the decision needs a changed condition or a material gap, not an indefinite preference for more reassurance.

AI makes producing changes easier. The organization's response should be to make consequential acceptance clearer, while keeping ordinary work workable.

The name that remains after the model is replaced

Models and assistants will change. The organization still needs a reliable account of why a change was accepted and who can act when its assumptions fail.

That continuity is the real object of responsibility. It should survive a different editor, a different model, and a different employee. It lives in clear decisions, workable authority, preserved evidence, and a correction process that does not depend on reconstructing a private conversation.

Before asking who wrote the next function, ask who is deciding that its effects are acceptable. Does that person have the information to decide? Can they stop the release? Is someone prepared to own the correction if the decision proves wrong?

If those questions have no clear answers, adding a human name to a generated commit will not solve the problem. The missing component is an organization capable of taking responsibility for the software it chooses to use.