To be upfront about what this is: I'm not a Rust developer or a PHP internals person. This is an experiment in whether the "point the AI at the original project's test suite" methodology (the way Bun was driven against real-world suites) holds up when the human can't review the code. The oracle is php-src's own .phpt corpus, ~22k tests I didn't write. Current honest score: 3,844 passing (17.4%), with a realistic ceiling around 40-45% since the rest tests C extensions (GD, curl, intl, etc.) that are out of scope.
"Renders WordPress" means: fresh install completes into SQLite, the front page renders with real posts, a real theme and /wp-admin/ renders without issues. The REST API is untested, and it's currently ~55x slower than PHP on the front page (a bytecode VM is in progress, micro-benchmarks are already at 1-3x of PHP 8.5).
The scoreboard auto-generates into the repo after every run, whether the number went up or down.
What I suspect is this 17% is the exact sub-set it needed to hack together to make the goal (running some example website) a reality as this is what those dodgy weasels do if you let them. Then you get to spend 200x the time to fill in the rest of the "speculative features deferred due to no real consumer" on top of whatever dodgy system they made up, which is usually whatever is easiest/closest to the literature instead of the actual intended design. Lots and lots of fun to be had doing the full-pipeline refactors to add that last 2% which need support from tip to tail.
I mean, I got them to 100% using the official conformance suite on my copy-and-patch jit compiler/interpreter WASM VM...
Saw that Salt Language article a day to two ago on how they do the static verification as part of the compilation process (or whatever they really get up to) and that's next on the agenda, tried that with a JavaCard VM I was poking at as its 'computation space' is much smaller but that was too much for my poor little laptop to handle but, apparently, this Salt thing is much different and actually tractable so, we'll see, still working out the details.
My boss asked me to set up a WordPress for a product landing page.
I naturally won't do this; it's no more than a couple of weeks ago that some SQL injection landed in the search query function of this monstrosity.
WordPress always was and always will be terrible.
So I set up the landing page with a Hugo static site, and I've been vibe-coding a WordPress-like dashboard that operates on git repositories containing Hugo sites.
I call it WorbPress (not released yet), and I'm sure that's what my boss told me to install, or I might've misheard.
And yes, it's written in Rust (with Axum and Alpine.js), because why not?
Ill preface my comment with saying: this might not be the best solution give the goal of your project to iteratively loop through and improve on the tests each round, and using deps would make that process longer/more complicated having to work potentially with another project.
.....however.....
mago, a static analyzer for php is written in rust and might be useful for gaining some "free" performance uplift: https://github.com/carthage-software/mago. iirc it splits out a far bit of its internals so they can be used by other projects (citation needed)
thanks, mago is a cool project. probably not as a dep tho, the parser isnt where the time goes (the 55x gap is all in evaluation, thats what the bytecode vm is for) and our parser is deliberatly tuned to match php's exact parse error messages, which is itself worth tests in the corpus. but using it as a second oracle to cross check my parser against theirs is actually a neat idea, same trick as the phpt suite but at the syntax layer.
its still iterating, 17% is just where the counter is today. three weeks ago it was at 10%, two weeks ago 13.8%. i didnt post this as a final result, i posted becuase wp-admin rendering surprised me.
but no, it cant reach 100%. around 55-60% of the suite tests C extensions, gd, curl, soap, intl, mysqli, ffi, sockets etc. passing those would mean writing all those extensions from scratch too (libcurl, ICU, an image library...) which is a completely different project. the realistic ceiling for a from scratch engine is around 40-45% and thats the number im climbing towards.
I feel like the future will be a git repository with text files and a markdown file describing how the site should look and how any endpoints needed for functionality should work and the AI will be the runtime for your site instead of wordpress.
Wow. Now did you try to check the setup with something like Claude Fable? Will it find issues, what kind of issues? Another question: how many tokens did this effort cost? Did you learn new prompting tricks?
19 comments
[ 2.8 ms ] story [ 34.4 ms ] threadTo be upfront about what this is: I'm not a Rust developer or a PHP internals person. This is an experiment in whether the "point the AI at the original project's test suite" methodology (the way Bun was driven against real-world suites) holds up when the human can't review the code. The oracle is php-src's own .phpt corpus, ~22k tests I didn't write. Current honest score: 3,844 passing (17.4%), with a realistic ceiling around 40-45% since the rest tests C extensions (GD, curl, intl, etc.) that are out of scope.
"Renders WordPress" means: fresh install completes into SQLite, the front page renders with real posts, a real theme and /wp-admin/ renders without issues. The REST API is untested, and it's currently ~55x slower than PHP on the front page (a bytecode VM is in progress, micro-benchmarks are already at 1-3x of PHP 8.5).
The scoreboard auto-generates into the repo after every run, whether the number went up or down.
Happy to answer anything.
But most of the stuff I’ve vibe coded this year has been astonishing by 2025’s standards.
If you got 100% I’d be genuinely blown away.
It's all in good fun, though... probably?
Saw that Salt Language article a day to two ago on how they do the static verification as part of the compilation process (or whatever they really get up to) and that's next on the agenda, tried that with a JavaCard VM I was poking at as its 'computation space' is much smaller but that was too much for my poor little laptop to handle but, apparently, this Salt thing is much different and actually tractable so, we'll see, still working out the details.
I naturally won't do this; it's no more than a couple of weeks ago that some SQL injection landed in the search query function of this monstrosity.
WordPress always was and always will be terrible.
So I set up the landing page with a Hugo static site, and I've been vibe-coding a WordPress-like dashboard that operates on git repositories containing Hugo sites.
I call it WorbPress (not released yet), and I'm sure that's what my boss told me to install, or I might've misheard.
And yes, it's written in Rust (with Axum and Alpine.js), because why not?
.....however.....
mago, a static analyzer for php is written in rust and might be useful for gaining some "free" performance uplift: https://github.com/carthage-software/mago. iirc it splits out a far bit of its internals so they can be used by other projects (citation needed)
Surely it can just keep iterating until it implements the full test suite?
but no, it cant reach 100%. around 55-60% of the suite tests C extensions, gd, curl, soap, intl, mysqli, ffi, sockets etc. passing those would mean writing all those extensions from scratch too (libcurl, ICU, an image library...) which is a completely different project. the realistic ceiling for a from scratch engine is around 40-45% and thats the number im climbing towards.
https://frankenphp.dev/
no, i don't think i will