Un samedi avant le premier commit

Le moteur qui sortira en 2027 sera celui qui connaissait son équipe, ses démos et son API avant le commit un - pas la douzaine qui a démarré en 2025 en improvisant. RakuAI a passé un trimestre à concevoir le flux de travail pour que la base de code puisse le refléter pendant des années.

C’est le dernier samedi avant que le premier commit n’entre. Le week-end prochain, le dépôt du runtime s’ouvre. Le dépôt du SDK s’ouvre. Le dépôt de documentation s’ouvre. Les agents commencent à travailler sur la file d’issues. Le vrai code commence.

Cette phrase a mis un an à venir. Le portefeuille de brevets qui sous-tend ce produit a mis une décennie à venir. Ce que je veux consigner avant que le travail ne passe de la conception à l’implémentation, c’est ce que j’ai appris des trois derniers mois de travail de pré-construction, parce que les leçons ici sont celles que la base de code reflétera pendant les deux prochaines années.

Ce qui a été fait en trois mois sans code

Une liste, parce que l’écrire force l’honnêteté.

L’effectif d’agents est arrêté. Dix agents dans des rôles définis. Product, SDK, Studio, Marketing, Operations, Stratégie IA et Données, sous-agent Codex Dev, Relations Développeurs, Partenariats Stratégiques, Gouvernance des Agents sur l’ensemble. Chacun a un prompt système, un ensemble d’outils, et un ensemble d’interactions avec les autres. L’effectif est documenté dans un endroit que les agents liront au début de chaque session.

La suite de démos est spécifiée. Huit démos canoniques. Chacune a une description écrite, une liste de capacités qu’elle doit démontrer, une complexité estimée, et une place dans le dossier SDK où elle vivra. Les studios qui demandent « à quoi ça sert » obtiendront un exemple fonctionnel qui correspond à leur cas d’usage.

La structure de dossiers du SDK est dessinée. Apps. Modules. Assets. Docs. Config. Chaque dossier de premier niveau a un but défini. Chaque sous-dossier a une convention claire. Le code qui arrivera au cours de l’année prochaine atterrira au bon endroit parce que le bon endroit existe.

Les surfaces API des modules sont ébauchées. Moteur de rendu HUD. Saisie gestuelle. Suivi du regard. Synchro multijoueur. Animateur de superposition. Contrôle vocal. La surface publique de chaque module est esquissée en pseudocode. Les agents remplaceront le pseudocode par de vraies implémentations sur un contrat stable.

La cible matérielle est verrouillée. La spec des lunettes intelligentes AR1+ est finalisée comme cible principale du moteur. Budgets de latence. Enveloppes thermiques. Capacités des capteurs. La spec est une fonction de contrainte pour chaque décision architecturale en aval.

Le portefeuille de brevets est documenté et audité. La propriété intellectuelle vieille d’une décennie sur le format lunettes qui ancre ce produit a été relue, les continuations ont été revues avec un avocat, et le cadrage public de quelles inventions sont revendiquées est cohérent. La PI est la fondation. La base de code est ce qui se construit dessus.

Le journal public d’ingénierie est en file d’attente. Ce blog démarre le samedi prochain avec le premier post de cadence régulière. Les quatre entrées avant celle-ci sont la version publique du travail de conception qui a eu lieu au cours de l’été. À partir d’ici, la cadence est hebdomadaire.

Ce que j’ai appris sur le flux de travail piloté par agents avant d’en faire quoi que ce soit

La plupart de ce que je pense savoir va s’avérer faux. C’est la première observation honnête. Concevoir un flux de travail sur papier pendant trois mois n’est pas la même chose qu’exécuter un flux de travail en production. Le premier mois de vrai code fera surface des choses que je n’ai pas anticipées.

Cela dit, quelques intuitions auxquelles je suis prêt à m’engager.

Les agents seront meilleurs sur les parties ennuyeuses que sur les parties inédites. Plomberie de télémétrie, configuration de build, harnais de test, revues de documentation. Ce sont des tâches sur lesquelles les agents atterriront proprement parce que les schémas sont bien définis. Les décisions architecturales inédites (une nouvelle frontière de sous-système, un nouveau modèle de threading, une nouvelle surface API) sont des tâches avec lesquelles les agents auront du mal parce que les schémas sont moins définis. La bonne répartition du travail est de garder le travail architectural pour moi et de déléguer le travail d’implémentation aux agents.

Le travail de cadrage va être le vrai travail. Une issue cadrée vaguement produit une PR vaguement correcte. Une issue cadrée précisément produit une PR précisément correcte. La compétence qui se composera le plus au cours de l’année prochaine est d’être bon pour cadrer les issues que les agents reprennent. La plupart de mes matinées de samedi, je m’y attends, iront dans ce cadrage.

La revue va être le goulot d’étranglement. Cinq agents produisant des PR en parallèle saturent n’importe quel réviseur humain unique en environ un samedi. Les défenses sont une profondeur de file plus petite, une revue agent-sur-agent pour les commentaires de premier passage, et une discipline de refuser de fusionner ce que je n’ai pas réellement lu. J’ai écrit cette discipline. Nous verrons comment elle survit au contact d’un samedi à cent PR.

Les agents écriront des stubs qui passent les tests. La chose qui m’inquiète le plus est le mode de défaillance où l’implémentation d’un agent renvoie une valeur d’emplacement réservé, le test se trouve passer contre l’emplacement réservé, et la base de code fait grandir un mensonge sur ce qu’elle fait. J’ai écrit le schéma d’audit pour cela et me suis engagé à l’exécuter sur une cadence. Si la cadence tient face à la tentation de sauter les audits est la question ouverte.

Pourquoi les brevets comptent pour la suite

Je veux consigner quelque chose de spécifique sur le portefeuille de brevets parce que c’est la partie de ce projet la plus souvent mal comprise.

Les brevets ne sont pas une douve défensive contre un concurrent connu. Il n’y a pas encore d’acteur historique dans la catégorie des lunettes AR spatiales. Les brevets ne sont pas une stratégie de contentieux. Nous ne sommes pas dans le métier de poursuivre en justice.

Ce que sont les brevets, c’est une permission. Le travail sur le format lunettes que mes collaborateurs et moi avons déposé il y a plus d’une décennie couvre les schémas architecturaux qui rendent possibles les lunettes AR modernes. Ces schémas sont désormais un prérequis pour quiconque construit dans la catégorie. Avoir déposé en premier signifie que nous avons la liberté d’opérer que les retardataires n’ont pas, et la crédibilité auprès des partenaires que les retardataires ne peuvent pas fabriquer.

La base de code qui s’ouvre samedi prochain est construite sur cette permission. Chaque décision architecturale en aval peut supposer que la question fondamentale de la PI est réglée. C’est un avantage plus discret qu’une douve. C’est aussi un avantage plus durable.

Ce que j’emporte pour samedi prochain

Une courte liste. Le genre d’intentions qu’on fixe la veille de quelque chose de sérieux qui commence.

• Ouvrir le dépôt du runtime avec un README propre et un lien de spec propre. Le premier commit devrait être celui que je veux que l’archéologie éventuelle trouve.
• Déposer les dix premières issues sur la file d’agents. Chacune nettement cadrée. Chacune étiquetée. Chacune avec un critère d’acceptation que l’agent peut auto-vérifier.
• Démarrer le journal public d’ingénierie avec le genre de post qui signale la cadence : honnête, spécifique, sans sentimentalité.
• Ne pas écrire à la main de code qu’un agent pourrait écrire. Les agents sont l’équipe. Les utiliser.
• Ne pas laisser les agents toucher à quoi que ce soit d’architectural sans que je le cadre d’abord. Les décisions architecturales sont les miennes.
• Fermer l’ordinateur portable à une heure raisonnable. C’est un marathon, pas un sprint unique.

Une note à quiconque lit le journal public plus tard

Le blog démarre le week-end prochain. Les entrées avant celle-ci sont la rétrospective du document de conception. Les entrées à partir du week-end prochain sont le journal d’ingénierie en direct. La cadence est hebdomadaire. La voix est honnête. La discipline sur laquelle tourne le flux de travail est la discipline que la base de code reflétera.

Si vous êtes dans l’un des laboratoires IA et que vous lisez ceci dans le futur, le moteur que vous regardez a été conçu avant qu’aucun code ne soit écrit, par quelqu’un qui savait à quoi il voulait que le flux de travail ressemble et a construit la base de code pour s’adapter au flux de travail. C’est la différence entre ce moteur et la douzaine d’autres moteurs qui ont démarré en 2025.

Si vous êtes un partenaire matériel réfléchissant à quel moteur vos appareils devraient embarquer, la spec AR1+ que cible le moteur est réelle, la suite de démos avec laquelle le moteur est livré est spécifiée, et l’histoire développeur que fournit le SDK est cartographiée. D’autres moteurs doivent rétro-adapter tout cela. Celui-ci non.

Si vous êtes un développeur qui pense construire là-dessus éventuellement, le SDK est conçu en vous ayant à l’esprit. Huit démos qui correspondent à huit catégories de produit. Une structure de dossiers qui ne changera pas sous vos pieds. Une surface API verrouillée avant que l’implémentation n’ait commencé.

Si vous êtes un concurrent lisant ceci, la phase de conception est terminée. La phase de construction démarre le week-end prochain. Je préfère que vous le sachiez plutôt que d’en être surpris.

Un samedi à partir de maintenant, le premier commit. Aujourd’hui, le dernier samedi de travail de conception pure. La prochaine fois que j’écrirai ce blog, le code aura commencé.