Valider le matériel avant que le silicium n'arrive

La réponse traditionnelle à l'attente du silicium est de s'asseoir et d'attendre. La réponse moderne est de construire d'abord tout ce qui est en aval du matériel et de tout avoir au vert avant que les pièces n'arrivent - pour que votre matériel se déploie sur RakuAI plus vite que ses concurrents.

Une décision que je ruminais pendant la semaine de travail attendait à la table de la cuisine quand le week-end a commencé. Faire pivoter la cible produit d’AR1+ vers AR2 Gen1. Construire tout ce qui est en aval de la nouvelle spec avant que le silicium n’arrive, pour que quand le silicium arrive effectivement, la validation commence le jour un au lieu du jour quatre-vingt-dix.

Il y a une étape que traverse chaque produit matériel où la spec existe, le plan de validation existe, le harnais de test existe, et le silicium réel n’existe pas. La réponse traditionnelle est de s’asseoir et d’attendre. La réponse moderne est de construire d’abord tout ce qui est en aval du matériel, et d’avoir tout au vert avant que les pièces ne sortent.

Ce week-end était celui-là. La plateforme cible est officiellement passée d’AR1+ à AR2 Gen1, et la réponse d’ingénierie a été de construire immédiatement l’infrastructure de validation dont la nouvelle plateforme aura besoin, avant qu’aucun de nous ne touche à la nouvelle plateforme.

Ce qui a atterri

Cinq choses, toutes atterries ce week-end :

• L’infrastructure de mise en service et d’intégration des capteurs de l’appareil AR2 Gen1
• Une suite de tests de connectivité Wi-Fi 7 et de stabilité de suivi
• Un cadre de validation thermique et énergétique
• Des tests de fumée CI avec analyse et rapport de métriques
• La documentation de validation matérielle AR2 Gen1 et la spec des standards de production

Tout cela contrôlé par des drapeaux de fonctionnalité pour que le chemin de code AR1+ fonctionne toujours et que rien dans le runtime existant ne régresse. Les agents qui ont fait atterrir ces PR ont fait correctement la discipline ennuyeuse : chaque nouveau fichier est caché derrière un drapeau de build, chaque ajout d’API est non cassant, chaque test tourne en CI même s’il n’y a pas d’appareil AR2 contre lequel tourner. Les tests simulent. La simulation est assez bonne pour attraper la dérive d’interface, les exports manquants, et les flux de capteurs cassés.

Ce fut un week-end de 77 commits. La plupart de ces commits sont au service d’un appareil que je ne peux pas tenir en main.

Pourquoi c’est sensé

Quelques raisons.

La validation matérielle qui sort avec le matériel est une validation matérielle qui arrive six mois en retard. Le cadre thermique et énergétique écrit ce week-end sera utilisé le jour où le premier kit de développement AR2 atteindra mon bureau, pas trois mois après. La première régression thermique de la plateforme sera attrapée par un test existant, pas par un humain remarquant que l’appareil est chaud.

Un harnais de test sans appareil reste un harnais de test. Il tourne contre des traces de capteurs simulées. Ces traces viennent de l’ère AR1+ et de la spec. Elles ne sont pas parfaites. Elles attrapent les bugs d’interface, les bugs d’intégration, et les bugs de collecte de métriques. Elles n’attrapent pas les bugs qui ne se manifesteront que sous le vrai silicium. C’est bien ainsi. Les bugs qu’elles attrapent sont les bugs que nous aurions passé la première semaine de temps sur du vrai matériel à traquer, et nous n’avons désormais plus à le faire.

L’acte d’écrire le harnais clarifie la spec. La moitié du document des standards de production qui a atterri d’ici dimanche soir n’existait que comme une intention floue au début du week-end. Écrire les tests de validation a forcé la spec vers des chiffres précis. Budgets de frame. Enveloppes thermiques. Seuils de stabilité Wi-Fi 7. Le harnais a rendu la doc nette. C’est le véritable livrable.

Comment l’agent a géré le pivot

Le pivot d’AR1+ vers AR2 Gen1 n’a pas été géré proprement la première fois. Au milieu du week-end, l’agent a fait atterrir une PR qui référençait « AR1+ » à des endroits où le nouveau chemin de code aurait dû dire « AR2 ». Cela a atterri parce que le cadrage de l’issue ne signalait pas le renommage. La correction a été une PR séparée intitulée « Fix AR1+ vs AR2 device discrepancy in documentation and copilot instructions » qui a balayé 121 références séparées et les a mises en ligne.

C’est le genre de chose qui ne se produit pas quand un seul humain écrit tout le code, parce que l’humain seul renomme au fur et à mesure. Cela se produit dans un flux de travail piloté par agents quand l’agent reprend une issue antérieure à un renommage et écrit fidèlement l’ancien nom. Le remède est de garder la documentation que l’agent lit en entrée entièrement synchronisée avec la réalité actuelle, et d’écrire les PR de renommage comme leurs propres morceaux de travail.

Je construis un système où la documentation de l’agent est aussi la documentation de l’équipe. Quand la documentation ment, l’agent ment dans la même direction. C’est une caractéristique du flux de travail que j’essaie de bien faire, pas un bug.

La suite de tests Wi-Fi 7, spécifiquement

C’est celle dont je suis le plus fier de ce week-end.

La spec AR2 Gen1 suppose une connectivité Wi-Fi 7 pour le rendu déporté et le calcul en tethering. Le Wi-Fi 7 en pratique n’est pas aussi stable que le Wi-Fi 6E, et les modes de défaillance sont différents. La suite de tests écrite ce week-end caractérise l’ensemble des modes de défaillance (débit dégradé, perte intermittente, tempêtes de réauthentification) et borne le comportement du runtime sous chacun. Le runtime ne peut pas tolérer chaque défaillance. Le travail de la suite de tests est d’être précis sur quelles défaillances le runtime dégrade avec grâce et lesquelles échouent bruyamment.

Cela compte parce que l’expérience AR que vit l’utilisateur ne peut pas saccader quand la connexion a un raté. Le runtime doit se replier sur le rendu local pendant une frame, ou deux, ou vingt, selon la durée du raté, et reconverger quand la connectivité revient. Cette logique existait sous forme d’intention floue dans la spec. Après ce week-end, elle existe sous forme de cas de test.

Ce que je veux que les partenaires retiennent de ceci

Deux choses.

Si vous êtes un partenaire matériel qui réfléchit aux lunettes AR, le cadre de validation avec lequel ce moteur est livré va être l’une des raisons pour lesquelles il se déploie sur votre matériel plus vite que ses concurrents. Le cadre est portable. Ajouter une nouvelle cible d’appareil est quelques centaines de lignes de code plus les vecteurs de test spécifiques à l’appareil. La partie coûteuse est déjà payée.

Si vous êtes un laboratoire IA qui réfléchit à l’inférence sur l’appareil sensible à la latence, le budget de latence que suppose la spec AR2 Gen1 est publié. Les traces de bout en bout du capteur au rendu sont instrumentées maintenant, donc quand votre modèle doit tenir dans ce budget, vous pouvez voir quel budget reste réellement pour l’inférence. C’est la conversation que je veux avoir avec vous en novembre.

77 commits sur le week-end. Terminé sur de la documentation, ce qui est le bon genre de week-end pour terminer.