Der wöchentliche Takt beginnt

Generativer Inhalt in einem Browser ist in Ordnung. Generativer Inhalt, verankert an der Wand deiner echten Küche, ist das Produkt. Das ist die Engine, die dafür gebaut wird, von deinem Modell Richtung zu nehmen, in jedem Simulationsschritt - Tag null, öffentlich.

Dieser Samstag beginnt den regulären wöchentlichen Takt auf diesem Blog. Die vier Einträge unter diesem waren die Design-Dokument-Samstage vom früheren Sommer: Agentenaufgebot, Demo-Suite, Ordnerstruktur, die letzte Reflexion, bevor der Code begann. Der Takt ist von hier an wöchentlich. Worum es im Blog geht, ist nicht neu.

Ich denke seit mehr als einem Jahrzehnt über AR-Brillen, real-welt-verankerte räumliche Erlebnisse und die richtige Form der Runtime nach, die sie antreibt. Ein Teil dieses Denkens wurde in den frühen 2010er-Jahren zu Patenten - dem Brillen-Formfaktor-Bestand, der das IP hinter dem, was wir jetzt bauen, noch immer verankert. Ein Teil davon wurde zu Prototypen, die nie das Tageslicht sahen. Das meiste lief im Hintergrund, während ich andere Arbeit machte.

Was sich im vergangenen Jahr geändert hat, ist, dass der Rest der Welt endlich aufgeholt hat. Rechenleistung ist klein genug. Optik ist gut genug. Cloud-LLMs sind echt genug. On-Device-Inferenz ist schnell genug. Das Produkt, das eine ein Jahrzehnt zu frühe Idee war, ist endlich ein Produkt, das man ausliefern kann.

Also habe ich angefangen auszuliefern. Der aktuelle Code-Lauf ist mehrere Monate alt. Die Commits leben in privaten Repos, die ich jetzt öffentlich mache, während ich sie aufräume und die Codebasis konsolidiere. Dieser Blog ist von hier an das öffentliche Protokoll.

Wie die nächsten Monate aussehen werden

Die Form des Plans für diesen Samstag, als Geschmacksprobe für das Kommende:

• Die Runtime: ein Entwurf der AR1+-Smart-Glasses-Spec liegt heute Morgen auf dem Schreibtisch. PDF-, PowerPoint- und Markdown-Versionen, damit ein LLM darüber nachdenken kann, ein Partner sie lesen kann und ein Designer sie prüfen kann. Der Punkt ist die Spec, nicht das Format. Das Format ist für die Leser.
• Eine main.cpp und ein Runtime-Main-Loop-Skelett, frisch eingecheckt.
• Ein Latenz-Tracker-Header und ein Implementierungs-Stub. Latenz wird die Kennzahl sein, die diese Engine definiert.
• Ein CMake-Build-Workflow in CI, damit jeder Push einen sauberen Build von einer sauberen Maschine bekommt.
• Ein Copilot-Onboarding-Guide, damit die Agenten im Team wissen, wie das Team arbeitet.

Das SDK-Repo bekam diesen Samstag auch sein eigenes Gerüst. Ein frühes Unity-HelloAR-Beispiel. Ein frühes Unreal-HelloAR-Beispiel. Header-Skelette für beide Bindings. Ein Paket-Veröffentlichungs-Workflow.

Nichts davon ist ausliefer-fertig. Alles davon ist das, was man braucht, bevor überhaupt etwas Ausliefer-fertiges möglich ist. Das Muster, beide Repos gleichzeitig in Bewegung zu bringen, mit bewusster Kopplung an den Nahtstellen, wird ein wiederkehrendes Thema sein.

Warum eine Smart-Glasses-Spec am ersten Tag des Öffentlichmachens

Die Spec ist eine bewusste Sache. Die meisten Engines wählen eine Runtime-Architektur und gehen dann Produkte shoppen, die plausibel darauf ausliefern könnten. Ich mache das in der anderen Reihenfolge. Das Produkt sind AR-Brillen, die Menschen in der Welt tragen, und die Engine muss die richtige Form für dieses Produkt haben. Also wird die Spec zuerst geschrieben, auch wenn sie roh ist.

Es ist kein Marketingdokument. Es ist eine erzwingende Funktion. Sie sagt, auf welcher Art von Hardware die Engine laufen muss, wie das Latenzbudget aussieht, wie die KI-Oberfläche in der Praxis aussehen muss. Jede nachgelagerte architektonische Entscheidung darf auf diese Spec zeigen und fragen „dient diese Entscheidung der Spec, oder dient sie einer anderen Engine, die ich stattdessen lieber bauen würde”. Diese zweite Kategorie ist der Ort, an dem Engine-Projekte sterben, und ich bin davon bisher ferngeblieben und habe vor, es weiterhin zu bleiben.

Warum ein Copilot-Guide am ersten Tag

Die andere bewusste Sache dieses Wochenendes ist der Copilot-Onboarding-Guide. Die erste Version ist roh. Sie wird zehnmal umgeschrieben werden. Aber der Guide existiert, weil die Agenten Teil des Teams sind, und das Team muss wissen, wie das Team arbeitet.

Der Guide sagt:

• Was die Strategie ist und welche Engine wir nicht bauen
• Wo die Roadmap lebt
• Wie Issues eingereicht, aufgegriffen und geschlossen werden
• Wie ein guter PR aussieht
• Was ein Reviewer tun soll (wobei der Reviewer manchmal ich bin und manchmal ein anderer Agent)

Die „Agenten lesen Dokumentation”-Rahmung ist kein Gimmick. Es ist die praktische Realität, einen Workflow zu betreiben, in dem das Team an Wochenenden ein Mensch ist und im Dauerbetrieb mehrere autonome Coding-Assistenten. Wenn der Guide schlecht ist, ist die Arbeit schlecht. Wenn der Guide gut ist, ist die Arbeit korrekt, und die Review-Kosten sinken.

Warum das öffentliche Log jetzt

Ein paar Gründe.

Die Patente sind jahrzehntealter Stand der Technik, über den niemand spricht, weil wir nicht darüber gesprochen haben. Die Brillen-Formfaktor-Arbeit, auf die die Engine zurückgeht, wurde still über Jahre erteilt und fortgesetzt. Ich möchte, dass das öffentliche Engineering-Protokoll auf die eigentliche Abstammung verweist. Räumliches AR ist keine neue Sache, die jemand letzten Sommer aufgegriffen hat. Die Arbeit geht zurück.

Partnerschaftsgespräche beginnen. Hardware-Partner, KI-Labore, Studios. Diese Gespräche werden schärfer, wenn es ein öffentliches Engineering-Protokoll gibt, das sie lesen können, statt eines Decks. Das Deck ist die aufgeräumte Version. Der Blog ist die tatsächliche Version.

Der Entwicklungsworkflow ist wirklich neu und es wert, gezeigt zu werden. KI-Agenten im Team ab dem ersten Tag der öffentlichen Phase. Mehrere Anbieter. Parallele Branches. Öffentliche Issue-Warteschlange. Nichts davon ist für dieses Projekt erfunden; was ungewöhnlich ist, ist, all das gleichzeitig bei etwas so Ernstem zu tun. Ich möchte es aufschreiben, während es passiert, während die Lektionen noch frisch genug sind, um ehrlich darüber zu sein.

Was ich möchte, dass Partner und Bauende daraus mitnehmen

Wenn du bei einem der großen KI-Labore bist und das hier liest, hier ist der Pitch. Die Engine wird explizit gebaut, um von deinem Modell Richtung zu nehmen. Nicht angeflanscht. Nicht in einem Editor-Panel. In der Runtime, auf dem Simulationsschritt, in jedem Frame. Die architektonischen Entscheidungen passieren gerade jetzt, öffentlich, mit einer expliziten Dokumentenspur. Wenn dein Modell besser darin wird, einen echten physischen Raum zu verstehen, in dem der Nutzer steht, ist diese Engine der Ort, an dem es mit diesem Verständnis etwas anfangen kann.

Wenn du ein Entwickler bist, der darüber nachdenkt, irgendwann darauf aufzubauen: Das SDK bewegt sich im Gleichschritt mit der Runtime. Unity- und Unreal-Beispiele sind ab diesem Wochenende im SDK-Repo gesät. Sie funktionieren noch nicht. Sie werden es. Der Grund, warum beide Bindings in dieser Phase existieren, ist, damit ich nie zu einem Moment sechs Monate in der Zukunft komme, an dem die Runtime-Architektur festgelegt ist und das SDK sich verbiegen muss, um zu passen.

Wenn du als Verbraucher auf das frühe Signal achtest, ist das Signal dies: Die Engine wird um die Annahme herum gebaut, dass die interessantesten Erlebnisse AR-Erlebnisse in echten Orten sind und die KI das ist, was diese Erlebnisse reagieren lässt. Generativer Inhalt in einem Browser ist in Ordnung. Generativer Inhalt, festgeklebt an einer Wand in deiner Küche, ist das eigentliche Produkt.

Heute ist Samstag. Der Blog ist live. Morgen geht es zurück ans Bauen.