Skip to content
Preprint

Escaping the Quicksand: A Call to Arms

Aug 2026 · 0 citations · 32 references
Computer Science

TL;DR

This work argues for a pragmatic approach to flexible combinations of testing, *specification*, and proof, that provides more effective feedback loops for both AI and human development, and calls for the community to arms to create and deploy it.

Abstract

Computing has been an astonishing success - but the accumulated technical debt exposes us all to huge costs in business and societal risk. For 75 years, we've built systems to prose specifications with test-and-debug development. That works well enough for industry to thrive, but it's an expensive and ineffective feedback loop, and leaves everyone relying on shaky foundations. Now, AI-enabled engineering is amplifying the success by reducing coding costs, but also amplifies the risks, by rapidly increasing technical debt, and by automating detection of the vulnerabilities therein. How can we do better? Research has long pursued mathematical proof of correctness, which, unlike testing, can cover all cases. This too has advanced massively, but it remains hard to apply, both technically and because of a deep-seated cultural disconnect. Instead, we argue for a pragmatic approach to flexible combinations of testing, *specification*, and proof, that provides more effective feedback loops for both AI and human development. Most simply, one can incrementally co-develop executable-as-test-oracle partial specifications alongside conventional prose descriptions, code, and tests. This clarifies design and makes testing much more discriminating. Developers can and should do it today. Or, even better, one can use specifications that support the full gamut of testing, property-based testing, symbolic execution, and proof. This enables a range of intertwined feedback loops, again both for AI and humans, from cheap testing to more expensive proof. However, making it really practical needs *semantics infrastructure*: specifications and tooling for the main programming languages and other abstractions, which we now more-or-less know how to build, but which is not yet in place. We call the community to arms to create and deploy it - to enable a future built on firmer ground.

View source

Similar papers

Preprint Sep 2026

C-to-Rust Fallacy: Automatic Refactoring != Memory Security

Rust has emerged as the leading system programming language, offering strong memory and type safety guarantees without compromising performance. This positions it as a compelling alternative to traditional languages like C and C++, which are susceptible to memory security bugs. However, manually transforming C to Rust...

Hung-Mao Chen, Xu He, Bo Lu et al. · 0 citations
Book Open access Sep 2026

zBulk: Towards Automatic Compartmentalization in Rust with Zero Manual Retrofitting

Memory safety is a dominant driver in security and systems research. Rust has become a viable alternative to C/C++ for systems programming because of its strong memory safety guarantees. However, it is not a silver bullet. Unsafe sections, foreign code, and compiler-soundness bugs still pose vulnerabilities. Compartmen...

Maxim Ritter von Onciul, Phillip Raffeck, Peter Wägemann et al. · 0 citations
Book Open access Oct 2026

Finding the Bugs Users Would Find: From Sapienz to Autonomous Agents (Keynote)

This keynote accompanies the ISSTA 2026 Impact Paper Award for the paper “Sapienz: Multi-objective Automated Testing for Android Applications”, first presented in 2016. Sapienz recast user-interface test generation as a multi-objective search, raising coverage and fault revelation while minimising the length of each fa...

Ke Mao · 0 citations
Review Sep 2026

Trust the Spec, Not the Code - A Specification-First, AI-Assisted Case Study in Online Banking

It is argued that AI removes much of that cost: natural language enriched with lightweight mathematics, written in \LaTeX, can serve as an intermediate specification language that is precise enough to reason over and prove, while a large language model reviews it for ambiguity, drafts proofs, and generates the implemen...

E. Farchi · 0 citations
Preprint Sep 2026

Evaluating Shaker for Flaky Test Detection in Python Projects

The first empirical evaluation of Shaker for Python is presented, comparing non-order-dependent flaky tests from the ground-truth dataset of Gruber et al., and finding that Shaker provides no statistically significant detection advantage over plain re-execution.

G. Leal, Denini Silva, Leopoldo Teixeira · 0 citations

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.