282 Commits, erstes Wochenende im öffentlichen Log

Die C-API war der Commit, der zählte: der Moment, in dem die Runtime eine stabile öffentliche Oberfläche hatte, hörten zwei Ströme agentenverfassten Codes auf, sich gegenseitig auf die Füße zu treten. So sieht eine KI-native Runtime aus, wenn die Schleife klickt.

Letzten Samstag habe ich einen Stapel Issues eingereicht und einen autonomen Coding-Agenten auf die Warteschlange angesetzt. Bis Sonntagabend, am Küchentisch sitzend mit dem Laptop ein letztes Mal offen vor Montag, waren 282 Commits im Runtime-Repo gelandet. Ich war bei einem kleinen Bruchteil davon der Autor. Ein autonomer Coding-Agent war der Autor der meisten übrigen.

Der Grund, warum die Zahl wie eine Sprintwoche Arbeit aussieht, ist, dass die Arbeit kontinuierlich passiert, während ich nicht an der Tastatur bin. Ich bin an Wochenenden an der Tastatur. Die Agenten haben keinen Brotjob. Die Ausgabe ist das, was aus dieser Anordnung herausfällt.

Wie die Warteschlange funktioniert

Samstagmorgen ist Einreichungstag. Ich setze mich mit Kaffee hin und schreibe GitHub-Issues. Jedes ist ein scharf umrissenes Stück Arbeit, das die Engine als Nächstes braucht. Die Form ist ungefähr:

• Ein Subsystem oder ein Feature pro Issue
• Ein klares Akzeptanzkriterium, das der Agent selbst prüfen kann
• Verweise auf die relevanten Docs, die Spec und alle bestehenden Dateien, die die Arbeit berühren sollte
• Ein explizites „agent-queue”-Label

Es gibt auch einen nächtlichen Workflow (Issue #37 im Runtime-Repo dieses Wochenende), der sicherstellt, dass die Warteschlange nie unter fünfzehn offene Agenten-Issues fällt. Falls doch, entwirft der Workflow Platzhalter-Aufgaben aus der Roadmap. Der Agent liest die Warteschlange, greift das nächste auf, das er erledigen kann, öffnet einen Draft-PR, iteriert und markiert sich schließlich als bereit für Review.

Samstag bis Sonntag prüfe und merge ich. Wo der Agent etwas falsch gemacht hat, schließe ich den PR, schärfe das Issue und reiche es neu ein. Wo der Agent es richtig gemacht hat, landet der PR und das Issue schließt sich. Der Rhythmus ist Einreichen zu Beginn des Wochenendes, Prüfen über beide Tage, und eine frische Warteschlange hinterlassen, wenn der Laptop Sonntagabend zugeht. Der Agent kaut sich durch die Warteschlange, während ich zurück im Brotjob bin.

Das ist der Workflow. Er ist nicht subtil. Der Grund, warum es sich lohnt, ihn aufzuschreiben, ist, dass er funktioniert.

Was gebaut wurde

Die Schlagzeilen aus den 282 Commits:

• Ein echter Runtime-Main-Loop, nicht nur ein Skelett
• Ein Latenz-Tracker, der End-zu-End-Timing von Sensor-Input bis Rendering misst
• Ein Speichernutzungs-Monitor mit konfigurierbaren Schwellenwerten und periodischer Berichterstattung
• Ein Logging-Subsystem mit INFO-/WARNING-/ERROR-Stufen, Konsolen- und Datei-Ausgaben
• Fehlerbehandlung mit Signal-Handlern für sauberes Herunterfahren
• Eine C-API, die die Runtime exponiert, damit das SDK sich andocken kann
• Ein Modul-/Agenten-Verwaltungssystem in der C-API für SDK-Integration
• Das Runtime-Nebenläufigkeitsmodell: Task-Warteschlangen und Worker-Threads
• Ein umfassender Testkabelbaum
• ABI-Verifikation und SDK-Verknüpfungsvalidierung
• AR1+-Smart-Glasses-Spec als Produktziel finalisiert

Nichts davon ist glamourös. Alles davon ist das, was eine AR-Runtime braucht, bevor irgendetwas Interessantes darauf gebaut werden kann.

Der wichtigste Commit, rückblickend, ist die C-API-Exposition. In dem Moment, in dem die Runtime eine stabile öffentliche Oberfläche hatte, an die sich das SDK andocken konnte, hörten die Runtime-Arbeit und die SDK-Arbeit auf, sich gegenseitig auf die Füße zu treten. Vor diesem Commit musste jede Änderung im einen Repo sorgfältig mit dem anderen synchronisiert werden. Danach entkoppelten sie sich. Zwei Ströme agentenverfassten Codes konnten parallel laufen, ohne Merge-Konflikte zu erzeugen.

Was mich überrascht hat

Drei Dinge.

Der Agent ist bei langweiliger Infrastruktur schneller, als ich es gewesen wäre. Telemetrie, Logging, Fehlerbehandlung, Testkabelbäume. Das sind die Art von Aufgaben, bei denen ein Mensch abgelenkt wird, weil die Arbeit unglamourös ist. Der Agent wird nicht abgelenkt. Er landet einfach den Diff.

Der Agent ist konservativ bei der Architektur. Gib ihm ein Issue, das sagt „implementiere einen Latenz-Tracker, der Sensor-zu-Render-Zeit misst”, und er baut genau das. Er erfindet keine Metaphysik dafür, was Latenz bedeutet, und schlägt keine andere Form für die API vor. Das ist gut. Architektur ist mein Job. Implementierung ist der Job des Agenten.

Warteschlangen-Auffüllung ist der Engpass. Wenn der Agent an einem Tag fünfzehn PRs ausliefert und die Warteschlange bis zum Abend leer ist, hört der Durchsatz auf, davon abzuhängen, wie schnell der Agent arbeitet. Er fängt an, davon abzuhängen, wie schnell ich die nächsten Aufgaben artikulieren kann. Das hat die Samstagvormittage umgeformt. Die erste Stunde ist Einreichen.

Was kaputtging

Zwei Dinge, keins davon fatal.

Der CMake-Build ging zweimal kaputt, als der Agent Code landete, der isoliert kompilierte, aber nicht gegen den Rest der Runtime verlinkte. Beide Male war die Lösung dieselbe: Der Agent hat noch keinen vollen Überblick über den Link-Zeit-Graphen des Projekts. Die Lösung liegt in der Issue-Rahmung. Von jetzt an sagt jedes Issue, das eine Bibliothek berührt, explizit, welche anderen Bibliotheken dagegen verlinken.

Der Testkabelbaum wurde spät im Lauf hinzugefügt und legte sofort vier Bugs in früheren PRs offen, die manuelle Smoke-Tests bestanden, aber am neuen Kabelbaum scheiterten. Die Lektion dort ist die unsexy: Tests als Teil des Features schreiben, nicht als Nachtrag. Der Agent tut das, wenn das Issue es sagt. Er tut es nicht, wenn das Issue es nicht sagt. Es immer sagen lassen.

Was ich Partnern und Bauenden mitteilen möchte

Die Form dieser Engine wird gerade jetzt gebaut. Bis Ende nächsten Monats werden die meisten grundlegenden Entscheidungen feststehen. Wenn du bei einem Modelllabor bist und Meinungen dazu hast, wie die KI-Ebene andocken sollte, ist dies das Zeitfenster, in dem Meinungen billig einzubauen sind. Wenn du ein Entwickler bist, der über Unity- oder Unreal-Integration nachdenkt, wird das SDK dieses Wochenende geformt, und die Bindings spiegeln wider, was die Runtime kann. Ich würde lieber in Woche sechs von dir hören als in Woche sechzig.

Das Runtime-Repo ist offen. Das SDK-Repo ist offen. Die Warteschlange offener Issues ist offen. Das in Echtzeit zu beobachten ist der ganze Sinn.

282 Commits, erstes Wochenende im öffentlichen Log. Sonntag in der Tasche. Montag als Nächstes.