Démarrer la cadence hebdomadaire

Le contenu génératif dans un navigateur, c'est bien. Le contenu génératif ancré au mur de votre vraie cuisine, c'est le produit. Voici le moteur construit pour recevoir des directives de votre modèle à chaque étape de simulation - jour zéro, en public.

Ce samedi démarre la cadence hebdomadaire régulière sur ce blog. Les quatre entrées ci-dessous sont les samedis de document de conception du début de l’été : effectif d’agents, suite de démos, structure de dossiers, la dernière réflexion avant que le code ne commence. La cadence à partir d’ici est hebdomadaire. Le sujet du blog n’est pas nouveau.

Je réfléchis aux lunettes AR, aux expériences spatiales ancrées dans le monde réel, et à la bonne forme du runtime qui les pilote depuis plus d’une décennie. Une partie de cette réflexion est devenue des brevets au début des années 2010, le portefeuille sur le format lunettes qui ancre encore la PI derrière ce que nous construisons maintenant. Une partie est devenue des prototypes qui n’ont jamais vu le jour. La plupart tournait en arrière-plan pendant que je faisais autre chose.

Ce qui a changé cette dernière année, c’est que le reste du monde a enfin rattrapé son retard. Le calcul est assez petit. L’optique est assez bonne. Les LLM cloud sont assez réels. L’inférence sur l’appareil est assez rapide. Le produit qui était une idée en avance d’une décennie est, enfin, un produit qu’on peut livrer.

Alors j’ai commencé à livrer. La série de code actuelle en est à plusieurs mois. Les commits vivent dans des dépôts privés que je rends maintenant publics au fur et à mesure que je les nettoie et consolide la base de code. Ce blog est le registre public à partir d’ici.

À quoi ressembleront les prochains mois

La forme du plan de ce samedi, comme un avant-goût de ce qui vient :

• Le runtime : une ébauche de spec de lunettes intelligentes AR1+ est sur le bureau ce matin. Versions PDF, PowerPoint et Markdown pour qu’un LLM puisse raisonner dessus, qu’un partenaire puisse la lire, et qu’un designer puisse la revoir. Le point important est la spec, pas le format. Le format est pour les lecteurs.
• Un main.cpp et un squelette de boucle principale du runtime, fraîchement intégrés.
• Un en-tête de traqueur de latence et un stub d’implémentation. La latence va être la métrique qui définit ce moteur.
• Un flux de build CMake en CI pour que chaque push obtienne un build propre depuis une machine propre.
• Un guide d’intégration Copilot pour que les agents de l’équipe sachent comment l’équipe fonctionne.

Le dépôt SDK a eu son propre échafaudage ce samedi aussi. Un premier exemple HelloAR Unity. Un premier exemple HelloAR Unreal. Des squelettes d’en-têtes pour les deux liaisons. Un flux de publication de packages.

Rien de tout cela n’est livrable. Tout cela est ce dont on a besoin avant que quoi que ce soit de livrable ne soit possible. Le schéma consistant à faire avancer les deux dépôts en même temps, avec un couplage délibéré aux coutures, va être un thème récurrent.

Pourquoi une spec de lunettes intelligentes le jour un de l’ouverture au public

La spec est une chose délibérée. La plupart des moteurs choisissent une architecture de runtime puis vont faire du shopping pour des produits qui pourraient plausiblement être livrés dessus. Je fais cela dans l’autre ordre. Le produit, ce sont des lunettes AR que les gens portent dans le monde, et le moteur doit avoir la bonne forme pour ce produit. Donc la spec est écrite en premier, même quand elle est brute.

Ce n’est pas un document marketing. C’est une fonction de contrainte. Elle dit sur quel type de matériel le moteur doit tourner, quel est le budget de latence, à quoi doit ressembler la surface IA en pratique. Chaque décision architecturale en aval peut pointer vers cette spec et demander « cette décision sert-elle la spec, ou sert-elle un autre moteur que j’aimerais construire à la place ». Cette deuxième catégorie est là où les projets de moteur vont mourir, et je m’en suis tenu éloigné auparavant et j’ai l’intention de m’en tenir éloigné maintenant.

Pourquoi un guide Copilot le jour un

L’autre chose délibérée de ce week-end est le guide d’intégration Copilot. La première version est brute. Elle sera réécrite dix fois. Mais le guide existe parce que les agents font partie de l’équipe, et l’équipe a besoin de savoir comment l’équipe fonctionne.

Le guide dit :

• Quelle est la stratégie et quel moteur nous ne construisons pas
• Où vit la feuille de route
• Comment les issues sont déposées, reprises et fermées
• À quoi ressemble une bonne PR
• Ce qu’un réviseur est censé faire (où le réviseur est parfois moi et parfois un autre agent)

Le cadrage « les agents lisent la documentation » n’est pas un gadget. C’est la réalité pratique de faire tourner un flux de travail où l’équipe est un humain les week-ends et plusieurs assistants de codage autonomes en service continu. Si le guide est mauvais, le travail est mauvais. Si le guide est bon, le travail est correct et le coût de revue baisse.

Pourquoi le journal public maintenant

Quelques raisons.

Les brevets sont une antériorité vieille d’une décennie dont personne ne parle parce que nous n’en avons pas parlé. Le travail sur le format lunettes auquel le moteur remonte a été discrètement accordé et poursuivi pendant des années. Je veux que le registre public d’ingénierie pointe vers la véritable lignée. L’AR spatiale n’est pas une chose nouvelle que quelqu’un a ramassée l’été dernier. Le travail remonte loin.

Les conversations de partenariat commencent. Partenaires matériels, laboratoires IA, studios. Ces conversations deviennent plus nettes quand il y a un registre public d’ingénierie qu’ils peuvent lire au lieu d’un deck. Le deck est la version nettoyée. Le blog est la version réelle.

Le flux de travail de développement est authentiquement nouveau et mérite d’être montré. Des agents IA dans l’équipe dès le premier jour de la phase publique. Plusieurs fournisseurs. Des branches parallèles. Une file d’issues publique. Rien de tout cela n’est inventé pour ce projet ; ce qui est inhabituel, c’est de tout faire en même temps sur quelque chose d’aussi sérieux. Je veux le consigner au fur et à mesure que ça arrive, pendant que les leçons sont encore assez fraîches pour être honnêtes.

Ce que je veux que les partenaires et les bâtisseurs retiennent de ceci

Si vous êtes dans l’un des grands laboratoires IA et que vous lisez ceci, voici le pitch. Le moteur est construit explicitement pour recevoir des directives de votre modèle. Pas boulonné en plus. Pas dans un panneau d’éditeur. Dans le runtime, sur l’étape de simulation, à chaque frame. Les décisions architecturales se prennent en ce moment même, en public, avec une trace documentaire explicite. Si votre modèle devient meilleur pour comprendre un véritable espace physique dans lequel se trouve l’utilisateur, ce moteur est l’endroit où il peut faire quelque chose de cette compréhension.

Si vous êtes un développeur qui envisage de construire là-dessus éventuellement, le SDK avance au pas avec le runtime. Des exemples Unity et Unreal sont semés dans le dépôt SDK dès ce week-end. Ils ne fonctionnent pas encore. Ils fonctionneront. La raison pour laquelle les deux liaisons existent à ce stade est pour que je n’arrive jamais à un moment dans six mois où l’architecture du runtime est verrouillée et où le SDK doit se déformer pour s’adapter.

Si vous guettez le signal précoce en tant que consommateur, le signal est celui-ci : le moteur est construit autour de l’hypothèse que les expériences les plus intéressantes sont des expériences AR dans des lieux réels, et l’IA est ce qui fait réagir ces expériences. Le contenu génératif dans un navigateur, c’est bien. Le contenu génératif collé sur un mur de votre cuisine, c’est le produit réel.

Aujourd’hui, c’est samedi. Le blog est en ligne. Retour à la construction demain.