Ekin Ertac's AI-built PHP engine now renders WordPress

Why it matters

Phargo is a clean case study in AI-assisted engineering where the human founder contributes targets, constraints and verification, while the model writes code against an external test oracle.

Ekin Ertac has pushed Phargo, a from-scratch PHP engine written in Rust by an AI coding agent, far enough to render a real WordPress page and pass thousands of upstream PHP tests.

That is the useful part of the story. The sharper part is how little Ertac claims to understand about the implementation itself. In a July 5 blog post, Ertac writes that he does not know Rust, has never written a lexer, and could not explain a tree-walking evaluator without looking it up. His role, as he describes it, is to aim the agent at a measurable target, read the result, and decide whether to continue.

Phargo is the latest entrant in a growing class of AI-era personal infrastructure projects where the founder's core skill is not hand-writing every subsystem. It is setting the test, choosing the next failure cluster, and refusing to let the model judge its own output. Ertac's version of that discipline is unusually concrete: Phargo runs against PHP's own .phpt corpus, a test suite maintained upstream by PHP's contributors and executed by PHP's own runner. The pass rate is auto-generated into the repo after each run.

Ertac's post reported 3,844 passing tests out of 22,037, or 17.4% of the full upstream corpus, and the progress is tracked publicly in PROGRESS.md. The repo separates a small curated smoke-test set from the upstream score so the headline number reflects tests neither he nor the agent wrote.

The founder is testing the workflow as much as the runtime

Ertac's public trail makes Phargo look less like a one-off stunt than a continuation of a 2026 obsession. His blog index lists recent posts about building a coding agent, building a 10,000-player game server in Elixir despite not speaking Elixir, and turning a CSS change into a performance chase. The Phargo post fits that same pattern: pick an unfamiliar technical surface, give an agent room to work, then wrap the work in an external measurement system.

The Phargo repository positions the project as a memory-safe PHP engine in Rust, built by driving an AI against the original project's test suite, with a scoreboard that runs the .phpt files and writes PROGRESS.md.

PHP's own documentation says a PHP build is tested with make test, which runs run-tests.php under the source root. The docs also describe .phpt tests as files that bundle code with expected output, giving implementers a standard way to check runtime behavior. Phargo's bet is that this decades-deep corpus can serve as a substitute for the human expertise Ertac says he lacks.

That substitute is imperfect, and the post is strongest when it says so. Early Phargo runs failed whole categories of tests because the local harness compared output byte-for-byte while the corpus had been checked out with Windows CRLF line endings. PHP's own runner normalizes line endings. Phargo's did not. One normalization fix flipped hundreds of tests green, according to Ertac. The lesson was not that the AI had suddenly become better at PHP. The measuring system had been wrong.

WordPress is the right target, with the wrong easy conclusions

The WordPress page matters because WordPress is a compatibility minefield. Ertac says Phargo rendered a 26 KB front page with a Phargo Test Site title, block-library CSS, Hello world! content pulled from SQLite, and a clean closing HTML tag. The same post says a fresh install runs, the front page renders from the database, and /wp-admin/ renders as well.

That is a meaningful milestone. It is also narrower than a production claim. The repo points to a longer-term target of bringing WordPress to the browser via a Rust-to-WASM path, not replacing server-side PHP outright.

That target puts Phargo near an existing technical pressure point. WordPress Playground already runs WordPress in the browser by compiling the C PHP interpreter to WebAssembly via Emscripten. In March, the Playground team wrote that its PHP WebAssembly binaries across supported builds and versions totaled 888 MB before two compiler flag changes cut them to 766 MB, a 122 MB reduction. Phargo's README points at that binary-size fight and argues that a Rust PHP engine compiled to WASM could be smaller while keeping memory safety. That remains a future goal, not a result.

The public evidence today is a Rust interpreter that can render a simple WordPress page locally and pass 3,844 upstream PHP tests. The browser claim remains the destination.

The AI did not remove the hard parts

The post's technical detail cuts against the lazy version of the AI-coding story. Phargo did not become useful because the model produced a clean implementation in one pass. It advanced through the same ugly compatibility work that defines language runtimes: goto, by-reference parameters in str_replace, regex escape handling, function_exists(), preg_split flags, autoloading, catch (\Throwable), variable variables, static function variables, clone, unset, and trim behavior.

Ertac also describes a familiar bug pattern the corpus finds relentlessly: features that parse and run without error while doing nothing. These are exactly the bugs a demo misses and a compatibility suite punishes.

The repo's internal agent guide, CLAUDE.md, shows the operational side of that punishment. It tells the agent that resource guards are mandatory because the corpus contains memory and CPU traps, notes a 6 GiB capped allocator, and instructs it to run a roughly seven-minute release-mode scoreboard before committing only if the number rises without regressions. It also warns the agent away from out-of-scope C extensions.

That is why the 17.4% figure needs context. Ertac argues the realistic ceiling for the current scope is around 40% to 45%, because much of the PHP corpus covers C extensions such as GD, curl, SOAP, intl, and MySQL-related drivers.

The pattern is bigger than PHP

Phargo sits in the same founder-led build pattern we have been tracking across recent projects. Ammaar Reshi used Claude Fable to bring a 2003 real-time strategy game to Apple platforms, with users still needing their own EA assets (our coverage). Vincenzo's NanoEuler rebuilt a GPT-2-scale training stack in C and CUDA as a learning project rather than a chatbot product (our coverage). AISlop turned AI-generated code smells into a CLI and GitHub Action that can fail CI (our coverage).

The common thread is verification. The projects that matter are not the ones with the boldest AI authorship claims. They are the ones that make the claim falsifiable: compile the game, train the model, fail the CI rule, pass the upstream corpus.

Ertac's advantage is that PHP gives him a brutal external judge. The corpus does not know or care that the code was written by an agent, that the human cannot read Rust fluently, or that a simple WordPress page now renders. It counts behavior. For an AI-built runtime, that is the only scoreboard worth watching.