I Don’t Know Rust: How My AI Rewrote a PHP Engine

The Dawn of AI-Assisted Systems Programming

We are currently witnessing a seismic shift in how we architect the foundational layers of the internet. For decades, the divide between high-level, developer-friendly languages like PHP and the performance-oriented, memory-safe world of Rust was a chasm bridged only by elite teams of systems engineers. Traditionally, a developer could spend years mastering the intricacies of memory management, borrow checkers, and low-level concurrency before feeling confident enough to touch a core engine. However, the emergence of Large Language Models (LLMs) has fundamentally altered this landscape, effectively democratizing the ability to rewrite complex legacy infrastructure. We have entered an era where being fluent in a language is no longer the primary barrier to building within it; instead, the barrier has shifted toward one’s ability to guide, audit, and architect alongside an AI partner.

My decision to rewrite a PHP engine in Rust was born from a mix of professional curiosity and a desire to see just how far this new paradigm could be pushed. Despite having only a superficial understanding of Rust’s complex syntax and rigid memory safety rules, I set out to translate the intricate logic of PHP’s execution model into a modern, performant alternative. The goal was never to simply replicate existing functionality, but to explore the potential for AI to bridge the architectural gap between an interpreted environment and a system-level runtime. By acting as the bridge between the logic of the source material and the rigorous constraints of the Rust compiler, I discovered that I could navigate deep technical waters—like bytecode interpretation and stack management—without needing to be a systems programming expert myself.

The true power of AI-assisted systems programming lies not in automating the code, but in compressing the time it takes for a single developer to master a new architectural domain.

This project serves as a practical experiment in the viability of AI-driven transformation. While I certainly did not start with deep expertise in Rust, the LLM functioned as a tireless tutor and a sophisticated translator, turning architectural concepts into functional, memory-safe code. This transition from “writing every line” to “orchestrating the logic” allows for a new velocity in software engineering. When we remove the friction of syntax and boilerplate, we are left with the core challenge: how do we design systems that are faster, more secure, and more resilient than what we have today? By leveraging these tools, ambitious migrations that were once considered the exclusive domain of large engineering teams are now within the reach of a single, motivated individual, provided they remain vigilant in their oversight of the AI’s output.

Ultimately, this endeavor is about more than just a PHP interpreter; it is about proving that we can modernize technical debt by offloading the heavy lifting of language conversion to intelligent models. As my engine began to pass a meaningful percentage of official PHP-src tests and eventually rendered a live WordPress site, the reality became clear: the barrier to entry for systems programming has been permanently lowered. We are no longer limited by our current vocabulary of programming languages, but rather by the scope of our ambition and our ability to verify the machines we build.

How AI Navigates the Complexity of Rust and PHP

The true innovation in this project lies not merely in translating syntax from PHP to Rust, but in reconciling two fundamentally different programming philosophies. PHP, with its dynamic typing, garbage collection, and permissive nature, stands in stark contrast to Rust’s strict ownership, borrowing rules, and explicit memory management. Our AI acts as the crucial interpreter, tasked with bridging this philosophical chasm, transforming PHP’s fluid semantics into Rust’s rigorously enforced safety model. This challenge goes far beyond a simple code-to-code conversion; it demands an understanding of underlying runtime behaviors and how to safely represent them in a language built for performance and reliability without a traditional garbage collector.

To achieve this intricate translation, the AI was given a highly structured and detailed prompting strategy. Instead of merely asking for a generic “PHP to Rust conversion,” the instructions meticulously laid out the architectural constraints and desired Rust paradigms. The core prompt instructed the AI to “Act as an expert Rust developer designing a highly performant and memory-safe interpreter for PHP code.” It included specifics on how to represent PHP’s dynamic types (e.g., suggesting an enum-based value type), how to handle mutable state (e.g., Rc<RefCell<T>> for shared ownership and interior mutability where necessary), and how to manage the lifecycle of objects without relying on a garbage collector. This comprehensive context allowed the AI to approach the problem with a deep understanding of Rust’s idioms rather than just a superficial syntactic swap, ensuring the generated code adhered to Rust’s safety guarantees from the outset.

One of the most significant hurdles was mapping PHP’s inherently dynamic type system onto Rust’s strict static typing. In PHP, a variable can effortlessly transition from holding an integer to a

Measuring Success: The 17% Milestone and Beyond

Passing 17% of the official php-src test suite might sound like a modest accomplishment to the uninitiated, but in the realm of language runtime development, it represents a monumental leap forward. This test suite is the gold standard for PHP compatibility, covering everything from core language syntax and type juggling to the nuance of edge-case memory handling. Achieving this milestone means that my AI-generated Rust engine has successfully navigated the fundamental logical hurdles of the Zend engine’s architecture. It is no longer a collection of speculative scripts; it is now a functional, verifiable runtime that mirrors the expected behavior of official PHP in nearly one-fifth of all standardized scenarios.

The true gravity of this progress becomes apparent when you consider the jump from passing unit tests to rendering a live WordPress installation. WordPress is notoriously complex, relying on a dense web of global state, intricate database abstraction layers, and recursive template parsing that pushes any execution engine to its absolute limit. Successfully rendering a page is proof that the engine can handle real-world HTTP lifecycle demands, including session management and dynamic file inclusion, which are far more unpredictable than the static, isolated logic found in standard test suites. When I saw that first WordPress dashboard load, it was the moment the project shifted from an academic experiment into a legitimate, functional web server environment.

However, we must remain pragmatic about the remaining 83% of the test suite. These unresolved tests represent the deep, murky waters of PHP’s legacy, including complex extensions, specific object-oriented behaviors, and the vast array of side effects inherent in PHP’s original design. Many of these failures stem from the sheer breadth of PHP’s standard library, which requires massive amounts of glue code to bridge the gap between Rust’s strict memory safety and PHP’s historically loose, C-based approach to resource management. Each remaining percentage point will likely require exponentially more effort than the first 17%, as we move from fundamental execution into the territory of high-performance optimization and exhaustive feature parity.

The leap from executing a basic script to rendering a live CMS is the difference between a prototype and a product; it demonstrates that the core architecture is robust enough to sustain the weight of a modern, production-grade application.

Ultimately, this progress serves as a validation of the generative process itself. By leveraging AI to architect the engine, I have been able to iterate on complex system-level problems that would have taken a single human developer years to debug manually. The path forward involves systematically addressing the architectural bottlenecks that cause those remaining 83% of tests to fail, focusing on areas like garbage collection and optimized opcode execution. While the journey to 100% compliance is still long, the ability to serve real-world content proves that the foundation is not only stable but capable of evolving into a high-performance alternative to the traditional PHP runtime.

Challenges in Translating Dynamic Logic to Static Safety

While artificial intelligence is undeniably a powerful force, revolutionizing how we approach development by accelerating code generation, it often operates with a significant blind spot: a lack of holistic architectural oversight. An AI, even a sophisticated one, typically excels at pattern recognition and synthesizing functional code snippets based on vast training data. However, it fundamentally struggles with the long-term, abstract implications of system design – the subtle trade-offs, the future maintainability, and the strategic choices that define a robust and scalable architecture. This limitation becomes particularly pronounced when attempting to translate the dynamic, “move fast and break things” philosophy inherent in a language like PHP into the rigorous, safety-first paradigm of Rust, creating unique friction points and accumulating technical debt that might not be immediately apparent.

One of the most common pitfalls encountered when an AI attempts this kind of cross-paradigm translation is the generation of code with suboptimal memory management, leading to significant overhead. PHP’s runtime is highly dynamic, relying heavily on garbage collection and automatic memory management, which abstracts away many low-level concerns for developers. Rust, by contrast, demands explicit ownership and borrowing, offering unparalleled control and performance but requiring a deep understanding of memory lifetimes. An AI, trained on patterns, might generate functionally correct Rust code that mirrors PHP’s allocation patterns, resulting in frequent, unnecessary heap allocations or copies where more idiomatic Rust would use references, stack allocations, or sophisticated ownership transfers. This can negate much of Rust’s performance advantage, turning what should be a lean, efficient component into a memory hog.

Beyond efficiency, another critical area where AI’s lack of architectural foresight can be detrimental is in the improper use of Rust’s `unsafe` blocks. Rust’s core promise is memory safety and thread safety without a garbage collector, enforced by its strict compiler. The `unsafe` keyword allows developers to bypass some of these checks, necessary for low-level optimizations, FFI (Foreign Function Interface) calls, or specific data structure implementations. However, `unsafe` code places the burden of upholding memory safety guarantees squarely on the developer. An AI, without a true understanding of the invariants `unsafe` code must maintain, might introduce such blocks without proper justification or, worse, without ensuring the underlying safety assumptions are met, inadvertently creating subtle memory bugs or vulnerabilities that are exceedingly difficult to detect and debug.

Furthermore, the very nature of AI-generated code presents a unique challenge to codebase maintenance and evolution. A human engineering team typically develops a consistent style, establishes common error handling patterns, and adheres to specific architectural idioms across a project. This consistency makes the codebase cohesive, easier to onboard new developers, and simpler to refactor or debug. AI-generated code, however, can often feel like a patchwork quilt: each generated function or module might exhibit slightly different patterns, variable naming conventions, or error propagation strategies. While individually functional, this lack of a unified “voice” or architectural consistency can make the overall codebase incredibly difficult to navigate, understand, and extend, leading to significant long-term maintenance burdens and hindering future development velocity.

The true challenge isn’t just getting the AI to write *working* code, but to write *maintainable, idiomatic, and architecturally sound* code that respects the philosophical underpinnings of the target language.

In essence, while AI can be an invaluable co-pilot for generating boilerplate or translating syntax, it still falls short when it comes to the nuanced, strategic decisions that underpin sound software architecture. Bridging the gap between a dynamic language like PHP and a static, safety-focused language like Rust requires more than just a syntactical rewrite; it demands a deep semantic understanding of both paradigms, an awareness of their respective strengths and weaknesses, and the foresight to build a system that leverages Rust’s capabilities without inheriting PHP’s architectural baggage. The human engineer’s role, therefore, shifts from mere coding to that of a chief architect, meticulously reviewing, refactoring, and guiding the AI’s output to ensure it aligns with robust engineering principles.

The Future of AI-Driven Compiler Development

The journey of leveraging AI to construct a PHP engine in Rust, capable of rendering WordPress and passing a significant portion of PHP-src tests, transcends mere technical curiosity. It stands as a compelling harbinger of a profound shift in the very fabric of software development. This project offers a tangible glimpse into a future where the act of programming increasingly pivots from meticulously crafting low-level implementations to articulating high-level intent, allowing intelligent systems to bridge the gap. Consequently, the traditional boundaries defining roles like ‘developer’ and ‘architect’ are not just blurring; they are beginning to intertwine in novel and productive ways, necessitating a re-evaluation of how we conceive of software creation itself.

One of the most immediate and critical questions this experiment raises pertains to the future of specialized engineering roles, particularly for compiler engineers. While some might envision AI systems entirely supplanting human expertise in these complex domains, a more nuanced and probable outcome points towards profound augmentation rather than outright replacement. AI excels at pattern recognition, boilerplate generation, and the meticulous translation of high-level directives into optimized machine code, tasks that are often tedious and error-prone for humans. However, the human element remains indispensable for architectural vision, novel problem-solving, creative design, and understanding the subtle, often unstated, requirements that drive robust software systems. Instead of replacing compiler engineers, AI becomes an incredibly powerful co-pilot, freeing these experts to focus on groundbreaking research, innovative language design, and tackling the truly intractable problems that require human intuition and ingenuity.

Beyond the immediate impact