Code Without Provenance: The Real Risk When 41% of Your Codebase Has No Author

Provenance is the chain that connects a line of code to a reason. Who wrote it, against which requirement, with what tradeoff in mind, and what they assumed about the rest of the system. For decades that chain was implicit but recoverable. A commit had an author. The author had context. If a function looked strange, you could read the PR, ping the person, and reconstruct the intent. Code carried accountability because a human stood behind it.

AI-generated code severs that chain at the source. A model produces a plausible implementation with no model of *why* it should exist. The commit has an author in the git sense, the engineer who accepted the suggestion, but that engineer is increasingly a reviewer of output they did not reason their way to. At 41% of the codebase, you are no longer maintaining software a team designed. You are maintaining a large and growing surface of decisions that were never actually decided.

This is the part the defect statistics miss. Industry research puts the share of AI coding tasks that introduce critical flaws or security issues near 45%, and that is alarming on its own. But a flaw you can detect is a tractable problem. The harder problem is the 55% that *works*. Code that passes tests, ships clean, and runs fine in production, while encoding an assumption nobody recorded and nobody can recover. That is the line that takes you down eighteen months later, during an unrelated migration, when someone changes the thing it silently depended on.

Intent is not a nice-to-have. It is the thing that makes a system safe to change. When you can't reconstruct why code exists, three concrete failure modes follow.

The aggregate cost of this is not hypothetical. The cost of poor software quality is estimated at around $2.41 trillion, and a large share of that is not dramatic breaches. It's the slow tax of systems no one fully understands: rework, fear-driven over-engineering, incidents in code that "worked," and the velocity that quietly evaporates when a team stops trusting its own repository.

The reflex is to fix this with process. Require better PR descriptions. Mandate that AI-assisted code be documented. Add a review checklist. These help at the margin and fail at the core, for a reason worth stating plainly: provenance discipline competes against generation speed, and speed wins.

Around 80% of developers already bypass policy and guardrails. That number is the verdict on any solution that depends on humans being more diligent than the tools they use. When a model can produce forty plausible lines in the time it takes to write one honest sentence about why those lines exist, the documentation gap doesn't shrink. It widens with every commit. You cannot annotate your way out of a volume problem with a manual process.

Manual review has the same ceiling. A reviewer can confirm that generated code looks correct. They cannot, at machine throughput, reconstruct and record the intent behind every change well enough that the *next* engineer inherits real context. Review tells you the code is plausible. It does not tell you the code is *meant*, or what it's allowed to touch.

If intent can't be reliably attached at the moment of writing, it has to be reconstructed from what is true about the system. That is the shift: stop treating provenance as metadata a human remembers to add, and start deriving it from a live model of how the software actually behaves.

A System Graph is that model: a continuously updated map of services, dependencies, and CI/CD that knows what each piece of code connects to and what a given change can actually reach. It doesn't recover the author's private reasoning, and it shouldn't pretend to. It recovers something more durable and more useful: the *real* relationships and blast radius that the author's intent was supposed to respect in the first place.

That reframes the provenance question into one you can answer mechanically. Instead of "why did someone write this," you ask "what does this depend on, what depends on it, and what breaks if it changes." For maintaining a 41%-generated codebase, that is the operative question. It turns a wall of authorless code into a graph of accountable relationships, where every change can be scoped to what it touches rather than feared as potentially-anything.

It also makes validation change-aware. A control plane built on this map can run Testing Fleets that adapt as the system evolves, focusing validation on what a specific change reaches instead of re-checking everything blindly. This is where the graph pays for itself twice. Reachability-based prioritization, knowing whether a vulnerable path is actually reachable in your system, can mean 70 to 90% less exploitable exposure to triage. You get that leverage only when you have a real model of reachability. Authorless code in a context-blind pipeline gives you neither intent nor reach. The graph gives you reach, and reach is the part you can act on.

Restoring context is necessary but not sufficient. The point of knowing what a change touches is to govern what happens next, and to make the accountability that AI stripped away a property of the system rather than a property of someone's memory.

This is where the closed loop matters. Understand the system through the graph, test the change against it, reproduce what fails, remediate under governance, and verify the fix held. When a generated change needs a fix, Remediation Fleets can propose one, but a human authorizes it. Agents propose; humans authorize. That principle is the answer to authorless code: every consequential change reacquires an accountable decision-maker, and governance captures who proposed it, what evidence backed it, and who signed off, as a byproduct of normal operation.

The result is provenance that survives the people who created it. Not "Sarah wrote this in a sprint two years ago," but a standing, queryable record of what every change touched, what was validated, and who authorized it. That record outlasts the engineer, the model, and the deadline that produced the code.

You don't need a re-platform to start closing the provenance gap. You need to stop treating authorless code as if it were authored.