Zwei Monate öffentlich, Jahre unter der Haube

Die meisten "KI-nativen" Engines schrauben ein Chat-Panel in einen Editor. RakuAI behandelt das Modell als Steuerungseingabe in jedem einzelnen Frame — und zwei Monate später liefert diese These Code, keine Foliensätze.

Der Plan für diesen Samstag war, langsamer zu machen und nachzudenken. Drei Commits das ganze Wochenende, die niedrigste Zahl, seit ich das öffentliche Log begonnen habe. Die Agenten laufen absichtlich kühler; meine Aufmerksamkeit gilt der Architektur statt dem Ausliefern von neuem Code. Die Codebasis endet das Wochenende ungefähr dort, wo sie begonnen hat, was für die Art von Arbeit, die ich gemacht habe, der richtige Zustand ist.

Vor zwei Monaten heute war das öffentliche Runtime-Repo ein leeres README. Die Engine und das dahinterstehende Patent-Portfolio reichen weiter zurück. Die Art von Wochenende, über die es sich zu schreiben lohnt, ist die, an der man Bilanz zieht. Also ist das hier genau das.

Was die Engine heute tatsächlich ist

Wenn ich Raku in einem Absatz jemandem beschreiben müsste, der nicht mitgelesen hat, würde die Beschreibung lauten:

Eine plattformübergreifende AR-Runtime, geschrieben in C++ und über eine stabile C-API freigelegt, mit Unity- und Unreal-SDK-Bindings. Sie zielt primär auf AR-Brillen ab und läuft auf jeder heute verfügbaren Hardware (derzeit für Meta-Quest-Passthrough in Vorbereitung, mit Desktop- und Mobile-Preview-Builds). Sie ist von Grund auf um die Annahme herum gestaltet, dass KI ein Runtime-Anliegen ist, kein Editor-Feature. Submillimeter-Anchoring wird unterstützt. OpenXR ist das Konformitätsziel, wo Standards existieren. Die Codebasis wird von autonomen Coding-Agenten im Entwicklungsteam gebaut, die durch eine öffentliche Issue-Warteschlange arbeiten.

Dieser Absatz wäre am ersten Tag ein ambitioniertes Leitbild gewesen. Jetzt ist es eine Beschreibung dessen, was im Repo steckt.

Was mich an den letzten zwei Monaten überrascht hat

Drei Dinge.

Der agentengetriebene Workflow skalierte über das hinaus, was ich erwartet hatte. Ich hatte die Sorge, dass die autonomen Agenten eine Codebasis produzieren würden, die in isolierten PRs funktioniert und über viele Merges hinweg zu Brei wird. Der Brei ist nicht eingetreten. Die Codebasis ist nach zwei Monaten kohärenter als Codebasen, die ich von menschlichen Teams nach zwei Jahren geerbt habe. Der Grund ist die Disziplin, über die ich jedes Wochenende schreibe (kleinere Warteschlange, früheres Review, Multi-Vendor-Pairing für Review-Unabhängigkeit, Dokumentation als Eingabe). Diese Disziplinen funktionieren.

Der Hardware-Pivot war weniger teuer, als ich befürchtet hatte. Der Wechsel von AR1+ als Produktziel zu AR2 Gen1 Anfang Oktober war eine Entscheidung, mit der ich mehrere Tage gerungen habe, weil die Kosten groß aussahen. Die tatsächlichen Kosten waren ein paar PRs (ein gründlicher Umbenennungs-Sweep, ein Dokumentationsdurchgang). Der Grund, warum die Kosten klein waren, ist die früh etablierte modulare Architektur. Subsysteme, die nichts über die Gerätetyp-Grenze wissen mussten, mussten sich nicht ändern. Diejenigen, die es mussten, änderten sich sauber über ihre klar definierten Oberflächen. Das ist die Dividende dafür, die Architektur früh zu ziehen.

Die Partnergespräche finden früher statt, als ich geplant hatte. Ich hatte erwartet, bis Jahresende im Modus “Engine bauen, Demo ausliefern, dann Partnergespräche führen” zu sein. Die tatsächliche Reihenfolge war “Engine bauen, unterwegs Partnergespräche führen, die informieren, was als Nächstes gebaut wird, dann Demos ausliefern, die zu dem passen, was diese Gespräche brauchen.” NTT QONOQ. Meta. Die nächsten will ich noch nicht nennen. Die Gespräche sind gerade schärfer als die Demos, was ein guter Ort ist, um zu sein.

Wo sich die Architektur gesetzt hat

Eine kurze Liste der architektonischen Entscheidungen, die ich nicht mehr erwarte, überdenken zu müssen:

• Die Runtime ist C++, freigelegt über eine stabile C-API. Andere Sprachbindings sitzen auf der C-API, nicht direkt auf C++.
• Das SDK ist von Tag eins an Multi-Binding. Unity und Unreal sind erstklassig. Godot ist auf der Roadmap. Web-nativ ist auf der Roadmap. Die C-API ist der Engpass. Die Bindings sind es nicht.
• Subsysteme sind DLLs. Jedes hat eine öffentliche Oberfläche; nichts innerhalb eines Subsystems greift auf die Interna eines anderen Subsystems zu. Die Oberflächen sind reviewte PRs.
• KI ist ein Runtime-Anliegen, kein Editor-Feature. Die KI-Arbeit, die in der Engine steckt, läuft in jedem Frame auf dem Simulationsschritt. Die Cloud-LLM-Arbeit, die in der Engine steckt, integriert sich zur Laufzeit in die Voice-Pipeline. Keines von beiden ist ein Panel in einem Autorenwerkzeug.
• OpenXR ist der Standard, wo der Standard passt. Anbieterspezifischer Code sitzt hinter Feature-Flags und Provider-Mustern. Ein neues OpenXR-konformes Geräteziel zu übernehmen ist eine anbieterspezifische Klebeschicht, kein Runtime-Rewrite.
• Der Entwicklungsprozess ist von Grund auf Multi-Vendor. Das Modell, das ein Stück Code schreibt, kann nicht das Modell sein, das es reviewt. Das Labor, dessen Modell gerade in einer bestimmten Rolle am besten ist, bekommt diese Rolle, bis ein anderes Labor besser ist.

Was ich noch erwarte zu überdenken:

• Die genaue Arbeitsteilung zwischen On-Device-Inferenz und Cloud-LLM-Intent. Das wird schärfer, sobald die TFLite-Arbeit reift und die Cloud-LLM-Schnittstelle durch echte Partner beansprucht wird. Die aktuelle Trennlinie ist vorläufig.
• Die Form des Experience-Definitionsdateiformats. Das Grundgerüst steht. Das Schema wird sich weiterentwickeln. Ich erwarte mindestens einen Major-Version-Sprung, bevor das Format stabil ist.
• Die Platzierung der Zustandssynchronisation für Multiplayer-AR. Wir haben heute einen Low-Latency-Delta-Kanal. Ob die richtige langfristige Antwort ein Peer-to-Peer-Mesh, ein gehosteter autoritativer Server oder eine Hybridlösung ist, ist noch nicht entschieden. Die Zwei-Spieler-Demos, die im Dezember ausgeliefert werden, werden diese Entscheidung informieren.

Der Weg zur Produktionsreife im Dezember

Ich ziele still auf einen Dezember-Meilenstein hin, an dem die Engine “produktionsreif für Partnerteams, um ernsthafte Demos darauf zu bauen” ist. Das ist kein öffentlicher Launch. Es ist die interne Messlatte, ab der ich bereit bin, ein Partnerteam einzuladen, mit dem Bau gegen die Runtime zu beginnen, ohne es vor einem halben Dutzend grober Kanten zu warnen.

Was noch passieren muss, um diese Latte zu reißen:

• Die KI-Subsysteme für die Runtime (Behavior Trees, Navigation Mesh, Crowd-Simulation, Sensorik-Systeme, Entscheidungsbäume). Derzeit in Design-Dokumenten skizziert; die Implementierung landet im Dezember und am ersten Januarwochenende.
• Windows-MSVC-Build-Sauberkeit. Ich habe die Runtime seit Oktober nicht tatsächlich unter Visual Studio 2026 gebaut. Ich bin mir ziemlich sicher, dass das ein Kampf wird. Ich schreibe darüber, wenn es so weit ist.
• Ein kanonisches Beispiel-Paket, das eine nicht-triviale AR-Erfahrung durchgängig sowohl über die Unity- als auch die Unreal-Bindings demonstriert, mit angeschlossener Voice-Pipeline und Cloud-LLM.
• Ein föderierter Sync-Pfad zur Verteilung von Modell-Updates an Geräte im Feld. Der Krypto-Teil muss produktionsreif sein, nicht Stub-Niveau.
• Der Runtime-Updater. Wir müssen in der Lage sein, einen neuen Build an das Dev-Kit eines Partners auszuliefern und ihn sauber installieren zu lassen.

Das ist die Liste. Sechs Wochen, um sie abzuarbeiten. Das Dezember-Commit-Volumen wird hoch sein.

Was Builder und Partner daraus mitnehmen sollen

Wenn Sie das öffentliche Log seit zwei Monaten lesen, haben Sie die Engine in Echtzeit zusammenwachsen sehen. Das Tempo ist hoch; die Disziplin ist echt; die architektonischen Entscheidungen sind dokumentiert. Das ist die Engineering-Kultur, mit der diese Engine gebaut wird. Es ist die Engineering-Kultur, mit der Sie arbeiten werden, wenn Sie darauf aufbauen.

Wenn Sie ein Partner sind, der überlegt, ob er ein ernsthaftes Gespräch beginnen soll: Das Gespräch ist gerade schärfer als die Demos, und das mit Absicht. Ich höre lieber, was Ihr Produkt tatsächlich braucht, und lasse das formen, was gebaut wird, statt eine Demo zu bauen und sie im Nachhinein an Ihre Bedürfnisse anzupassen. Das Fenster, um zu formen, was der Dezember liefert, ist bis Ende November offen.

Wenn Sie Entwickler sind und auf Stabilität warten: Stabilität ist das Dezember-Liefergut. Die Engine befindet sich heute in einer aktiven genug Entwicklung, dass ich noch nicht empfehlen würde, ernsthaften abhängigen Code darauf zu bauen. In zwei Monaten wird die Empfehlung eine andere sein.

Ruhiger Samstag. Zwei Monate rum. Nächstes Wochenende geht es zurück ans Bauen.