Phillip Mortimer, a software engineer at Carta, delivered a talk arguing that AI has changed the fundamental nature of code complexity, and that the industry needs to rethink how it reviews, tests, and maintains software as a result. His core claim: in the age of AI, all code is write-only.
Mortimer built the argument around a distinction between two kinds of complexity. The first is the density that languages like APL and regular expressions produce, where a single line can be nearly impossible to parse visually. The second is the volume that AI generates, where individual lines are perfectly readable but the sheer quantity makes human review impossible. Different cause, same result.
Arthur Whitney and the original write-only code
The talk opens with the J Incunabulum, a piece of C code written by Canadian computer scientist Arthur Whitney in a single afternoon in 1989. It is a working interpreter for the J programming language, including an object model, memory management, a standard library, a parser, a lexer, and a read-eval-print loop. It fits on one screen.
Whitney was known for writing incredibly dense C code. He later created A+, a derivative of APL, while working at Morgan Stanley. APL, proposed by Ken Iverson in 1962 at IBM, uses mathematical notation to manipulate arrays and became popular in financial institutions during the 1970s because its interpreted nature supported rapid development. Morgan Stanley's fixed income risk systems ran on A+ for years.
Mortimer spent a decade at Morgan Stanley, first in London then in Tokyo, as a quantitative developer supporting the fixed income trading desk. He wrote APL and regex daily. His conclusion from that experience is blunt: write-only code gives you a second problem to solve, and the only practical response is to treat tests as documentation and treat the code itself as disposable. Keep the tests. Throw away the code. Write it again.
AI makes everything write-only
The shift Mortimer describes is not about notation or density. It is about volume. When Anthropic announced Claude Opus 4.6, the company described how the model had autonomously developed its own C compiler in Rust over two weeks. The GitHub repository shows 500,000 lines of code added, 277,000 deleted, across 4,000 commits.
The code itself is not hard to read. AI writes well-documented, well-commented code with good docstrings. The problem is that no human can review all of it in a reasonable timeframe. AI writes code far faster than any person can read it. That is what makes it write-only, and Mortimer argues the same two principles from APL and regex apply: tests define the behavior, and the code is disposable.
The Anthropic project succeeded in large part because Nicholas Carlini, the researcher who supervised it, collected high-quality C compiler test cases before starting. He built a test harness that guided Claude as it worked. Without those tests, neither the model nor a human reviewer could verify the output was correct.
The pull request is broken
Mortimer contends that the traditional pull request process no longer works for AI-generated code. Having humans review line by line turns people into the bottleneck. He draws a parallel to machine learning, where nobody reviews individual model weights. You review performance statistics. He argues the same approach should apply to code: evaluate what the code does, not how it is implemented.
At Carta, where Mortimer works following the company's acquisition of Accelex, the team uses Claude for code review on code Claude wrote. The approach sounds circular, but Mortimer says it works well in practice. The review model has a different prompt, different instructions, and a different context, which is enough to catch a meaningful number of errors.
He gives a concrete example. A colleague used AI to raise a pull request containing a regular expression. The AI code review caught a catastrophic backtracking problem. A pattern with an optional character in the wrong position turns a 20-character input into 500,000 combinations for the regex engine to check. A 40-character input would take longer than the heat death of the universe. A real denial-of-service risk, caught by AI reviewing AI.
Self-healing software and dead code cleanup
Mortimer describes two other systems Carta has built using Claude skills. The first listens to the company's observability platform, aggregates alerts over a time window, and opens pull requests to fix the most common problems. Over time, the software heals itself, leaving only critical bugs that require human judgment or complex refactors.
The second targets dead code behind feature flags. Carta uses trunk-based development, where new features sit behind flags until they ship. Over time, old flags accumulate. When a flag is turned on everywhere, the code behind it is dead. Mortimer's colleague Eric Vogl built a system he calls the Feature Flag Reaper that has autonomously cleaned up more than 400 feature flags and tens of thousands of lines of dead code.
Monoliths are coming back
The last trend Mortimer identifies is architectural. AI works best when all the code, business logic, and functionality sit in one place. He spent the past few weeks collapsing Accelex's old document intelligence architecture, which was a collection of single-task ML models deployed as independent services, into a single service. LLM calls through APIs replaced the complex workflow orchestration that used to tie those services together.
The broader point is that what previously required complex software systems can now be implemented with a single agent running in a Python process calling LLMs. Software complexity is going up. Architectural complexity is going down. And the developers building these systems are, in Mortimer's words, all full-stack developers now, touching Terraform, React, Python, and whatever else the task demands, because AI decouples intent from implementation at the highest possible level of abstraction: natural language.