At QCon London, Phillip Mortimer argued that AI is making all code write-only and unreadable, with code becoming disposable and tests defining behavior as documentation. He recommended automated code review, self-healing software via observability, and decoupling intent from implementation so developers can focus on creativity.
SynthePulse Insight · AI deep reading
Version 1 · 1 source
At QCon London, Phillip Mortimer argued that AI is pushing code toward being "write-only and unreadable," and therefore we should let tests define behavior, treat code as disposable, and replace manual line-by-line review with automated review and self-healing agents. This is a self-consistent engineering position, but what supports it is mainly personal experience, not verifiable data.
At his QCon London talk "Complexity and Creativity in Software Engineering," Phillip Mortimer offered a fairly radical judgment: artificial intelligence is pushing all code toward being "write-only and unreadable." This is not a description of some category of projects, but a universal statement covering all code.
He borrowed Eric S. Raymond's definition to anchor the meaning of "write-only code": code that is obscure, complex, or poorly structured, that almost no one besides the author can modify or understand, and that even the author may not fully understand. By this definition, the problem with write-only code is not just that "others can't read it," but that even the author may lose full grasp of the code.
Mortimer also pointed out that some languages are "write-only" by design, trading readability for extreme expressiveness and performance; his examples were APL and regular expressions. Such languages embody the complexity brought by extreme density—density itself is not a defect, but it pushes the cost of understanding high enough that external means are needed to compensate.
What needs to be distinguished is this: this is Mortimer's judgmental statement, and the source did not provide empirical data supporting the universal conclusion that "all code is trending toward write-only." Treating it as an engineering hypothesis worth taking seriously is more prudent than treating it as a verified industry fact.
Facing write-only code, Mortimer's first principle is to let tests define behavior. When written code is too dense to read, the only way to understand its behavior is through a large number of test cases, and tests therefore become the code's documentation. The understanding path he describes is to look at combinations of inputs and outputs to learn what the code is supposed to do, because it is hard to see it directly from the code itself.
The second principle is that code is disposable. Mortimer believes write-only code is hard to debug, and that rewriting from scratch is usually easier than modifying existing code, so he recommends keeping the tests, discarding the code, and reimplementing.
These two principles interlock logically: if tests carry the definition of behavior, then code degrades into a replaceable implementation vehicle; since behavior is locked down by tests, rewriting does not need to presuppose understanding the old code. In other words, tests are upgraded from "verification tool" to "specification and documentation," while code is downgraded from "asset" to "consumable."
There is a noteworthy implication here (inference): this approach shifts the center of gravity of maintainability from code readability to test completeness. The source did not discuss whether the tests themselves may also become hard to maintain, nor did it give any numbers on test coverage or rewrite frequency.
Mortimer's rejection of manual review is quite direct: because of the sheer volume, having humans review AI-generated code line by line is meaningless, because humans quickly become the bottleneck.
His alternative is to write very detailed tests and automate code review. In an InfoQ interview after the talk, he described automated code review as relatively simple and straightforward: you can invoke a coding agent harness as a CI action and give it the skills a senior developer pays attention to when reviewing code; a code review agent can post comments, request changes, and even approve PRs.
He also mentioned a counterintuitive observation: having a model review its own output can provide very valuable review feedback, finding defects before code is deployed. His explanation is that different prompts, different instructions, or different contexts seem sufficient to produce valuable review, and he believes this adversarial review process is becoming a general technique in broader agent systems, not just for code review.
These claims about effectiveness come from Mortimer's personal experience and observations and are claims relayed by the source; the source did not state sample size, defect types, or false positive rates. The "relatively simple and straightforward" mentioned in the interview refers to the implementation method, and does not mean the effectiveness has been quantitatively verified.
Mortimer pushed the boundary of automation from "review" to "repair." His proposed approach is to have AI coding agents listen to observability platforms, aggregate alerts within a certain time window, and then begin opening pull requests to fix these problems, starting with the most common ones.
He also described another type of agent that resides in the codebase: "De-slopify" agents can run periodically to find duplicate code, unparameterized tests, unused feature flags, or similar low-cost, low-risk items and fix them.
In addition, code review agents can also run outside the pull request process, which helps uncover structural problems that are hard to notice within a single PR.
Putting these three together, what Mortimer envisions is an automated closed loop from alert to PR, and from PR to codebase cleanup. But the source did not explain the actual deployment status and risk controls of self-healing agents in production environments, nor did it give any validation results for the "de-slopify" agents. The source likewise did not clarify the permission boundary between automatically opening fix PRs and automatically approving PRs.
Mortimer advocates decoupling intent from implementation. His argument is that AI uses natural language, which makes developers more portable across different programming languages—if intent is expressed in natural language, the choice of implementation language is no longer a factor binding the developer.
From this he redefines the developer's role: the software developer's role today is creativity. His description of creativity is iterative, a process of gradual improvement over a longer period; anyone can create, and the key is to start doing it.
At the organizational level, he believes creative people need time and space to do their work, avoiding interference from daily meetings, deliveries, and demos, and he says that brainstorming, which is widely admired in the business world, actually produces fewer good ideas than individual independent thinking. He mentioned that he tends to concentrate meetings at the beginning or end of the day, leaving long blocks of focused time.
He also emphasized the importance of constraints for creative work: constraints eliminate the infinite possibilities of a blank canvas and force people to explore within a bounded space. He used his early experience at the document intelligence startup Accelex as an example—limited by time and resources, which forced him to find innovative solutions to the problem of reading data from tables.
These claims about the conditions for creativity are Mortimer's personal views and experience; the source did not provide verifiable industry data, and the specific timing, scale, and results of the Accelex case were not explained.
Mortimer's summary is: AI has already solved the implementation problem, what remains is creativity, we are all full-stack developers, all you need is a creative idea, and now is the best time to build with software.
Looking at this set of claims as a whole, its structure is clear: AI makes code unreadable (premise) → tests define behavior, code is disposable (method) → manual review is unfeasible, automated review and self-healing take over (organizational arrangement) → developers focus on creativity (role redefinition). Each link points to the next, and the internal logic is self-consistent.
But self-consistency does not equal verification. The source explicitly lists several unresolved points: the proportion of AI-generated code in real projects, the specific threshold of the manual review bottleneck, and the success rate of self-healing agents all lack any numbers; the source did not explain at what scale, with what tech stack, or under what organizational conditions these practices apply; and there are no failure cases or counterexamples.
Therefore, a more accurate reading is this: this is an engineering claim and directional judgment put forward by a practitioner at a conference, not a conclusion verified by a third party. It proposes a hypothesis worth testing about "how to organize software production in the AI era," but the testing itself has not yet happened.
All content in this article comes from InfoQ's report on Phillip Mortimer and the post-talk interview (the Chinese text reposted on a WeChat public account). Mortimer's views and recommendations are the speaker's personal claims, not industry consensus or third-party-verified conclusions; his descriptions of the effects of automated review, agent self-healing, and "de-slopify" agents all come from personal experience and observation, and the source did not provide verifiable quantitative data or benchmarks. The source also did not provide the specific date, session information, or independently verifiable talk materials for the QCon London talk. Any places in the text involving inference have been clearly marked.
Mortimer's claims offer a self-consistent engineering direction: when code trends toward unreadable, hand the authority to define behavior to tests, treat code as disposable, hand review and repair to agents, and let people return to creativity. But the evidence supporting this direction is currently mainly personal experience—no proportions, thresholds, success rates, applicable boundaries, or counterexamples. It is worth testing as a hypothesis, not executing as a conclusion.
Primary report
Primary source