Suppose something breaks in production at 3am. Someone pulls up the history, runs git blame on the offending line, and finds a name.

Then the story gets less tidy. An agent generated the code. An engineer accepted it in a batch of forty changes on a Tuesday they barely remember. The tests passed. The policy checks were green. Another agent reviewed the diff. Perhaps nobody opened the file at all because the system had produced enough evidence to call the change safe.

So who is to blame? The robot?

It is the wrong first question. A robot has no duty of care, no professional judgment, no authority to exercise and nothing to lose. You cannot hold it responsible. But pointing to the human who clicked approve is not much better if that person had become the last mechanical step in an automated process.

The useful questions come earlier. What did the agent change? What was it asked to do? What evidence supported the change? What did that evidence fail to cover? Who decided that the evidence was sufficient? And who had the authority to stop the system?

That is where attribution becomes a control problem.

A robot cannot carry responsibility

Responsibility belongs to people and organisations because they can make choices, accept duties and change what happens next. The engineer can reject a change. The team can narrow an agent's permissions. The organisation can decide that some work needs a security specialist, a domain expert or a second pair of human eyes.

An agent can do none of those things on its own authority. It acts inside a system that people designed and permitted. Treating it as the accountable party does not make accountability modern. It gives everyone else somewhere convenient to point.

That does not mean the human nearest the merge button automatically owns every failure. Responsibility has to follow authority. If a reviewer cannot inspect the evidence, challenge the acceptance rules or stop the rollout, calling them accountable merely transfers blame to the person with the least control.

Before we decide whose judgment failed, we need a reliable account of what happened. That is the job of provenance. It supplies evidence for accountability, but it does not assign blame.

git blame never told the whole story

For years, git blame was a useful shortcut. It associated a line with the last commit that changed it and the author recorded on that commit. Teams often treated that as authorship because, in practice, the gap was small enough.

Agents have made the gap impossible to ignore. The recorded author may have written the code, edited a suggestion, accepted a patch without reading every line, or simply committed work produced elsewhere. The command still prints a human name, but the name now answers a weaker question: who recorded this change in Git?

Thoughtworks describes the same limitation: existing tools cannot tell us whether a contribution came from a human, an AI system or both. The mechanism still works. Our interpretation of it no longer does.

That matters during an incident, but it also matters during ordinary review. A diff shows the resulting code. It does not show the instruction, the discarded attempts, the tool calls, the assumptions or the evidence that persuaded someone to accept the result.

"Correct" is an evidence case

The uncomfortable possibility is that opening every changed file will stop being the default. The volume of agent-produced code can already make complete line-by-line review unrealistic. Pretending otherwise does not preserve human control. It encourages hurried reviews that look responsible in the audit log and feel empty to the person doing them.

The alternative is not to trust a single green badge. It is to make a case from several independent pieces of evidence.

Tests show that selected examples behaved as expected. Type systems and schema checks establish constraints on shape. Linters and policy engines reject known classes of mistake. Security scans look for particular weaknesses. A review agent can challenge the implementation from another angle. A sandbox run can show what the change actually did. A canary can show how it behaved under limited real traffic. Formal verification, when it is practical, can prove a stated property under stated assumptions.

Each result is a datapoint. None means "the code is correct" without qualification. A test suite only covers the behaviours it exercises. A policy only enforces the rules someone wrote. A formal proof is only as useful as its specification and assumptions. A second agent can share the first agent's blind spot.

The reviewable object therefore needs to be more than the diff and more than a pass or fail summary. It should expose the claim being made, the evidence for it, the assumptions behind that evidence, the known gaps, the blast radius and the rollback path. Green is evidence, not a verdict.

This is the practical extension of the argument I made in the death of vibe coding: no change should enter the system without evidence. The harder question is who decides when the evidence is enough.

No single trace can answer everything

Agent Trace remains a useful part of the answer. It is a small, vendor-neutral RFC for recording whether code was contributed by a human, an AI system, a mixture of both or an unknown source. Its trace record can associate files or lines with contributors and the conversation that led to them.

Its restraint matters. Agent Trace does not claim to assess quality, determine legal ownership or reconstruct training data. It records origin. That is necessary, but origin is only one layer of the evidence case.

Other tools now cover adjacent questions:

  • Git AI attaches line-level AI attribution to commits through Git Notes and links the result to the agent, model and session.
  • Entire connects coding-agent sessions to Git history, preserving transcripts, file changes, tool activity and checkpoints that can be inspected later.
  • OpenTelemetry's generative AI conventions record what agents, models and tools did at runtime. That answers a different question from who authored a line.
  • SLSA provenance describes how an artefact was produced, including its inputs and build process. It connects the reviewed change to what was actually built.
  • Feedback sensors for coding agents bring deterministic checks such as compilers, linters and tests into the agent's own loop, so failures can be found before the work reaches a reviewer.

These are not interchangeable products chasing the same problem. They answer different questions: where the code came from, what happened during the session, what the running agent did, what was built and which claims were checked. Together they can form a chain of evidence. None can certify that a human exercised judgment.

There is newer research pushing provenance further. A 2026 paper on automated and explainable provenance for AI-generated code argues for tracing output back not only to prompts but eventually to training examples, broader data properties and internal model components. That is a research direction, not a control teams can buy today. The distinction matters. We should use the evidence we can capture without pretending it explains more than it does.

The trust frontier is fragile

We have all seen engineers approve a change without completing the review they were supposedly performing. Sometimes it is laziness. More often it is queue pressure, boredom and a system that has been right often enough to earn trust.

That trust is a good sign. A useful engineering system should become dependable. Nobody wants experts to recheck every routine fact forever. The risk appears when trust changes from an informed judgment into the absence of judgment.

An approval record cannot tell the difference. It can prove that someone clicked a button at 14:03. It cannot prove that they understood the evidence, noticed what was missing, challenged an assumption or had enough domain knowledge to recognise the unusual part.

This is why "human in the loop" is not enough. I have argued before that approval queues tend to become throughput systems. The next problem is harder: once the code is no longer routinely opened, how do people remain genuinely in charge?

The frontier is fragile. We need enough trust to benefit from automation and enough doubt to keep exercising expert judgment. Push too far toward suspicion and every gain disappears into ceremonial review. Push too far toward trust and the expert becomes an approver whose name is retained after their agency has gone.

The knowledge most likely to matter is often the knowledge least likely to be encoded in a test. A change can satisfy its unit tests and still violate an operational constraint, a product promise, a regulatory obligation or an assumption held by another team. Subject-matter experts are valuable because they know which questions the automated case has not learned to ask.

Keep people in charge of the acceptance system

Human control does not require a person to retype or reread every line an agent produces. It requires people to control the conditions under which machine work is accepted.

That starts before generation. Someone has to define what must remain true, which systems the agent may touch, how much uncertainty is acceptable and which changes need specialist review. Those decisions belong to accountable owners, not to the agent that will later be evaluated against them.

The evidence should also be independent enough to deserve trust. The same agent should not be the sole author, reviewer and judge of its own work. Deterministic checks, independent review and runtime evidence catch different failure modes. Disagreement between them is useful information, not noise to hide behind one combined score.

Review effort should follow risk. Routine, reversible changes with well-understood checks can be automated and sampled. Changes with a large blast radius, weak coverage, novel behaviour or important domain consequences should reach someone with the expertise, context and time to decide. The goal is not to put a human everywhere. It is to put judgment where it can change the outcome.

Most importantly, the person described as responsible must retain practical authority. They need to be able to inspect the underlying code, reject the evidence, request another test, narrow permissions, stop a rollout and change the rules for next time. Engineers who can only approve are not in charge.

Teams should watch the control system too. If approvals become faster while review queues grow, overrides disappear and exceptions are routinely waved through, that is not proof of confidence. It may be evidence that attention has collapsed. Incidents, near misses and expert overrides should feed back into the tests, policies and routing rules, so the system learns without making the next reviewer carry the same hidden assumption.

This is part of the heavy system beneath a small team's speed. The machinery is not there to remove responsibility. It is there to give responsible people better leverage and a record they can challenge.

Responsibility starts before the merge

Return to the incident at 3am. A useful record would tell us which instruction led to the change, which parts came from an agent, what evidence was presented, what assumptions and waivers were recorded, who set the acceptance threshold and who authorised the deployment.

That record would help people reconstruct the causal chain. It still would not decide who is at fault. Attribution is fact; accountability is judgment. The judgment must consider whether the controls were reasonable, whether the evidence matched the risk and whether the people involved had the knowledge and authority to act differently.

If the only answer is "a human approved it", the failure happened earlier. The organisation preserved a click and lost the judgment it was meant to represent.

We should not preserve human control by making people perform machine-speed code review forever. We preserve it by letting them set the boundaries, choose the evidence, demand exceptions, bring in expert knowledge and stop the system when the case is not convincing.

The agent can leave a trace. Only people can take responsibility for what follows. To do that, they must remain more than approvers.