When code becomes write-only, the tests become the reviewable artifact

Phillip Mortimer told QCon London that AI makes all code write-only: too dense to read, so the tests define the behaviour and become the documentation ^{[1] [3]}. The operational consequence is larger than the slogan, because if humans cannot review generated code line by line without becoming the bottleneck ^[5], the artifact an organisation actually inspects has to move from the code to the tests and the alerts, and that is a reorganisation of process rather than a tool you buy.

Mortimer's precedent is that some languages were always write-only by design, trading readability for power and performance; he named APL and regular expressions ^[12]. The second principle follows from the first: code is disposable, because debugging dense code is harder than replacing it, so you keep the tests, throw away the code and write it again ^[4]. Anyone who has maintained a large regex library recognises that trade. What is new is the proposed scale.

He proposes two substitutes for human reading. The first is detailed tests plus automated review ^[6]. In an interview with InfoQ he described the mechanism: a coding agent harness invoked as a CI action, carrying a skill that encodes what a senior developer would look for, able to post comments, request changes, or approve a pull request ^[8]. He said a model reviewing its own output still produces valuable comments and catches bugs before deployment, because a different prompt, a different instruction set and a different context are enough for a meaningful review ^[9], and that this adversarial pattern is becoming common in agentic systems more widely ^[10]. He also recommends review agents that run outside the pull request loop, since a single atomic change will not expose structural problems: "de-slopify" agents scanning for repeated code, unparameterized tests and unused feature flags ^[11].

The second substitute is observability. Mortimer's suggestion is an agent that listens to the observability platform, aggregates alerts over a time window, and raises pull requests for the most common problems first ^[7]. Read as a work queue, that orders repairs by alert frequency ^[17]. Frequency is not severity, and a failure that emits no alert never enters the queue. That makes instrumentation coverage a correctness dependency rather than a dashboard concern.

Note what the reported account does not settle. Approval rights are granted to the review agent ^[8], but the evidence offered for its reliability is observed examples, not measured defect rates ^[18]. And if the tests are the documentation, the specification and the thing you keep across rewrites ^{[3] [4]}, then test review becomes the scarce human activity, which means someone has to fund it, staff it and own it. Mortimer's own condition on creativity points the same way: he said creative people need time and space to work, free from the day-to-day demands of meetings, deliverables and demos ^[15].

Watch whether teams give review agents merge authority or comment-only rights ^[8], whether de-slopify passes run on a fixed cadence or only as cleanup before an audit ^[11], and whether the alert-to-pull-request loop acquires a severity gate rather than a frequency sort ^[7]. Watch the staffing question too: if intent and implementation are decoupled and developers become portable across languages ^[13], the work that still needs a named owner is the tests and the instrumentation.