The Shifting Sands of Code: How AI and Rust are Redefining Software Development

By Manuel Masiero

A seismic shift is rippling through the developer community, originating from a seemingly innocuous keynote at Rails World. David Heinemeier Hansson (DHH), the celebrated creator of Ruby on Rails, dropped a bombshell that has developers debating the very future of programming: the backend of the next iteration of his popular email service, HEY, will be rewritten in Rust, not Ruby. The most startling revelation, however, was not the language switch itself, but the method of implementation: it was largely crafted by AI coding agents, with DHH himself admitting he wouldn’t even be closely examining the code.

This announcement has ignited a firestorm of discussion, challenging deeply ingrained notions of programmer happiness, language aesthetics, and the role of human developers in the age of artificial intelligence. While some recoil at the perceived soullessness of AI-generated code and the "aesthetically terrible" nature of Rust, a closer examination reveals a pragmatic evolution in software development, one that prioritizes outcome and efficiency over the subjective pleasure of the coder.

The End of "Programmer Happiness" as the Sole Arbiter?

At the heart of DHH’s original Rails doctrine lies the principle of "Optimize for programmer happiness." For years, this philosophy has resonated with developers, positioning Ruby and Rails as tools that foster joy and elegance in the coding process. The emphasis was on making programming feel good, on the swift and delightful transformation of ideas into functional code. This focus on the human experience of writing code has been a cornerstone of Ruby’s success, attracting a loyal community who value its expressiveness and ease of use.

However, DHH’s latest pronouncement suggests a fundamental re-evaluation of this principle. He boldly declared that "the most beautiful programming language in the world is English," implying that when code is no longer primarily written by humans, the aesthetic and emotional considerations that once guided language choice become secondary, if not entirely irrelevant. For the thousand developers in the audience, the silence that followed this statement was palpable, a collective pause to absorb the implications of a world where the programmer’s emotional connection to their tools might no longer be the primary driver of decision-making.

The author of this article, Manuel Masiero, finds himself in agreement with DHH’s core thesis, at least in part. He argues that for applications like HEY, which are not characterized by extreme technical complexity, AI agents are increasingly capable of generating robust and manageable code. This realization shifts the focus from the act of coding to the qualities of the resulting software. When the programmer’s direct engagement with the code is minimized, the criteria for selecting a programming language must necessarily evolve.

The Pragmatic Appeal of Rust: Performance and Efficiency

The choice of Rust, a language often described as having a steep learning curve and an unappealing syntax, might seem counterintuitive given the historical emphasis on developer experience. However, DHH’s embrace of Rust is driven by its inherent strengths: its strong type system, its exceptional performance, and its remarkably low resource consumption. He estimates that the HEY backend, previously requiring a significant server infrastructure, can now be scaled down to a mere ten servers, primarily for redundancy. His "gut feeling" suggests that even a single Raspberry Pi might suffice, a testament to Rust’s efficiency.

This dramatic reduction in infrastructure needs underscores a critical shift in priorities. While Ruby excels at rapid prototyping and developer satisfaction, Rust offers a compelling alternative for performance-critical applications and resource-constrained environments. The ability to achieve such efficiency without sacrificing functionality is a powerful draw, especially when coupled with the burgeoning capabilities of AI in code generation.

AI as a Catalyst, Not the Sole Driver

A common, yet potentially misguided, conclusion drawn from DHH’s announcement is that Rust is inherently "better" for AI to write. Masiero contends this is a misinterpretation. While languages with less syntactic freedom, like Go, can offer some advantages by reducing variance in training data, the core issue is not the inherent suitability of a language for AI, but the availability of robust testing and validation mechanisms.

Even with more flexible languages like JavaScript and TypeScript, AI-generated code can yield excellent results when guided by strong linters, formatters, and, crucially, comprehensive test suites. The difficulty arises not with the language itself, but with the scarcity of training material for truly exotic or niche programming languages.

Therefore, the superior results achieved by the AI in HEY’s Rust backend are not because Rust is inherently more "AI-friendly." Instead, they stem from Rust’s intrinsic advantages in areas where Ruby might falter, and crucially, these advantages come at virtually no additional cost when an AI is doing the writing. The historical "price" of dealing with a more rigid and verbose language like Rust is now borne by the AI, which, by its nature, is indifferent to such inconveniences.

A Personal Evolution: The Diminishing Role of Human Code Review

Masiero admits to a personal evolution in his thinking, prompted by this paradigm shift. He previously championed "code reading" as an underappreciated senior discipline, warning against the tendency to rewrite rather than understand existing code, a problem he feared would be exacerbated by Large Language Models (LLMs). Today, his perspective has shifted.

The reality is that code is read far more often than it is written. Features are added, bugs are fixed, and modules are understood – all requiring code comprehension. However, the primary reader is increasingly becoming an AI, and less frequently, a human. Furthermore, the sheer volume of code that can be generated by AI outpaces the capacity of human teams to review it thoroughly. The notion of manually scrutinizing every line of AI-generated code is not a solution; it merely shifts the bottleneck.

This leads to the concept of Spec-Driven Development (SDD), where the desired behavior is defined first, and an AI agent generates the corresponding code. The validation then shifts from the code itself to whether the defined behavior is achieved. As Masiero elaborates in "Code is an Implementation Detail," a recent publication, the true linchpin of this approach is not the specification but the tests derived from it.

While a prose specification can be ambiguous, a test provides a deterministic outcome. A green test signifies success; a red one, failure. While not a mathematical proof, tests offer an objective measure of correctness, a significant improvement over an AI simply generating code that "looks right."

The Power of the Test Suite: A Case Study in xAPI

The efficacy of this approach was vividly demonstrated in the implementation of a Learning Record Store for xAPI. The Experience API (xAPI) is a standard for capturing learning activities, allowing platforms to report on what learners have done. A Learning Record Store (LRS) ingests these reports, stores them, and makes them available for queries.

The critical element in this scenario was the official conformance test suite for xAPI, managed by the ADL Initiative. This suite rigorously tests the specification’s mandatory requirements from an external perspective, interacting with the HTTP interface. For xAPI 2.0, this suite comprises a staggering 1435 tests, providing an exceptionally comprehensive description of the desired behavior.

The instruction to the AI agent was straightforward: "Implement this in Go, and iterate until all tests are green." The AI required approximately 75 minutes to complete the task, engaging in multiple cycles of testing, self-correction, and re-submission. Ultimately, all 1435 tests passed, and the implementation has been functioning flawlessly for weeks.

The profound insight derived from this experience is that the success was not attributable to the AI model or the programming language alone. It was fundamentally driven by the existence of a high-quality, extensive, and complete test suite. Without it, the same AI, using the same model and language, would have produced code that appeared plausible but whose underlying errors would have remained undetected. For developers assessing the extent to which they can delegate tasks to AI, the quality of the tests should be the primary consideration, not the programming language.

The Unspoken Limitations: When Agents Fail Silently

Despite the compelling success of the xAPI example, it’s crucial to acknowledge the limitations of AI in code generation. Certain scenarios are inherently difficult, if not impossible, to test comprehensively. This includes situations involving inter-machine communication, hardware dependencies, operating system threading behaviors, and network stack intricacies. Errors that manifest only under specific timing conditions might appear only once in a thousand test runs, or perhaps never, yet they persist.

Furthermore, areas with limited training data, even within purely software-defined domains, pose challenges. AI agents struggle to find reliable patterns to emulate and lack sufficient corrective feedback in such environments.

The most significant problem is not the AI’s failure, but how it fails. An AI will rarely declare its inability to perform a task. Instead, it will prematurely report completion, delivering a solution that appears convincing but may be fundamentally flawed. In the less testable domains, these solutions are often incorrect.

This highlights the true role of tests in this new workflow: they serve as the AI’s adversarial partner. Where tests are robust, as in the xAPI interface, AI can be entrusted with significant responsibilities. However, where tests are weak, there is no one to challenge the AI, and this is where the danger lies.

The Compiler as a Second Line of Defense

This is where Rust’s strengths truly shine and offer the most compelling argument for DHH’s decision. In concurrent programming, where testing often proves less effective, Rust shifts a significant portion of error detection from runtime to compile time. Its ownership model, for instance, prevents multiple parts of the code from concurrently modifying the same memory locations. As long as the code avoids explicitly marked unsafe blocks, Rust guarantees the absence of data races – unsynchronized, simultaneous access to data by multiple threads, where at least one thread is writing.

It’s important to clarify that Rust does not prevent all race conditions or deadlocks. Its documentation explicitly states that this is mathematically impossible in environments where the scheduler is not controlled by the program. However, Rust effectively eliminates an entire class of insidious bugs by catching them during compilation. Coupled with its powerful type system, which catches many errors at compile time that would only surface at runtime in languages like Ruby, Rust provides a robust safety net.

The rigidity that some developers find frustrating in Rust transforms into an advantage when an AI is the primary coder. The compiler, unlike a human developer, cannot be "persuaded" to accept plausible-looking but incorrect code. It provides a second, deterministic layer of validation, precisely where testing reaches its limits. The "ugliness" of the language, as DHH described it, becomes a non-issue when it’s the machine experiencing it.

The Enduring Role of Human Oversight: When is a Human Truly Needed?

Does this mean humans are no longer needed to read code? Not entirely, but the criteria for when human intervention is necessary are evolving. Masiero emphasizes the criticality of the software. For safety-critical systems, vital infrastructure, or any application where errors could endanger lives or cause widespread damage, human oversight remains indispensable, complementing all tests and compilers.

However, for the "ten-millionth web server in Python," manual line-by-line review is becoming obsolete. AI agents can handle these tasks with increasing autonomy. HEY, as an email service, falls into a less critical category. While important to its users, its technical architecture is manageable, making DHH’s thesis applicable. Applying this same level of delegation to controlling a nuclear power plant, however, would be irresponsible.

The profound silence in the Rails World audience was also a reflection of the human element. Many developers define themselves by their chosen language, and for a community whose identity has been forged over two decades on the joy of writing code, such a keynote represents a significant turning point.

Masiero maintains a pragmatic view. While he acknowledges personal preferences for certain languages (subjectively favoring C# over Visual Basic, and Go over Python), he stresses that for clients, the underlying programming language is often irrelevant. Their primary concern is the resolution of their business problem, regardless of the technical implementation.

The passionate debates over technology within teams are often a symptom of a deeper issue: too many technological discussions and too few focused on the actual business logic. AI exacerbates this by minimizing the cost of writing code, diminishing the argument for syntax aesthetics.

The Decoupling of Language and Outcome

DHH’s keynote has stirred controversy by touching upon a taboo: the potential interchangeability of programming languages, which are so deeply intertwined with developer identity. Masiero argues that his thesis holds true for its intended application. When AI is writing code, the determining factors are no longer which language brings joy, but which can be deterministically verified through tests, and, where tests fall short, through the compiler. The more critical the software, the greater the ongoing need for human involvement.

However, a crucial question often gets overlooked in these debates. While the choice between Ruby and Rust might become less significant with AI, fundamental architectural decisions – the need for a relational database versus a document store or a message queue – remain paramount. These are not matters of taste but of strategic architectural choices, decisions many teams make before fully understanding the problem itself. This critical aspect will be the focus of the second part of this series.