Joël Wurtz von JoliCode berichtet, wie er rphp baute, eine experimentelle PHP-VM in Rust, bei der Large Language Models als Beschleuniger dienten, nicht als Autoren. Ein erster Prototyp entstand an einem einzigen Tag aus dem Wissen des Modells heraus. Er führte eine relevante Teilmenge von PHP aus, war aber extrem langsam und implementierte eine Stack-VM, während PHP eine Register-VM ist – ein Unterschied, der die Destruktionsreihenfolge von Werten und das Timing von Fehlern verändern kann, worauf bestehende Bibliotheken angewiesen sein dürften.

Bewusst war das Ziel nicht, die Zend Engine zu klonen. Wurtz kritisiert Rewrites wie den von Bun wegen des massiven Einsatzes von unsafe-Blöcken, was aus seiner Sicht den Sinn von Rust untergräbt. Stattdessen ging es darum zu verstehen, warum PHP so funktioniert, wie es funktioniert, und eine VM nach Rusts Philosophie zu entwerfen: Ownership, kein globaler mutierbarer Zustand, minimales unsafe. Das Lesen der Zend-Engine-Quellen mit der KI als Diskussionspartner zeigte, dass manche Optimierungen auf älteres CPU-Verhalten zurückgehen, PHP in anderen Fällen aber schon vor Jahren die beste Lösung gefunden hatte.

Zwei Architekturideen stechen heraus. Die VM ist ein in sich geschlossenes Objekt, das mehrfach pro Thread instanziiert werden kann, was Tests und Embedding vereinfacht. Und ein Fork-Modell erlaubt es, eine vorgeladene, pausierte VM per Copy-on-Write pro Request zu klonen: Symfony-Kernel booten, teure Daten cachen, rphp_request_pause() aufrufen – jeder Request startet aus diesem warmen Zustand, bleibt aber isoliert. Das liegt zwischen klassischem PHP pro Request und FrankenPHPs Worker-Modus.

Aktueller Stand: Rund 80 % der Basis-Kompatibilitätstests bestehen. Reine PHP-Ausführung ist 5- bis 15-mal langsamer als die Zend Engine, doch der Fork-Modus ist etwa 30-mal schneller als der klassische Modus der eigenen VM – genug, um PHP mit FrankenPHP im klassischen Modus in der Symfony-Demo-Anwendung zu schlagen, weil der Anwendungszustand nicht pro Request neu aufgebaut wird.

Das Projekt dauerte etwa einen Monat mit einem Claude-Max-20x-Plan (ca. 200 €) unter Nutzung von Opus 4.8, Sonnet 4.6 und zeitweise Fable; bei konstantem Steuern hätte Wurtz zufolge jedes der drei Modelle ähnliche Ergebnisse geliefert. Sein Fazit: KI liegt selten beim ersten Versuch richtig, produziert mitunter schlampigen oder falschen Code, der verifiziert werden muss, und ersetzt kein Verständnis – Rusts strenge, deterministische Constraints machen die Sprache besonders gut für KI-gestützte Arbeit geeignet, weil Fehler automatisch sichtbar werden. Der Code liegt auf GitHub unter jolicode/rphp.