Deux mois en public, des années sous le capot

La plupart des moteurs « natifs IA » boulonnent un panneau de chat dans un éditeur. RakuAI traite le modèle comme une entrée de contrôle à chaque frame - et deux mois plus tard, cette thèse livre du code, pas des diapositives.

Le plan pour ce samedi était de ralentir et de réfléchir. Trois commits pour tout le week-end, ce qui est le compte le plus bas depuis que j’ai commencé le journal public. Les agents tournent au ralenti exprès ; mon attention est sur l’architecture plutôt que sur la livraison de nouveau code. La base de code termine le week-end à peu près où elle l’a commencé, ce qui est le bon état pour le type de travail que je faisais.

Il y a deux mois aujourd’hui, le dépôt public du runtime était un README vide. Le moteur et le portefeuille de brevets derrière lui remontent plus loin que ça. Le genre de week-end qui vaut la peine d’être écrit est celui où l’auteur fait le point. Alors c’est ce que c’est.

Ce qu’est réellement le moteur, aujourd’hui

Si je devais décrire Raku en un paragraphe à quelqu’un qui n’a pas suivi, la description serait :

Un runtime AR multiplateforme, écrit en C++ et exposé à travers une API C stable, avec des liaisons SDK Unity et Unreal. Il cible principalement les lunettes AR et tourne sur le matériel disponible aujourd’hui (actuellement en cours de mise en ligne pour le passthrough Meta Quest, avec des builds de prévisualisation desktop et mobile). Il est conçu depuis les fondations autour de l’hypothèse que l’IA est une préoccupation de runtime, pas une fonctionnalité d’éditeur. L’ancrage sous-millimétrique est supporté. OpenXR est la cible de conformité là où les standards existent. La base de code est construite avec des agents de codage autonomes dans l’équipe de développement, travaillant à travers une file d’issues publique.

Ce paragraphe aurait été un énoncé de mission aspirationnel le jour un. C’est maintenant une description de ce qu’il y a dans le dépôt.

Ce qui m’a surpris des deux derniers mois

Trois choses.

Le flux de travail piloté par agents a passé à l’échelle au-delà de ce que j’attendais. J’avais une inquiétude au départ que les agents autonomes produiraient une base de code qui fonctionnait dans des PR isolées et se transformerait en bouillie à travers de nombreuses fusions. La bouillie ne s’est pas produite. La base de code est plus cohérente à deux mois que des bases de code que j’ai héritées d’équipes humaines à deux ans. La raison est la discipline sur laquelle j’ai écrit chaque week-end (file plus petite, revue plus précoce, appairage multi-fournisseurs pour l’indépendance de revue, documentation comme entrée). Ces disciplines fonctionnent.

Le pivot matériel a été moins coûteux que je le craignais. Passer d’AR1+ comme cible produit à AR2 Gen1 début octobre était une décision avec laquelle je me suis assis pendant plusieurs jours parce que le coût paraissait grand. Le coût réel a été une poignée de PR (un balayage de renommage minutieux, un passage de documentation). La raison pour laquelle le coût a été petit est l’architecture modulaire établie tôt. Les sous-systèmes qui n’avaient pas besoin de connaître la frontière de classe d’appareil n’ont pas eu à changer. Ceux qui en avaient besoin ont changé proprement à travers leurs surfaces bien définies. C’est le dividende de dessiner l’architecture tôt.

Les conversations de partenariat arrivent plus tôt que je ne le prévoyais. Je m’attendais à être en mode « construire le moteur, livrer une démo, puis avoir des conversations de partenariat » jusqu’à la fin de l’année. La séquence réelle a été « construire le moteur, avoir des conversations de partenariat en chemin qui informent ce qu’il faut construire ensuite, puis livrer des démos qui correspondent à ce dont ces conversations ont besoin ». NTT QONOQ. Meta. Les prochaines je ne vais pas encore les nommer. Les conversations sont plus nettes que les démos en ce moment, ce qui est un bon endroit où être.

Où l’architecture s’est stabilisée

Une courte liste des décisions architecturales que je ne m’attends plus à revoir :

• Le runtime est du C++ exposé à travers une API C stable. Les autres liaisons de langage reposent sur l’API C, pas directement sur le C++.
• Le SDK est multi-liaison dès le premier jour. Unity et Unreal sont de premier ordre. Godot est sur la feuille de route. Le web natif est sur la feuille de route. L’API C est le goulot d’étranglement. Les liaisons ne le sont pas.
• Les sous-systèmes sont des DLL. Chacun a une surface publique ; rien à l’intérieur d’un sous-système n’accède aux internes d’un autre sous-système. Les surfaces sont des PR revues.
• L’IA est une préoccupation de runtime, pas une fonctionnalité d’éditeur. Le travail IA qui vit dans le moteur tourne sur l’étape de simulation à chaque frame. Le travail LLM cloud qui vit dans le moteur s’intègre au pipeline vocal au runtime. Aucun des deux n’est un panneau dans un outil de création.
• OpenXR est le standard là où le standard convient. Le code spécifique au fournisseur se trouve derrière des drapeaux de fonctionnalité et des schémas de fournisseur. Adopter une nouvelle cible d’appareil conforme OpenXR est une couche de colle spécifique au fournisseur, pas une réécriture du runtime.
• Le processus de développement est multi-fournisseurs par conception. Le modèle qui écrit un morceau de code ne peut pas être le modèle qui le revoit. Le laboratoire dont le modèle est actuellement le meilleur pour un rôle donné obtient ce rôle jusqu’à ce qu’un autre laboratoire soit meilleur.

Ce que je m’attends encore à revoir :

• La division exacte du travail entre l’inférence sur l’appareil et l’intention LLM cloud. Cela deviendra plus net à mesure que le travail TFLite mûrit et que l’interface LLM cloud est exercée par de vrais partenaires. La ligne actuelle est provisoire.
• La forme du format de fichier de définition d’expérience. Les os sont là. Le schéma évoluera. Je m’attends à au moins un saut de version majeure avant que le format ne soit stable.
• Le placement de la synchronisation d’état pour l’AR multijoueur. Nous avons un canal delta à faible latence aujourd’hui. Si la bonne réponse à long terme est un maillage pair-à-pair, un serveur autoritaire hébergé, ou un hybride n’est pas encore réglé. Les démos à deux joueurs qui sortiront en décembre informeront la décision.

La route vers la préparation à la production de décembre

Je vise discrètement un jalon de décembre où le moteur est « prêt pour la production, pour que des partenaires construisent des démos sérieuses par-dessus ». Ce n’est pas un lancement public. C’est la barre interne à laquelle je suis prêt à inviter une équipe partenaire à commencer à construire contre le runtime sans les avertir d’une demi-douzaine d’aspérités.

Ce qui doit encore se produire pour franchir cette barre :

• Les sous-systèmes IA pour le runtime (arbres de comportement, maillage de navigation, simulation de foule, systèmes sensoriels, arbres de décision). Actuellement échafaudés dans des documents de conception ; l’implémentation atterrit en décembre et le premier week-end de janvier.
• La propreté du build Windows MSVC. Je n’ai pas réellement construit le runtime sous Visual Studio 2026 depuis octobre. Je suis à peu près sûr que ça va être un combat. J’écrirai à ce sujet quand je le ferai.
• Un package d’exemples canoniques qui démontre une expérience AR non triviale de bout en bout à travers les deux liaisons Unity et Unreal, avec le pipeline vocal et le LLM cloud branchés.
• Un chemin de synchronisation fédérée pour distribuer les mises à jour de modèle aux appareils sur le terrain. La partie crypto doit être de qualité production, pas de qualité stub.
• Le mécanisme de mise à jour du runtime. Nous devons pouvoir livrer un nouveau build au kit de développement d’un partenaire et le faire s’installer proprement.

C’est la liste. Six semaines pour la franchir. Le volume de commits de décembre va être élevé.

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

Si vous lisez le journal public depuis deux mois, vous avez vu le moteur se rassembler en temps réel. Le rythme est élevé ; la discipline est réelle ; les décisions architecturales sont documentées. C’est la culture d’ingénierie avec laquelle ce moteur est construit. C’est la culture d’ingénierie avec laquelle vous travaillerez si vous construisez par-dessus.

Si vous êtes un partenaire qui réfléchit à démarrer une conversation sérieuse : la conversation est plus nette que les démos en ce moment, et c’est exprès. Je préfère entendre ce dont votre produit a réellement besoin et laisser cela façonner ce qui est construit plutôt que construire une démo et essayer ensuite de l’adapter à vos besoins après coup. La fenêtre pour façonner ce que décembre livrera est ouverte jusqu’à la fin novembre.

Si vous êtes un développeur qui attend la stabilité : la stabilité est le livrable de décembre. Le moteur est aujourd’hui dans une évolution assez active pour que je ne recommande pas encore d’y construire du code dépendant sérieux. Dans deux mois à partir d’aujourd’hui, la recommandation sera différente.

Samedi tranquille. Deux mois passés. Retour à la construction le week-end prochain.