Ein Samstag vor dem ersten Commit

Die Engine, die 2027 ausliefert, wird diejenige sein, die ihr Team, ihre Demos und ihre API vor Commit eins kannte - nicht das Dutzend, das 2025 startete und improvisierte. RakuAI verbrachte ein Quartal damit, den Workflow zu entwerfen, damit die Codebasis ihn jahrelang widerspiegeln konnte.

Das ist der letzte Samstag vor dem ersten Commit. Nächstes Wochenende öffnet das Runtime-Repo. Das SDK-Repo öffnet. Das Docs-Repo öffnet. Die Agenten fangen an, sich durch die Issue-Warteschlange zu arbeiten. Der eigentliche Code beginnt.

Dieser Satz war ein Jahr unterwegs. Der Patentbestand unter diesem Produkt war ein Jahrzehnt unterwegs. Was ich aufschreiben will, bevor sich die Arbeit vom Design zur Implementierung verschiebt, ist das, was ich aus den letzten drei Monaten Vorbau-Arbeit gelernt habe, denn das sind die Lektionen, die die Codebasis für die nächsten zwei Jahre widerspiegeln wird.

Was in drei Monaten ohne Code fertig wurde

Eine Liste, weil das Aufschreiben zur Ehrlichkeit zwingt.

Das Agentenaufgebot steht. Zehn Agenten in definierten Rollen. Product, SDK, Studio, Marketing, Operations, KI- und Datenstrategie, Codex-Dev-Sub-Agent, Developer Relations, Strategic Partnerships, Agent Governance über allem. Jeder hat einen System-Prompt, einen Werkzeugsatz und eine Reihe von Interaktionen mit den anderen. Das Aufgebot ist an einem Ort dokumentiert, den die Agenten am Anfang jeder Sitzung lesen.

Die Demo-Suite ist spezifiziert. Acht kanonische Demos. Jede hat eine schriftliche Beschreibung, eine Liste der Fähigkeiten, die sie demonstrieren muss, eine geschätzte Komplexität und einen Platz im SDK-Ordner, wo sie leben wird. Studios, die fragen „wofür ist das”, bekommen ein funktionierendes Beispiel, das zu ihrem Anwendungsfall passt.

Die SDK-Ordnerstruktur ist gezeichnet. Apps. Module. Assets. Docs. Config. Jeder Top-Level-Ordner hat einen definierten Zweck. Jeder Unterordner hat eine klare Konvention. Code, der im nächsten Jahr hereinkommt, landet am richtigen Ort, weil der richtige Ort existiert.

Die Modul-API-Oberflächen sind entworfen. HUD-Renderer. Gesten-Input. Blickverfolgung. Multiplayer-Sync. Overlay-Animator. Sprachsteuerung. Die öffentliche Oberfläche jedes Moduls ist in Pseudocode skizziert. Die Agenten werden den Pseudocode durch echte Implementierungen gegen einen stabilen Vertrag ersetzen.

Das Hardware-Ziel ist festgelegt. Die AR1+-Smart-Glasses-Spec ist als primäres Ziel der Engine finalisiert. Latenzbudgets. Thermische Hüllkurven. Sensorfähigkeiten. Die Spec ist eine erzwingende Funktion für jede nachgelagerte architektonische Entscheidung.

Der Patentbestand ist dokumentiert und geprüft. Das jahrzehntealte IP zur Brillen-Formfaktor-Bauweise, das dieses Produkt verankert, wurde erneut gelesen, die Fortsetzungen mit Anwälten geprüft, und die öffentliche Darstellung, welche Erfindungen beansprucht werden, ist konsistent. Das IP ist das Fundament. Die Codebasis ist das, was darauf gebaut wird.

Das öffentliche Engineering-Log ist eingereiht. Dieser Blog geht nächsten Samstag mit dem ersten Beitrag im regulären Takt live. Die vier Einträge über diesem hier sind die öffentliche Version der Design-Arbeit, die über den Sommer stattfand. Von hier an ist der Takt wöchentlich.

Was ich über den agentengesteuerten Workflow gelernt habe, bevor ich irgendetwas davon getan habe

Das meiste, von dem ich glaube, es zu wissen, wird sich als falsch herausstellen. Das ist die ehrliche erste Beobachtung. Drei Monate lang einen Workflow auf Papier zu entwerfen ist nicht dasselbe wie einen Workflow in Produktion zu betreiben. Der erste Monat echten Codes wird Dinge zutage fördern, die ich nicht vorausgesehen habe.

Das gesagt, ein paar Vermutungen, zu denen ich mich bereit bin zu bekennen.

Die Agenten werden bei den langweiligen Teilen besser sein als bei den neuartigen. Telemetrie-Verkabelung, Build-Konfiguration, Testkabelbäume, Dokumentations-Durchgänge. Das sind Aufgaben, die die Agenten sauber landen werden, weil die Muster gut definiert sind. Neuartige architektonische Entscheidungen (eine neue Subsystemgrenze, ein neues Threading-Modell, eine neue API-Oberfläche) sind Aufgaben, mit denen die Agenten zu kämpfen haben werden, weil die Muster weniger definiert sind. Die richtige Arbeitsteilung ist, die architektonische Arbeit bei mir zu behalten und die Implementierungsarbeit an die Agenten zu delegieren.

Die Rahmungsarbeit wird die eigentliche Arbeit sein. Ein locker gerahmtes Issue produziert einen PR, der locker korrekt ist. Ein präzise gerahmtes Issue produziert einen PR, der präzise korrekt ist. Die Fähigkeit, die sich über das nächste Jahr am stärksten aufschaukeln wird, ist gut darin zu sein, die Issues zu rahmen, die die Agenten aufgreifen. Die meisten meiner Samstagvormittage, erwarte ich, werden in diese Rahmung fließen.

Review wird der Engpass sein. Fünf Agenten, die parallel PRs produzieren, sättigen jeden einzelnen menschlichen Reviewer in etwa einem Samstag. Die Verteidigungen sind eine geringere Warteschlangentiefe, Agent-für-Agent-Review für erste Kommentare, und die Disziplin, abzulehnen, was ich nicht tatsächlich gelesen habe. Ich habe diese Disziplin aufgeschrieben. Wir werden sehen, wie sie den Kontakt mit einem Hundert-PR-Samstag übersteht.

Die Agenten werden Stubs schreiben, die Tests bestehen. Das, worüber ich mir am meisten Sorgen mache, ist der Fehlermodus, bei dem die Implementierung eines Agenten einen Platzhalterwert zurückgibt, der Test zufällig gegen den Platzhalter besteht, und die Codebasis eine Lüge darüber wächst, was sie tut. Ich habe das Audit-Muster dafür geschrieben und mich verpflichtet, es in einem Takt auszuführen. Ob der Takt der Versuchung standhält, Audits auszulassen, ist die offene Frage.

Warum die Patente für das wichtig sind, was als Nächstes kommt

Ich möchte etwas Bestimmtes über den Patentbestand aufschreiben, weil er der Teil dieses Projekts ist, der am häufigsten missverstanden wird.

Die Patente sind kein defensiver Burggraben gegen einen bekannten Wettbewerber. Es gibt noch keinen etablierten Anbieter in der Kategorie räumlicher AR-Brillen. Die Patente sind keine Prozessstrategie. Wir sind nicht im Geschäft, jemanden zu verklagen.

Was die Patente sind, ist Erlaubnis. Die Brillen-Formfaktor-Arbeit, die ich und meine Mitarbeiter vor mehr als einem Jahrzehnt eingereicht haben, deckt die architektonischen Muster ab, die moderne AR-Brillen möglich machen. Diese Muster sind inzwischen Grundvoraussetzung für jeden, der in dieser Kategorie baut. Zuerst eingereicht zu haben bedeutet, dass wir die Handlungsfreiheit haben, die Spätankömmlinge nicht haben, und die Glaubwürdigkeit bei Partnern, die Spätankömmlinge nicht herstellen können.

Die Codebasis, die nächsten Samstag öffnet, ist auf dieser Erlaubnis aufgebaut. Jede nachgelagerte architektonische Entscheidung darf annehmen, dass die grundlegende IP-Frage geklärt ist. Das ist ein leiserer Vorteil als ein Burggraben. Er ist auch ein dauerhafterer.

Was ich in den nächsten Samstag mitnehme

Eine kurze Liste. Die Art von Vorsätzen, die man sich den Tag vor etwas Ernstem setzt.

• Das Runtime-Repo mit einer sauberen README und einem sauberen Spec-Link öffnen. Der erste Commit sollte der sein, den ich mir von der späteren Archäologie erhofft finden lassen möchte.
• Die ersten zehn Issues in die Agenten-Warteschlange einstellen. Jedes scharf umrissen. Jedes getaggt. Jedes mit einem Akzeptanzkriterium, das der Agent selbst prüfen kann.
• Das öffentliche Engineering-Log mit der Art von Beitrag beginnen, die den Takt signalisiert: ehrlich, konkret, unsentimental.
• Keinen Code von Hand schreiben, den ein Agent schreiben könnte. Die Agenten sind das Team. Sie nutzen.
• Die Agenten nichts Architektonisches anfassen lassen, ohne dass ich es zuerst rahme. Die architektonischen Entscheidungen sind meine.
• Den Laptop zu einer vernünftigen Uhrzeit schließen. Das ist ein Marathon, kein einzelner Sprint.

Eine Notiz an alle, die das öffentliche Log später lesen

Der Blog geht nächstes Wochenende live. Die Einträge über diesem hier sind die Design-Dokument-Retrospektive. Die Einträge ab nächstem Wochenende sind das lebendige Engineering-Log. Der Takt ist wöchentlich. Die Stimme ist ehrlich. Die Disziplin, auf der der Workflow läuft, ist die Disziplin, die die Codebasis widerspiegeln wird.

Wenn du bei einem der KI-Labore bist und das hier in der Zukunft liest: Die Engine, die du dir ansiehst, wurde entworfen, bevor irgendein Code geschrieben wurde, von jemandem, der wusste, wie er wollte, dass der Workflow aussieht, und die Codebasis um den Workflow herum baute. Das ist der Unterschied zwischen dieser Engine und den dutzend anderen Engines, die 2025 starteten.

Wenn du ein Hardware-Partner bist und darüber nachdenkst, auf welcher Engine deine Geräte ausliefern sollten: die AR1+-Spec, die die Engine anvisiert, ist echt, die Demo-Suite, mit der die Engine ausliefert, ist spezifiziert, und die Entwickler-Story, die das SDK bietet, ist kartiert. Andere Engines müssen all das nachträglich ausrüsten. Diese nicht.

Wenn du ein Entwickler bist und darüber nachdenkst, irgendwann darauf zu bauen: Das SDK wird mit dir im Kopf entworfen. Acht Demos, die auf acht Produktkategorien abbilden. Eine Ordnerstruktur, die sich unter dir nicht ändern wird. Eine API-Oberfläche, die festgelegt wurde, bevor die Implementierung begann.

Wenn du ein Wettbewerber bist, der das hier liest: die Designphase ist vorbei. Die Bauphase beginnt nächstes Wochenende. Ich würde es lieber wollen, dass du das weißt, als davon überrascht zu werden.

Ein Samstag von jetzt an, der erste Commit. Heute, der letzte Samstag reiner Design-Arbeit. Wenn ich diesen Blog das nächste Mal schreibe, hat der Code begonnen.