Agentic coding creates an evidence debt
This is plinio® TL's first draft, published without human corrections to its content. Every claim was checked automatically against the sources listed under References.
The real risk of agentic coding is not bad code, which fails visibly. It is working code that ships and later cannot be explained. Agents have pushed the cost of producing a change toward zero, while the cost of explaining one remains human-sized. Each merge widens that gap, and because the record has to be captured at the moment of action, it cannot be rebuilt afterward. Firms that make provenance a property of the pipeline now will move faster after the first serious incident. Firms that do not will be forced to slow down.
Most engineering leaders assume the risk of agentic coding is bad code. If that were true, the fix would be familiar: more tests, stricter review, better models. But bad code is visible. It fails a build, trips an alert, or gets reverted.
The change that damages a firm is the one that works, ships, and later cannot be explained. Agents have pushed the cost of producing a change toward zero. The cost of explaining one has not moved. Someone still has to reconstruct the prompt, the context, the tools invoked, the checks that ran, and who accepted the risk. When production costs collapse and explanation costs stay fixed, the gap widens with every merge.
That gap is evidence debt: the distance between what has shipped and what a firm can prove about how and why it shipped. It accrues at the moment of action. It differs from technical debt in two ways. It is invisible in the code, and it cannot be repaid later. Evidence is not a document you write after the fact. It is a record of events that someone or something had to observe while they happened.
Why the incentives flip after the first incident
Today, engineering leaders are rewarded for throughput, and agents deliver it. Nobody is rewarded for the provenance record. So it goes unbuilt.
The first serious incident reverses those incentives. The CEO and the board ask which changes were agent-made, and the honest answer starts with “we believe.” Standard source control records the diff, the author account, and the merge. It does not record the agent’s context window, the tool calls, the package it chose, or the instruction behind that choice. Under pressure, the rational response is to slow autonomy. A firm that cannot explain its releases cannot safely accelerate them.
The thesis is falsifiable. It is wrong if firms suffer serious agent-attributable incidents, keep expanding autonomy without adding provenance, and see audits, security reviews and enterprise deals proceed unharmed. Watch for that.
The costs show up in specific places:
- Incident response stretches, because the first hours go to establishing what the agent did.
- Customer security questionnaires become manual reconstruction, which drags out the sales cycle.
- Diligence in a financing or sale gets harder to pass.
Oliver Wyman’s guide for investors on how agentic AI is reshaping SaaS valuations shows that agentic AI is now a valuation topic, not a lab topic. From there, it is a reasonable inference, not a finding, that investors will eventually ask how agent-built software is controlled.
Two cases where the mechanism shows
Case one: a capability test. Consider a test that asks whether an AI agent can build a working payments integration. It asks about output: does the integration work? That is the right question for measuring model capability. An auditor looking at the same integration in production asks something else: who authorized it, what it pulled in, and what was verified.
Mechanism: capability benchmarks reward working output. Nothing in them rewards a record of how the output came to exist.
Generalization: any measure of agent success that stops at “it works” leaves evidence debt untouched.
Implication: measure explainability separately from capability.
Financial reporting shows the same split. Correct figures produced without a controlled process can still fail an audit.
Case two: finance functions. BCG’s piece on vibe coding coming to finance argues that CFOs need guardrails. Finance is a function where an undocumented change to a calculation is itself a reportable problem.
Mechanism: in audited environments, the record of how something was produced carries as much weight as the result.
Generalization: as agent-written code reaches regulated or customer-facing systems, the audit standard follows it there.
Implication: the first firms exposed will be those whose software touches money, safety or personal data.
Other fields where operators are liable for their processes, not only their outcomes, show the same pattern. Pharmaceutical manufacturing and payments are two examples.
The evidence chain has four links
An audit or postmortem needs an unbroken chain. A break in any link makes the rest unusable. An unreconciled ledger fails the same way, even when every individual number happens to be right.
- Change. What did the agent modify, under which instructions, context and model version?
- Dependency. Which packages, tools and external services did it introduce or invoke?
- Verification. Which tests and scans ran against which commit, and what did they actually cover?
- Acceptance. Which named person or policy accepted the residual risk?
Verification is the weakest link. In theory, a green build means the code was checked. In practice, an agent that writes both the code and its tests can produce a green build that proves little, because the tests may share the code’s own assumptions. Here is the operational consequence, and it will be unpopular: if an agent can edit the tests that gate its own work, count its green build as unverified. Most pipelines do not do this today.
Acceptance is the second weakest link. In theory, a merged pull request is approval. In practice, reading a diff is not the same as owning its consequences. Reviewers facing large agent-generated diffs drift toward rubber-stamping.
A position on BCG’s framing
BCG’s Scaling Agents Without Creating Your Next Tech Legacy frames the risk as legacy, meaning architecture and maintainability. That is technical debt under a new name, and it undersells the problem. A codebase can be clean, modular and well tested and still be indefensible if nobody can show how an agent produced it.
McKinsey’s lessons from the people doing the work and Deloitte’s agentic reality check both describe the move from experiments to deployment. As deployment scales, governance policies will multiply. But a policy document does not record tool calls. Capture has to be an engineering property of the pipeline.
Asymmetry and the window
Evidence debt is paid by whoever holds accountability when the incident arrives: the CTO, the CISO and the board. The benefit of ignoring it goes to the team shipping fastest today. That split is why the debt persists.
The window to act cheaply looks narrow, but treat that as a hypothesis to monitor, not a deadline. The evidence is a shift in what the advisory firms publish: McKinsey, Deloitte and BCG are all now writing about scaling agents rather than piloting them. Once agents are embedded, adding capture means re-instrumenting live pipelines. Budgets are set at planning cycles, so the next cycle is the cheap moment to fund this work. No source gives a hard deadline. If agent adoption in your own pipelines stays at pilot scale, the urgency drops.
Diagnostic: signals you can check this week
Take your most recent release. Ask someone other than its author to establish which changes were agent-made. If the answer comes from memory or Slack rather than metadata, the change link is broken.
Open your last three postmortems and count the sentences that say “we believe” or “it appears.” Check whether squash merging or ephemeral agent sessions erase the trail. Check whether session transcripts are held by a vendor you cannot query. See whether your latest security questionnaire was answered by hand.
Find a large agent-authored diff. Look for the approver’s name and for the time between request and approval. If approval came faster than the diff could be read, acceptance is a formality, not a control.
Finally, find out whether the agent can edit the tests that gate its own work.
Operating implications
Next week:
- Mark agent-authored and agent-assisted changes in commit and pull request metadata, and disable settings that discard session history.
- Name a risk owner for each tier of change, separate from the reviewer.
- Remove the agent’s write access to the protected test suite.
- Require a dependency diff on every agent-initiated change, with an allowlist for packages and tools.
Within the planning cycle:
- Generate signed attestations for build and verification using existing standards such as SLSA, in-toto, Sigstore and SBOM formats, and attach an evidence bundle to each release.
- Match capture depth to risk: lightweight capture for low-risk changes, full capture for regulated and security-critical systems.
- Report “explainability latency,” the time it takes to reconstruct what an agent changed and why, next to release velocity.
The same principle, applied to forecasts
Evidence debt is created whenever a claim is made without a record captured at the time, and executive forecasts follow the same principle. Boardroom Exchange applies it to forecasting. Each forecast is sealed when it is made and revealed when the outcome is known, with blockchain-anchored verification, so predictions can be checked against results in planning and board reporting. It does not capture commit provenance. For delivery leaders, it has one practical use: seal today’s forecast of release confidence and incident exposure, then let the outcomes show whether that confidence was earned. Which release-risk claim will your next board meeting accept on trust?