Hardware validieren, bevor das Silizium da ist

Die traditionelle Antwort auf das Warten auf Silizium ist, zu sitzen und zu warten. Die moderne Antwort ist, alles nachgelagerte der Hardware zuerst zu bauen und es grün zu haben, bevor die Teile ankommen - damit deine Hardware schneller auf RakuAI ausliefert als die Konkurrenz.

Eine Entscheidung, an der ich die Arbeitswoche über gekaut hatte, wartete am Küchentisch, als das Wochenende begann. Das Produktziel von AR1+ auf AR2 Gen1 verschieben. Alles nachgelagerte der neuen Spec bauen, bevor das Silizium ankommt, sodass die Validierung, wenn das Silizium tatsächlich ankommt, am ersten Tag beginnt statt am neunzigsten.

Es gibt eine Phase, die jedes Hardware-Produkt durchläuft, in der die Spec existiert, der Validierungsplan existiert, der Testkabelbaum existiert, und das eigentliche Silizium nicht. Die traditionelle Antwort ist, zu sitzen und zu warten. Die moderne Antwort ist, alles zu bauen, was nachgelagert der Hardware ist, und es grün zu haben, bevor die Teile ausliefern.

Dieses Wochenende war das. Die Zielplattform verschob sich offiziell von AR1+ auf AR2 Gen1, und die technische Antwort war, sofort die Validierungsinfrastruktur zu bauen, die die neue Plattform brauchen wird, bevor irgendeiner von uns die neue Plattform überhaupt anfasst.

Was gelandet ist

Fünf Dinge, alle dieses Wochenende gelandet:

• Die AR2-Gen1-Geräte-Bring-up- und Sensorintegrations-Infrastruktur
• Eine Wi-Fi-7-Konnektivitäts- und Tracking-Stabilitäts-Testsuite
• Ein Thermik- und Strom-Validierungs-Framework
• CI-Smoke-Tests mit Metrikanalyse und Berichterstattung
• Die AR2-Gen1-Hardware-Validierungsdokumentation und Produktionsstandards-Spec

Alles davon durch Feature-Flags gegattert, sodass der AR1+-Codepfad weiterhin funktioniert und nichts in der bestehenden Runtime regrediert. Die Agenten, die diese PRs gelandet haben, machten die langweilige Disziplin richtig: Jede neue Datei ist hinter einem Build-Flag versteckt, jede API-Ergänzung ist nicht-brechend, jeder Test läuft in CI, auch wenn es kein AR2-Gerät gibt, gegen das er laufen könnte. Die Tests simulieren. Die Simulation ist gut genug, um Schnittstellen-Drift, fehlende Exports und kaputte Sensorabläufe zu fangen.

Das war ein Wochenende mit 77 Commits. Die meisten dieser Commits stehen im Dienst eines Geräts, das ich nicht in der Hand halten kann.

Warum das sinnvoll ist

Ein paar Gründe.

Hardware-Validierung, die mit der Hardware ausliefert, ist Hardware-Validierung, die sechs Monate zu spät ankommt. Das Thermik- und Strom-Framework, das dieses Wochenende geschrieben wurde, wird am Tag verwendet, an dem das erste AR2-Dev-Kit meinen Schreibtisch erreicht, nicht drei Monate danach. Die erste thermische Regression der Plattform wird von einem bestehenden Test gefangen, nicht von einem Menschen, der bemerkt, dass das Gerät heiß ist.

Ein Testkabelbaum ohne Gerät ist immer noch ein Testkabelbaum. Er läuft gegen simulierte Sensorspuren. Diese Spuren stammen aus der AR1+-Ära und aus der Spec. Sie sind nicht perfekt. Sie fangen Schnittstellenbugs, Integrationsbugs und Metrik-Erfassungsbugs. Sie fangen nicht die Bugs, die sich erst unter echtem Silizium zeigen werden. Das ist in Ordnung. Die Bugs, die sie fangen, sind die Bugs, mit deren Jagd wir sonst die erste Woche echter Hardware-Zeit verbracht hätten, und das müssen wir jetzt nicht mehr.

Der Akt, den Kabelbaum zu schreiben, klärt die Spec. Die Hälfte des Produktionsstandards-Dokuments, das bis Sonntagabend landete, existierte zu Beginn des Wochenendes nur als vage Absicht. Das Schreiben der Validierungstests zwang die Spec in konkrete Zahlen. Frame-Budgets. Thermische Hüllkurven. Wi-Fi-7-Stabilitätsschwellenwerte. Der Kabelbaum machte das Dokument scharf. Das ist das eigentliche Ergebnis.

Wie der Agent den Wechsel handhabte

Der Wechsel von AR1+ zu AR2 Gen1 wurde beim ersten Mal nicht sauber gehandhabt. Mitten im Wochenende landete der Agent einen PR, der an Stellen, an denen der neue Codepfad „AR2” sagen sollte, „AR1+” referenzierte. Das landete, weil die Issue-Rahmung die Umbenennung nicht kennzeichnete. Die Lösung war ein separater PR mit dem Titel „Fix AR1+ vs AR2 device discrepancy in documentation and copilot instructions”, der 121 einzelne Referenzen durchkämmte und in Einklang brachte.

Das ist die Art von Ding, die nicht passiert, wenn ein einzelner Mensch den gesamten Code schreibt, weil der einzelne Mensch einfach im Vorbeigehen umbenennt. Es passiert in einem agentengesteuerten Workflow, wenn der Agent ein Issue aufgreift, das einer Umbenennung vorausgeht, und getreu den alten Namen schreibt. Die Abhilfe ist, die Docs, die der Agent als Input liest, vollständig mit der aktuellen Realität synchron zu halten und Umbenennungs-PRs als eigenständige Arbeitsstücke zu schreiben.

Ich baue ein System, in dem die Docs des Agenten auch die Docs des Teams sind. Wenn die Docs lügen, lügt der Agent in dieselbe Richtung. Das ist ein Feature des Workflows, das ich richtig hinbekommen will, kein Bug.

Die Wi-Fi-7-Testsuite, im Speziellen

Das ist die, auf die ich von diesem Wochenende am stolzesten bin.

Die AR2-Gen1-Spec setzt Wi-Fi-7-Konnektivität für ausgelagertes Rendering und angebundenes Computing voraus. Wi-Fi 7 ist in der Praxis nicht so stabil wie Wi-Fi 6E, und die Fehlermodi sind anders. Die dieses Wochenende geschriebene Testsuite charakterisiert die Bandbreite der Fehlermodi (degradierter Durchsatz, intermittierender Verlust, Reauth-Stürme) und grenzt das Verhalten der Runtime unter jedem einzelnen ein. Die Runtime kann nicht jeden Fehler tolerieren. Die Aufgabe der Testsuite ist, genau festzulegen, welche Fehler die Runtime elegant abfängt und welche laut scheitern.

Das ist wichtig, weil das AR-Erlebnis des Nutzers nicht stottern darf, wenn die Verbindung aussetzt. Die Runtime muss für einen Frame, oder zwei, oder zwanzig, je nach Dauer des Aussetzers, auf lokales Rendering zurückfallen und wieder konvergieren, wenn die Konnektivität zurückkehrt. Diese Logik existierte als vage Absicht in der Spec. Nach diesem Wochenende existiert sie als Testfälle.

Was ich Partnern mitgeben möchte

Zwei Dinge.

Wenn du ein Hardware-Partner bist und über AR-Brillen nachdenkst, wird das Validierungs-Framework, mit dem diese Engine ausliefert, einer der Gründe sein, warum sie schneller auf deiner Hardware ausliefert als die Konkurrenz. Das Framework ist portabel. Ein neues Geräteziel hinzuzufügen ist ein paar Hundert Zeilen Code plus die gerätespezifischen Testvektoren. Der teure Teil ist schon bezahlt.

Wenn du ein KI-Labor bist, das über latenzsensitive On-Device-Inferenz nachdenkt, ist das Latenzbudget, das die AR2-Gen1-Spec voraussetzt, veröffentlicht. Die End-zu-End-Spuren von Sensor bis Rendering werden gerade instrumentiert, damit du siehst, welches Budget für Inferenz tatsächlich übrig bleibt, wenn dein Modell in dieses Budget passen muss. Das ist das Gespräch, das ich im November mit dir führen möchte.

77 Commits übers Wochenende. Geendet bei Dokumentation, was die richtige Art ist, ein Wochenende zu beenden.