I stared at the screen. A WordPress homepage, fully rendered, loading in my browser. The engine powering it? 100% AI-written Rust code. And I don’t know a single line of Rust.
That moment was equal parts thrilling and terrifying. Thrilling because an AI had just bridged a gap I couldn’t cross myself. Terrifying because I had no idea how to fix it if it broke. This isn’t a story about AI replacing developers. It’s a story about a shift in who gets to build, and what happens when the human in the loop becomes a passenger.
The experiment was simple: point a large language model at the PHP-src test suite and ask it to reimplement the PHP runtime in Rust. No deep understanding of PHP internals required — just let the test failures guide the code. The result: 17% of PHP-src tests passed. But that 17% was enough to render WordPress, a real-world application.
Here’s the part that demands attention: The real constraint isn’t the AI’s coding ability — it’s the quality and comprehensiveness of the test suite itself. This experiment accidentally measured how well PHP-src tests capture real-world behavior, not just how well the AI can code. The 17% pass rate isn’t a failure metric; it’s a map of where test coverage fails human understanding.
You’ve probably felt it too — that strange unease when a tool does something you can’t explain. We’ve been taught that expertise is knowing the language, the runtime, the edge cases. But this AI bypasses all of that. It doesn’t know what a Zend engine is. It doesn’t care about PHP’s memory model. It just reads test cases and writes Rust until the tests turn green.
“I don’t know Rust, but my AI does” is the new power dynamic of software development. It’s empowering because it lowers the barrier to building complex systems. It’s terrifying because it raises the question: who maintains the code when the expert is no longer in the room? The author of this experiment — a non-Rust, non-PHP-internals developer — admits as much. The code works, but it’s fragile. Production-ready? No. A proof of concept that challenges our assumptions? Absolutely.
This is where the contrarian take lives: The AI isn’t replacing developers. It’s exposing the gap between test-passing and genuine system comprehension. If a test suite can guide an AI to build a working PHP engine, then maybe our test suites are the real treasure. But if the test suite is incomplete — and it always is — then the AI produces a castle built on sand.
Take a side: this is brilliant, and this is dangerous. Brilliant because we now have a methodology to build software in languages the human doesn’t speak. Dangerous because we lose the ability to reason about the system. The WordPress homepage loaded, but what’s lurking in the other 83% of untested behaviors?
The twist is this: The AI revolution isn’t about better code. It’s about who gets to build — and who gets to maintain the wreckage. The next time you watch an AI generate code, ask yourself: would you trust it to run in production? More importantly, would you trust yourself to fix it when it doesn’t?
FAQ
Q: Isn't 17% pass rate just garbage code that happened to work by luck?
A: No. The 17% is not random; it's the subset of tests that the AI could satisfy. It passed enough to render a real application (WordPress), which means those tests accurately captured real-world behavior. The rest failed because the test suite is incomplete or the AI lacked deep understanding. It's a signal that test coverage doesn't map perfectly to production scenarios.
Q: What's the practical takeaway for a developer reading this?
A: Start treating your test suite as the most valuable asset in your project. If an AI can derive working code from tests alone, then your tests need to be comprehensive, precise, and reflective of real use cases. Also, get comfortable with the idea that AI-generated code will require a new kind of maintenance — not debugging logic, but debugging test coverage.
Q: The contrarian view: isn't this proof that AI will steal our jobs?
A: No, but it's proof that the nature of the job is changing. The real risk isn't AI taking over — it's AI making humans obsolete as maintainers of systems we didn't build. If you can't read the code an AI wrote, you can't fix it when it breaks in production. The next generation of developers will need to be fluent in test-driven reasoning, not language-specific internals. Those who can't adapt will be left behind.