The Uncredited Co-Author: Code Provenance in AI-Assisted Custom Software
Photo: DFID - UK Department for International Development, CC BY 2.0, via Wikimedia Commons
A decade ago, a company commissioning bespoke software could reasonably assume that every line in the delivered repository had been typed by a named engineer, checked by a second named engineer, and tied to a ticket in a tracker. Few executives ever verified that assumption, but it held well enough to support the warranty language, the indemnification clause, and the security questionnaire that traveled with the deal.
That assumption is no longer safe. AI coding assistants are now standard equipment in the delivery toolchains of most custom software firms serving US clients. They complete functions, refactor modules, draft test suites, propose migrations, and in some shops generate entire components from a prompt. The productivity gain is genuine and should not be dismissed. So is the accounting problem: when an assistant contributes to a codebase, the chain of authorship that procurement, legal, and security teams rely on acquires a link that almost nobody is documenting.
An inventory problem wearing the costume of a tooling debate
The question is not whether AI assistance belongs in professional software delivery. In 2026 it is already there, embedded in the editors engineers open each morning. The question is whether the buyer can answer four basic questions about any file in the repository: who produced it, what did they consult while producing it, who reviewed it, and under what license does it arrive.
Most statements of work are silent on all four. That silence is comfortable during delivery and expensive afterward, particularly when the software becomes collateral in a financing round, a diligence exercise, or an acquisition.
Three records every provenance trail must carry
A workable provenance practice rests on three artifacts, none of which is exotic.
The first is attribution. For each significant unit of code, the record identifies whether it was written by a person, drafted by a model and edited by a person, or generated wholesale and accepted. Attribution does not need line-level granularity to be useful; file-level or module-level disclosure catches the overwhelming majority of risk at a fraction of the administrative cost.
The second is review attestation. Attribution without review says little. What matters is that a named engineer has confirmed comprehension of the code, not merely that a continuous integration check passed. The distinction is critical: a machine can produce plausible code that no human on the team can safely modify six months later, and no automated gate detects that condition.
The third is origin disclosure. Assistants occasionally reproduce material with licensing obligations attached. A record of which tools were used, whether any retrieval or contextual grounding was involved, and how outputs were screened for third-party overlap turns an unanswerable question into a documentable one.
Where contract language earns its keep
Provenance clauses fail when they are vague. Language that requires the vendor to use AI responsibly means nothing in a dispute. Four provisions carry actual weight.
Require disclosure of the tooling categories in use, updated when the vendor changes providers. This is not a request for trade secrets; it is a request for the class of tools touching client code.
Require a provenance ledger as a contractual deliverable, submitted with each milestone and at final acceptance, in a format the client can retain.
Require that any AI-generated code entering a production branch has passed human review against a defined standard, and that the review is recorded in the repository rather than in a private chat log.
Finally, confirm that intellectual property representations and indemnities extend to machine-assisted output. Many vendors have quietly narrowed these warranties while leaving the surrounding language untouched. Buyers should read the intellectual property section of a 2026 statement of work against the 2021 version and note what changed.
Review standards are where provenance actually lives
Contracts create the obligation; engineering practice discharges it. The practical shift is from asking whether code is correct to asking whether code is understood. A useful standard requires that the reviewing engineer be able to explain the change, modify it without assistance, and describe its failure modes. Where an assistant generated a substantial block, the review should include at least one deliberate modification, which forces comprehension in a way that passive approval does not.
Teams should also maintain a short internal register of modules that were substantially machine-drafted. That register is not a mark of shame. It is a maintenance planning tool, and it tells a future engineering lead where to concentrate onboarding effort.
The audit trail as a living artifact
Provenance records that are compiled once at delivery and never updated describe a system that no longer exists. The ledger should be regenerated as part of the release process, small enough to be reviewed in a standing meeting, and stored alongside the code rather than in a vendor's project management tool. When a client later exercises an audit right or begins technical due diligence, the difference between a maintained ledger and a reconstructed one is measured in weeks.
The strategic argument is straightforward. Custom software is bought to create an asset the organization controls. An asset whose origins cannot be explained is controlled only in the loosest sense. Establishing provenance now costs a few process changes and a clause negotiation. Establishing it later, during diligence or after an incident, costs considerably more, and the answers may no longer be available at any price.
