What accounting did when volume broke the check

In 1900, an audit meant checking every single transaction. All of them. It has something to say about AI code review in 2026.

The ledgers outran the clerks

Before roughly 1840, auditing was the detailed verification of every transaction in the books. Testing and sampling were not part of the procedure. Internal control was not yet something an auditor examined, because there was no need to infer anything: the auditor looked at everything, and looking at everything was possible.

Then it was not. Lee Teck-Heang and Azham Md. Ali, tracing the historical development of auditing, name the cause without hedging. The volume of transactions inside large corporations operating across widespread locations made verifying all of them impractical. Companies grew faster than audit teams could. By 1940 practitioners were writing that a “detailed examination of every entry, footing, and posting” was not necessary to obtain the value of an audit.

Nobody voted on this. There was no meeting at which the profession resolved to stop checking everything. The practice drifted, because the arithmetic left it nowhere else to go. For a period, auditors were performing one thing and describing another.

What happened next is the part worth studying.

The profession rebuilt the method and then changed the claim

Faced with a check it could no longer perform, accounting did not simply add clerks and hope. It built new machinery, and the machinery was written down where other people could inspect it.

• Materiality. A defined threshold below which an error would not change the decision of anyone relying on the accounts. Not everything matters equally, and the profession committed that judgement to paper rather than leaving it to instinct.
• Sampling. An inference from a subset to a population, with error found in the sample projected back across the whole. A defensible statistical claim, not a spot check.
• Reliance on internal control. Test the process that produces the transactions, not only the transactions themselves. Where the process holds, the population inherits some of that assurance.
• Risk-based scoping. Direct effort to where a misstatement is both likely and consequential, and record where that was and why.

Then came the move that matters most. The opinion itself changed. A modern audit report does not say the accounts are correct. It says they are free from material misstatement, and it publishes the basis for that conclusion, the standard applied, and who was responsible for what.

That is not a weaker promise dressed up as a stronger one. It is a promise that can be tested. When it failed badly enough, at Enron, the failure was legible: a statute followed inside a year, and a body was created to inspect the inspectors.

Software delivery is in 1900

Faros AI has published two years of instrumented telemetry covering 22,000 developers across more than 4,000 teams, comparing each organisation’s periods of lowest and highest AI adoption. Throughput moved as promised. Epics completed per developer rose 66 per cent, task throughput 33.7 per cent, pull request merge rate 16.2 per cent.

The downstream numbers moved further. Median time in review is up 441.5 per cent. Average time spent in code review is up 199.6 per cent. Bugs per developer are up 54 per cent, from 9 per cent in the equivalent 2025 dataset. Incidents per merged pull request are up 242.7 per cent. Code churn, lines removed against lines added, is up 861 per cent.

One figure is the whole argument. Pull requests merging with no review at all, human or agentic, are up 31.3 per cent. Faros is explicit that it does not read this as a decision to bypass oversight. It reads it as reviewers being unable to keep pace with what arrives.

LinearB’s 2026 benchmarks, drawn from 8.1 million pull requests across 4,800 organisations in 42 countries, describe the same shape from the other end. AI-assisted changes are around two and a half times larger than unassisted ones, over 400 lines at the seventy-fifth percentile against 157. Yet once a reviewer engages, they finish faster on AI work than on human work, roughly 194 minutes against 252. LinearB reads that speed as shallow inspection rather than efficiency.

Bigger population. Shorter procedure. Identical sign-off.

Sonar’s 2026 survey of more than 1,100 developers supplies the human half. Forty-two per cent of committed code is now AI-generated or AI-assisted. Ninety-six per cent do not fully trust that AI output is functionally correct. Forty-eight per cent always check it before committing. Distrust is close to universal; verification is not.

A caveat that belongs in the open rather than a footnote. Faros, LinearB and Sonar all sell into the problem their research describes, and each dataset comes from their own instrumented customers. Treat the magnitudes as directional. The direction is not seriously contested, and the honest reading is that vendors with an interest in a finding can still be reporting a real one.

The evidence is also genuinely split on one point. DORA’s 2025 research concludes that strong engineering foundations amplify AI’s benefits and protect against its downsides. Faros looked at two years of telemetry and found that high-performing organisations with mature practice degrade the same as everyone else. Surveys measure how work feels. Telemetry measures what happened to the queue. Both can be true of different things, and neither should be smoothed over to make a cleaner argument.

The claim did not move

Accounting spent decades performing a diminished check while still describing the old one, and then closed the gap by rewriting what it promised. Software delivery has reached the first half of that and not the second.

Almost every engineering policy still contains a sentence of the form: all changes are peer reviewed before merge. In organisations where roughly a third more changes reach production unread, that sentence is no longer a description of anything. It is a description of an intention.

This is the difference between a control that is documented and a control that is working. They are different states, not points on a scale, and the distance between them is not closed by writing the policy more firmly. A team that could not say what share of last month’s merges nobody read does not have a review control. It has a review aspiration and an approval button.

Accounting’s honesty was never that it kept checking everything. It was that it stopped saying it did.

The obvious lesson is the wrong one

The tempting conclusion is that software should copy the answer: sample the pull requests, review the risky ones, spot check the rest. Two things argue against it.

The first is that audit is already walking back. In June 2024 the PCAOB amended AS 1105 and AS 2301 to address audit procedures involving technology-assisted analysis, effective for fiscal years beginning on or after 15 December 2025. The board’s stated reason is that advances in technology have let auditors widen what they examine. Selecting every item in a population is now one of the recognised means of testing, alongside sampling. The constraint that forced audit to sample was human reading capacity, and that constraint is lifting. In software it barely applied in the first place: the population is machine-readable and the checks are executable. Building a cleverer way to sample pull requests may be optimising a detour.

The second argument is harder, and it comes from inside the profession being admired here. Michael Power’s work on the audit society describes verification spreading as ritual: expanding in volume and confidence while the substance thins, and reshaping the audited thing so that it can be checked rather than so that it is sound. Any industry adopting audit machinery can import that pathology alongside the mechanism. The profession that produced materiality and sampling also produced Arthur Andersen, and a literature arguing that much of what followed was ceremony.

So the lesson is narrow and specific. Take the mechanism. Refuse the ceremony. The test for whether that has been managed is whether anyone outside the team producing the work can inspect the basis of the claim and find that it holds.

What a delivery team could write down this quarter

None of the following requires a standards body, a regulator, or a budget line. All of it requires deciding something and recording the decision.

• A materiality threshold for change. Which changes must be read by a named human, and which may pass on automated evidence alone. Write the criteria, not the instinct. Blast radius, data class, reversibility, and whether the change touches an authorisation path are all better inputs than lines of code.
• A measured coverage figure. What proportion of merges last month had no human read them. Publish it monthly. A control you cannot measure is a control you are describing rather than operating.
• Gate testing rather than transaction testing. Evidence that the pipeline itself refuses what it is supposed to refuse, produced by running the refusal, not by pointing at the configuration. A gate nobody has watched fail is an assumption.
• A claim that matches the practice. Replace the sentence promising universal peer review with one that says what actually happens and on what basis. The new sentence will be less impressive and considerably more defensible.

The 1900s auditor was not negligent. The work had outgrown the method, and it took the profession several decades to say so out loud and rebuild around the admission. Software delivery has the advantage of watching the whole sequence in advance, and the disadvantage of moving through it in about three years rather than fifty.

Where else have you seen a control keep its wording long after it stopped doing the work?

Sources

• Lee Teck-Heang and Azham Md. Ali, The evolution of auditing: An analysis of the historical development, Journal of Modern Accounting and Auditing, December 2008.
• Faros AI, AI Engineering Report 2026: The Acceleration Whiplash, April 2026. Telemetry from 22,000 developers across more than 4,000 teams.
• LinearB, 2026 Software Engineering Benchmarks Report, May 2026. Analysis of 8.1 million pull requests.
• Sonar, 2026 State of Code Developer Survey, January 2026. More than 1,100 professional developers.
• DORA, State of AI-assisted Software Development and related analysis, 2025 and 2026.
• PCAOB Release 2024-007, amendments to AS 1105 and AS 2301 on technology-assisted analysis, adopted 12 June 2024.
• Michael Power, The Audit Society: Rituals of Verification, Oxford University Press, 1999.

Jason Cruz Falzon is the creator of the Cognitive Delivery Framework and the Cognitive Delivery Index. Reach him at jason@cognitivedelivery.co.uk or at cognitivedelivery.co.uk.