Escaping the Quicksand: A Call to Arms

Imagine a world where the invisible machinery of modern life—our banks, hospitals, power grids, and communication networks—is built on a foundation that is slowly sinking. This is the reality facing the computing industry today. For decades, the standard way to build software has been to write a rough description of what a program should do, then write the code, and finally test it by running it with various inputs to see if it breaks. This method, known as test-and-debug development, has allowed technology to flourish, but it leaves systems riddled with hidden flaws. Because the original descriptions are often vague and written in ordinary language, they cannot be checked by machines, and because testing can only cover a tiny fraction of the billions of possible ways a program might behave, many errors slip through. As artificial intelligence begins to write more code, this cycle threatens to accelerate, creating vast new systems that are even more complex and fragile than before, built on a "quicksand" of decades-old design choices that were made when cyberattacks were rare and computing power was scarce.

Two researchers, Peter Sewell from the University of Cambridge and Jean Pichon-Pharabod from Aarhus University, argue that the industry has been stuck in a dangerous loop for seventy-five years. They observe that while we have become incredibly skilled at writing code, we have neglected the precise definitions of what that code is supposed to achieve. The current approach relies on prose specifications—paragraphs of text that describe a system's behavior. While these are easy for humans to read, they are inherently ambiguous and incomplete. A human reader might interpret a sentence in one way, while a machine or a different human interprets it differently. Because these descriptions cannot be directly tested by a computer, developers are forced to guess what the correct behavior should be, often falling back on simple checks like "does the program crash?" rather than verifying if the program is actually doing the right thing. This gap between the written intent and the actual code creates a massive amount of technical debt, a hidden cost that manifests as security vulnerabilities and system failures that can be exploited by attackers.

The authors suggest that the solution is not to abandon testing, but to change how we use specifications. Instead of writing vague paragraphs, they propose creating specifications that are executable, meaning they are written in a form that a computer can run. Imagine a specification that acts as a live referee during the development process. As code is written or generated, this executable specification runs alongside it, instantly checking if the code's behavior matches the intended rules. If the code tries to do something the specification forbids, the system flags it immediately. This creates a much tighter feedback loop, allowing developers to catch errors as they happen rather than weeks later. This approach can be applied in different ways: one can start with the code and write a specification to match it, start with a specification and generate code that fits it, or build both together. The key is that the specification is not just a document to be read, but a tool to be used.

However, the researchers acknowledge that this is not a simple switch to flip. To make this work on a massive scale, the computing community needs to build a new layer of infrastructure. Currently, there are no universally accepted, machine-readable definitions for the behavior of many fundamental technologies, such as the C programming language, the Rust language, or the instructions that run on computer chips. While some researchers have successfully created these definitions for specific parts of the system, there is no unified framework that connects them all. The authors point out that building this infrastructure is a challenge of scale and cooperation. It requires a massive, coordinated effort from universities, governments, and technology companies to create, validate, and maintain these precise definitions for the entire stack of computing technology, from the hardware up to the cloud services.

The paper also addresses the role of artificial intelligence. The authors warn that simply using AI to write more code without these better feedback loops will only make the problem worse. AI can generate code faster than humans, but if that code is built on shaky foundations and tested only with the old, ineffective methods, it will simply create larger systems with more hidden errors. Conversely, if AI is used to help generate and check these executable specifications, it could become a powerful tool for improving software quality. The authors envision a future where AI helps create rigorous specifications, and where those specifications are used to verify that both human-written and AI-written code are correct. This would allow for a gradual increase in confidence, starting with simple tests and moving toward more complex mathematical proofs of correctness, all without requiring every developer to become a mathematician.

Despite the clear path forward, the authors argue that the industry has been held back by a mismatch of incentives. Technology companies are motivated to release products quickly to capture market share, while the risks of failure fall largely on society and the end-users. Building the robust infrastructure needed to prevent these failures is expensive and time-consuming, and no single company wants to bear the full cost of fixing problems that affect everyone. The researchers call for a collective effort, similar to the large-scale projects seen in physics or biology, to fund and coordinate the creation of this semantic infrastructure. They suggest that while the cost is significant, it is a tiny fraction of the current spending on artificial intelligence and is essential for securing the future of computing. Without this shift, the industry remains trapped in a cycle of building increasingly complex systems on foundations that are too weak to support them, leaving society vulnerable to constant risk.

The authors conclude that the tools and methods to solve this problem already exist. Researchers have successfully demonstrated how to define the behavior of complex systems and verify them with high confidence. What is missing is the will to bring these methods into everyday practice and to build the shared infrastructure that makes them accessible to all. The paper serves as a call to action for the research community, industry leaders, and funding agencies to collaborate on this task. By moving away from vague descriptions and toward precise, executable specifications, the computing world can escape the quicksand of technical debt and build a future that is not only more innovative but also fundamentally safer and more reliable.