Verification Is Not Accountability

Engineering organizations used to know who owned a change, because a person wrote it and another person approved it. The record was thin, a commit and a merge, but it pointed at humans and it held. Coding agents changed that. Generation moved to machines while approval stayed with people. So the approval is now the only human decision left in the path, and it happens at volumes nobody reviews the way that record implies.

That leaves a question most organizations cannot answer about their own repositories. When an agent-authored change fails in production, who accepted the risk, and on what basis? Not who clicked approve, that part is easy to find. Who understood what the change touched, decided it was acceptable, and would say so in an incident review three weeks later, when retries start hammering a downstream service that was never built for them.

We got very good at answering “is this code sound?” and barely started on “whose decision was this?”. The industry treats the first as if it settles the second. It doesn’t, and this essay is about the gap between them.

The Part We Solved

It’s worth starting with what the industry got right, because it got a lot right.

At Google, AI went from more than a quarter of new code in October 2024 to 75% of new code by April 2026. Pichai was careful to describe it as generated by AI and then approved by engineers. Discount the CEO arithmetic as much as you like, the direction holds. At the frontier, generation is the default and approval is what the humans do.

The tooling followed the volume. In March 2026 Sonar introduced the Agent Centric Development Cycle, a loop built for agent-scale code: Guide, Generate, Verify, Solve. Analysis runs while the agent works, and a remediation agent repairs findings and re-verifies its own fixes. That’s the verification layer industrializing, and it needed to. If code is written at machine speed there is no other way to check it.

But look at those four stage names. Guide, generate, verify, solve. None of them is own. The loop runs end to end, from prompt to merged fix, without a single human decision recorded anywhere in it. That’s not a flaw in one vendor’s framework, it’s the shape of the whole market. We industrialized the answer to “is this code sound?” and left “whose decision was this?” where it was in 2022.

What the Delivery Data Shows

If verification were the whole problem, the system-level numbers should have improved as the tooling matured, and they didn’t.

DORA’s 2024 report estimated that a 25% increase in AI adoption was associated with a 7.2% decrease in delivery stability, alongside a small decrease in throughput. The same respondents reported better flow and higher individual productivity. So the individual got faster while the system got less stable. A year later the 2025 report found throughput had flipped, AI adoption now associates with faster delivery. The stability association did not flip. These are estimated associations across large survey populations, not controlled experiments, and DORA says so plainly. But two consecutive years pointing the same way deserve attention.

DORA’s explanation is close to mine. Teams adapted for speed while the control systems around them, automated testing, version control discipline, feedback loops, didn’t keep up, and bigger change batches carry more risk. I’d say it more plainly. Code review was built for a diff a colleague could walk you through and defend, a couple of hundred lines. An agent rewrites thirty files in a few minutes. Generation runs on compute now, review still runs on somebody’s attention, and only one of those has scaled. The review step doesn’t disappear when that happens, it just stops meaning what it used to. I haven’t seen an engineering organization where review throughput kept pace, mine included.

So the rubber stamp isn’t a discipline problem, and treating it as one produces policies nobody follows. It’s what you get from a queueing system whose arrival rate exploded while its service capacity stayed flat. You fix that by changing what the system records and enforces, not by writing a sterner review guideline.

Verification Is Not Accountability

The obvious objection is that review already handles this. A pull request has an approver, the approver owns the change, and agents don’t change that. Strictly speaking, that’s true. But look at what the approval has actually become.

Verification is about the artifact. The code compiles, the tests pass, the scanner finds no known vulnerability class, the gate is green. Accountability is about a decision. A named person understood a specific risk, accepted it, and can answer for it later. The green checkmark only gives you the first one. We’ve drifted into reading it as the second, because on screen the two look identical, an approval and then a merge.

Regulators have a name for this failure mode. The EU AI Act’s human-oversight article requires that people overseeing high-risk AI systems stay aware of “automation bias”.¹ That is the documented tendency to over-rely on automated output precisely because it is usually right. It’s legal text describing the accept click. And there’s something uncomfortable in it. The better verification gets, the more sense it makes to stop reading, so improving the tooling makes the click mean less, not more.

I should be clear about one thing. Most changes deserve no ceremony at all. A generated utility function, a test fixture, a documentation string, waving those through is the right call. Any process that demands theatre for them will be routed around within a month. The problem is that today the wave-through and the considered decision leave exactly the same trace. Both say “Approved”, and nothing in that record tells you which one you’re looking at.

Decision Lineage

I argued in April that AI didn’t break accountability, it exposed where accountability was never properly engineered. What’s missing is a control plane that makes ownership observable instead of assumed. This essay is about the record that control plane has to keep. Call it decision lineage: four facts for every change that reaches production, captured while they’re still true rather than reconstructed after the incident.

Who or what generated it. Human, agent, or the usual blend, with tool and model identity when an agent was involved. Most organizations can only answer this today by asking the author, assuming they can find one.

What a human actually reviewed. Not the approval bit, the review depth. Read line by line, sampled, delegated to the gate, or auto-approved under policy. Recorded as an explicit state, not inferred later from how confident the approver sounds.

The blast radius. What the change can plausibly break: data exposure, availability, money movement, compliance surface. Half the value here is that somebody thinks about it for ten seconds before the merge instead of for the first time on the incident call.

The owner. The named human accepting the residual risk. Not the committer by default, and not “the team”. A person whose acceptance is on the record. Most engineering leaders I talk to haven’t made this decision yet, and they will have to, ideally not during the incident that forces it.

This isn’t git blame with extra steps, and it isn’t supply-chain provenance either. SLSA and in-toto attestations answer “what produced this artifact”, and they answer it well, but they’re statements about artifacts. Lineage is a statement about a decision, what a person chose to accept and on what basis. An attestation can prove an agent built the binary, but not whether anyone decided that was acceptable.

The first place this pays for itself is the postmortem. Incident review works by walking back a chain of human decisions, and agents didn’t remove the decisions, they removed the record of them. With lineage, “who decided this, and what did they know at the time” is a query. Without it, reviews land on the same weak conclusion every time, that nobody specifically decided anything, so the process must tighten everywhere. That’s how governance debt compounds.

Where the Record Has to Live

The only place every change already goes through is the merge path, the pull request and the quality gate sitting on it. That’s where the facts are still fresh, and it’s the one point in the pipeline that can actually stop something. If you separate it into a wiki, a governance document, or something similar, it will become obsolete eventually. Following GitOps here will save you time. I’ve had to do the reconstruction version of this in a regulated programme. It costs many times what capturing the same evidence as the pipeline ran would have cost.

So the gate has to do more than it does today. Right now it answers one question, may this code proceed. It also needs to answer whether the decision record is complete, and what that record has to contain for this particular class of change. In practice that means three things. Read generator identity from commit and tool metadata. Require a declared review depth before merge. Scale that requirement with blast radius, which static analysis can increasingly infer from what the diff touches, auth code, data access, payment paths. Incomplete record, no merge.

That’s an uncomfortable inversion for most teams, so I’ll say it plainly. The code can be perfect and the merge still blocked, because code nobody owns is exactly the failure mode the stability data points at.

The verification vendors sit on this chokepoint. Over the next two years I’d expect the real competition in that market to be about who moves first from verifying artifacts to recording decisions. It isn’t a large technical step for them. They parse the diff, run inside CI, hold a policy model and issue a blocking verdict. What they would add is a decision record attached to that verdict: generator identity, a declared review depth, an inferred blast radius, and a named owner. A standalone governance product has to win a place in the pipeline before it can do any of that, which is why I doubt that’s where this lands. And being late costs more than a feature race would. The buyer’s question moves from “does your tool find problems” to “can your tool show me who decided”. A scanner that only answers the first ends up as a component inside somebody else’s answer to the second.

And one more thing, for the platform engineers who’ll get asked to build this. A record of review depth looks like surveillance the first time you see it. It isn’t. Platform engineering is developer empathy at scale. The platform carries the bookkeeping so the developer doesn’t have to perform it. A record that honestly says “sampled, low blast radius, owned by policy” protects the engineer who waved through a utility function. Today’s undifferentiated “Approved” protects nobody. Without a recorded review depth, that engineer is just the last name on the commit.

Three Floors Underneath

Any argument about governance rests on three different floors, and they are not equally solid. There is the statutory floor, what the law will eventually require of you. The procurement floor, what your customers ask before they sign. And the audit floor, what your auditors test every year. Most leadership teams watch only the first, which happens to be the only one that moves.

The statutory floor moved twice this year. In Europe, the Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July and deferred the AI Act’s Chapter III obligations for high-risk systems. Standalone systems under Annex III now apply from 2 December 2027 instead of this month, and AI embedded as a safety component in regulated products from 2 August 2028.² Most of what I would have cited here went with it: the logging, deployer-transparency and human-oversight obligations of Articles 12 to 14, including the automation-bias language above, and the Annex IV requirement that technical documentation describe how a system was developed and which tools built it.³ Article 50 transparency duties and the obligations on general-purpose model providers kept their original schedule. So the part of the Act that deals with how software gets built and owned is now sixteen months further out.

Why it moved matters. The deferral is unconditional, the new dates hold whether the harmonised standards arrive or not. But the schedule gave way because those standards weren’t ready, which is to say the industry could not yet describe what conformity looks like. Nobody decided the obligations were wrong.

In the US it moved further and faster. Colorado passed the first comprehensive AI statute in the country. Like the state privacy laws it bound anyone doing business in Colorado rather than anyone headquartered there, so it reached plenty of non-US vendors too. SB 24-205 was due on 1 February 2026, a special session pushed it to 30 June, a federal court blocked enforcement in April after a constitutional challenge, and in May the governor signed SB 26-189, which repealed it outright and replaced it with a notice regime that doesn’t start until January 2027.⁴ Compliance programs were sized against that law, and it went from first-in-the-country to repealed in under two years without ever taking effect. Above the states, an executive order signed on 11 December 2025 set out to preempt state AI regulation and directs federal challenges against the state laws still standing.⁵

So if you sized your accountability work to a statutory deadline, which deadline was it? For most organizations the honest answer is whichever one was easiest to put on a slide. All of them have moved since.

One detail from Colorado is worth noting though. When that legislature cut its AI law back to what it could actually agree on, the notice obligations still came with a three-year record-keeping requirement. They dropped the duty of care and kept the records.

We should be clear here, because overselling regulation is its own kind of failure. These obligations bind high-risk or consequential systems, hiring, credit scoring, medical devices, critical infrastructure. They don’t bind your average repository, and nothing in any of this audits a CI pipeline for its own sake.

The procurement floor has no deferral mechanism, because a customer asking how your software came to exist isn’t waiting on a harmonised standard. The clearest example isn’t European at all. Since March 2024, software producers selling to the US federal government have signed the CISA Secure Software Development Attestation Common Form, issued under Executive Order 14028 and OMB Memorandum M-22-18. They attest that they follow the practices in the NIST Secure Software Development Framework. The chief executive or a designee signs it personally, on behalf of the company, and a false attestation carries False Claims Act exposure.⁶ So a named individual is putting a signature against how software was built. And they are signing for a development process that produces less and less evidence about itself.

The audit floor is the oldest, and the one most organizations already owe. Under section 404 of Sarbanes-Oxley, IT general controls over financially relevant systems have required the same thing for roughly twenty years. A change has to be authorized, tested, and approved by someone other than whoever made it. An external auditor tests that evidence every year.⁷ No AI deadline attached, and it was never deferred. It applies to every US-listed company today, and an agent-authored change to a system in SOX scope still has to produce that evidence. I was doing FedRAMP Moderate authorization a few years ago, on Azure Government, and the controls themselves were rarely the hard part. What consumed the time was producing evidence that changes had been reviewed and approved by someone with the standing to approve them. The pipeline either had that or it didn’t. Nobody calls this AI governance. But a good share of the organizations now arguing about whether AI accountability work is premature already owe the record, they just owe it under a different name.

So treating any of these dates as a reprieve is expensive. Sixteen months is roughly what this takes. Retrofit a decision record into the merge path of a large estate, agree what a declared review depth means, and build up enough history for the record to be worth querying. Start when a date arrives and your first job is reconstructing everything merged in between. In any case the AI Act was never really what justified decision lineage. The delivery data was the argument, and that has no application date. What the statutes added was enforceable language for what accountable automation means, and so far every rewrite of them has kept the record-keeping.

A Blast-Radius Lens

The frame that keeps all this proportionate is simple. Put the two properties the lineage record makes explicit on two axes, blast radius against review depth.

Three of the four quadrants are fine. Low blast radius with shallow review is what agents were built for, let policy own it and record it honestly. Low blast radius with deep review is attention you’ll reclaim as soon as you can see it. High blast radius with deep review and a named owner is the system working. The fourth is the problem: high blast radius, shallow review, recorded as though it were owned. The delivery data suggests it’s been filling since 2023, and nothing in an undifferentiated approval flow will ever show it to you.

Reviewing harder won’t empty it, attention doesn’t scale that way. It empties when both axes are explicit per change and the gate enforces the diagonal, ceremony proportional to consequence.

Where to Start

If you’re an engineering leader wondering what to do next week rather than next quarter, four moves.

Measure the gap on one change. Pick an agent-authored change that merged into a consequential path last month. Try to reconstruct the four facts: generator, review depth, blast radius, owner. However long that takes you is your gap, measured. In April I suggested the same test for provenance. The lineage version is harder and more useful.

Define what review depth means. Not a policy document, a short list your teams will actually pick from: read line by line, sampled, delegated to the gate, auto-approved under policy. Four values. Argue about them once, then put them in the merge template.

Use the blast-radius signals you already have. Your static analysis knows when a diff touches auth, data access, or payment paths. Start with those three. You don’t need a risk taxonomy to begin, you need one signal that reliably separates the changes that matter from the ones that don’t.

Decide who declares and who owns. These are different people more often than teams expect. Whoever reviewed declares the depth. The owner accepts the residual risk, and that is not the committer by default and not “the team”.

Four moves, and none of them is a six-month programme.

The question in front of engineering leadership isn’t “who wrote this?” any more. The industry answered that one, increasingly not a person, and that answer is fine. The question that decides whether delivery stays stable, audits stay short and postmortems stay useful is the one the last four months have sharpened. Did we build a system where ownership stays real under AI-assisted development? Industrial verification tells you in seconds that the code is sound. It can’t tell you that anybody owns it.