Core claim: Most software teams can no longer answer the question “who — or what — wrote this line of code,” and the moment they need the answer, it is too late to create one: provenance evidence can only be recorded while the work happens, never reconstructed afterwards.

The question changed before the tooling did

For decades, “who wrote this?” had a lazy but workable answer: git blame. The name on the commit was a person, the person had a keyboard, and nobody asked further. AI-assisted development quietly broke that chain. A commit authored by a human may contain code proposed by a model; an agent may produce an entire pull request that a human merely approved; a pair session may interleave both in the same function. The committer field still shows a name — but it now answers “who pressed the button,” not “who did the work.”

None of this is hypothetical bookkeeping. Buyers running technical due diligence ask for the AI share of a codebase. Customers send vendor assessments asking which parts of a delivery were machine-generated and how they were reviewed. Insurers and auditors ask how AI-written changes are supervised. Today, most teams answer these questions with estimates, because their tooling records outcomes (the code) but not origination (who produced it, under whose review, with what evidence).

Regulation is turning an awkward question into a liability

The European Union has decided that software is a product. Under the revised Product Liability Directive (EU) 2024/2853, software — including AI systems — falls under product liability rules, with member state implementation due by 9 December 2026. When a defective product causes damage, the evidentiary burden shifts in ways that reward manufacturers who can document how their product was built, reviewed and maintained.

It does not stop there. The Cyber Resilience Act (EU) 2024/2847 requires manufacturers of products with digital elements to maintain technical documentation of their secure development process, with reporting obligations for actively exploited vulnerabilities applying from 11 September 2026. And the AI Act (EU) 2024/1689 — even after the 2026 “Digital Omnibus on AI” (EU) 2026/1744 postponed several high-risk obligations — kept its Article 50 transparency requirements in force as of 2 August 2026.

The common denominator: each of these regimes assumes you can show your work. A development process you cannot evidence is, for regulatory purposes, a process that did not happen.

Evidence must be recorded, not remembered

Here is the uncomfortable property of provenance: it is one of the few things in software that cannot be fixed later. You can refactor code, rewrite documentation and patch vulnerabilities retroactively. You cannot retroactively prove who wrote something eight months ago, under which review, with which tests passing — the information either was captured at the moment of change, or it is gone. Reconstructions from memory and chat logs are estimates wearing a suit.

What a credible answer looks like is well understood from other engineering disciplines: an append-only record, written at the time of the event, carrying enough metadata to identify the actor (human or machine), the change, the review and the verification — and structured so that a third party can check its integrity without trusting the party that produced it. Evidence, not assertions. It is the difference between a logbook kept during the voyage and a story told at the harbor.

The teams that start recording now get something their competitors cannot buy later: a continuous, verifiable history that begins before anyone demanded it. The teams that wait will meet the question — from a buyer, a customer, a regulator or a court — with an estimate.

The question “who wrote your code?” is already being asked. The only thing you get to choose is whether your answer is evidence or anecdote.

Sources