The mechanism worth dwelling on is not volume, it is plausibility. Meadows argues that machine-written code rarely looks lazy; it looks idiomatic and finished right up to the point where it is quietly wrong about your business logic, and no linter catches that [4]. Human review heuristics were tuned on human failure signals. Those signals are absent, so the reviewer's instinct returns a false negative and the approval lands [9].
Her two illustrative figures, a 900-line pull request [9] and the 90 seconds of scrutiny a uniform pipeline gives every change [10], sit in different paragraphs. Put them together and the implied reading rate is ten lines a second [14]. That is rhetoric, not measurement, but it names the gap the velocity chart hides.
The quantitative load in the piece rests on one study: roughly 800 developers, 41% more bugs from AI-assisted engineers, no meaningful throughput gain [2]. The column does not name it, its authors, or where it was published [c2b], which is worth knowing before anyone puts it in a board deck. If it holds, the accounting is worse than the headline. Bug count up 41% with output flat means defects per unit of shipped work also rise 41% [13]. And the column opens with the opposite feeling: teams adopting these tools, watching pull requests get bigger, and celebrating [15]. Bigger diffs are not more delivered value, and leaders should be clear about which of those two their dashboards actually count.
The three prescriptions all move work earlier, and each has a price someone has to approve. Making tests the specification means the engineer writes or signs off the intent before the generator runs [7], which spends exactly the minutes that felt like the speedup. Deterministic gates, contract tests, property-based tests, static analysis, policy checks that block known-bad patterns, are engineering projects with owners and maintenance, not settings to enable [6]. Risk-routed review requires somebody to declare, in advance and in writing, that billing logic and a dependency bump do not travel the same path [8]. That declaration is a governance artifact, and most teams do not have one.
Then the part that outlives the incident. Meadows' answer to who is accountable for agent-written code is whoever merged it, but only if the process makes that true: you need a durable record of what was generated, what was modified, what was checked, and who made the call [11]. Today that context lives in chat threads, tool sessions and people's heads, and it evaporates within weeks, well before an auditor or a postmortem asks [12]. So the practical question for anyone running this stack is a retention question. Does the merge record say which lines a model produced and which gates ran, or does it say "LGTM"?
Teams that scaled generation without scaling verification have already taken on the liability [5]. The invoice arrives as incidents, rework, and code with a human name on the commit and no human who can explain it [5].
