When Ekin Ertac’s terminal printed a fully rendered WordPress front page, complete with block styles and a post pulled from a SQLite database, the unremarkable output masked something unusual: every line of the engine that served it was written in Rust by an AI, not by Ertac himself. He describes his own role simply as “aiming.”
The project is called Phargo, and it is a from-scratch PHP interpreter written entirely in Rust — a language Ertac openly admits he does not know. The engine currently sits at roughly 24,000 lines of Rust code and passes 3,935 of 22,037 tests from PHP’s official upstream test suite, putting it at 17.9%. That figure sounds modest, but Ertac notes the realistic ceiling is around 40 to 45 percent, because the remainder of the suite covers C extensions such as GD, curl, and MySQL drivers that are deliberately out of scope.
The core discipline holding the experiment together is that the AI never grades its own output. PHP ships with approximately 22,000 .phpt test files accumulated by the PHP internals team over three decades. These tests cover everything from DateTime daylight-saving edge cases to the exact output of var_dump() on a float. The AI implements features; the test suite confirms whether they actually work. The pass rate is auto-generated into the public repository after every run and cannot be argued with.
I’m not (yet) a Rust or PHP-internals expert. This is an open experiment in AI-assisted engineering. The wins and the failures are in the open, and the scoreboard never lies.
Ekin Ertac
The suite exposed a long list of features that appeared to work but did not. The clone keyword parsed without error and silently returned NULL, breaking every DateTimeImmutable operation in the engine. unset($arr[$key]) was a complete no-op. trim() ignored its second argument. Variable variables, static function variables, and spl_autoload_register() either did not exist or accepted input and did nothing with it. Each would have passed a live demo; none survived the corpus.
Getting WordPress to run introduced its own chain of blockers. PHP’s goto statement — used inside WordPress’s HTML parser — had to be supported. String replace’s by-reference count parameter, hex escape sequences inside regex character classes, and function_exists() being blind to half the engine’s built-ins all required fixes before wp-load.php would even bootstrap. A bug four layers deep in wpdb::prepare, caused by preg_split ignoring the PREG_SPLIT_DELIM_CAPTURE flag, was corrupting the database during installation.
The result is a fresh WordPress install that renders its front page and loads the admin dashboard from a SQLite database. The REST API remains untested, and the engine currently runs about 55 times slower than standard PHP on that page — 7.1 seconds versus 126 milliseconds. A bytecode virtual machine already in development is running micro-benchmarks at one to three times the speed of PHP 8.5 and is the next target for closing that gap. The source and live scoreboard are public at github.com/ekinertac/Phargo.
