Série : Apprendre à coder avec l’IA

282 commits, premier week-end sur le journal public

282 commits du premier week-end : boucle principale, traqueur de latence et API C.

282 commits, premier week-end La boucle : déposer, reprendre, ébaucher, revoir, fusionner - puis réapprovisionner Déposer des issuesnettement cadrées L'agent reprendouvre une PR brouillon Revuehumaine, les deux jours Fusion / redépôtaffiner si faux le réapprovisionnement de la file = le goulot d'étranglement Ce qui a atterri : boucle principale - traqueur de latence - API C - harnais de test - vérification ABI 282 commits la plupart écrits par un agent de codage autonome
Les agents n'ont pas d'emploi de jour - la production est ce qui tombe d'une file tournant en continu.

L'API C a été le commit qui comptait vraiment : le moment où le runtime a eu une surface publique stable, deux flux de travail écrit par des agents ont arrêté de se marcher dessus. Voici à quoi ressemble un runtime natif IA quand la boucle clique.

Samedi dernier j’ai déposé une pile d’issues et pointé un agent de codage autonome vers la file. Dimanche soir, assis à la table de la cuisine avec l’ordinateur portable ouvert une dernière fois avant lundi, 282 commits avaient atterri dans le dépôt runtime. J’étais l’auteur d’une petite fraction d’entre eux. Un agent de codage autonome était l’auteur de la plupart du reste.

La raison pour laquelle le compte ressemble à une semaine de sprint de travail est que le travail s’est déroulé en continu pendant que je n’étais pas au clavier. Je suis au clavier les week-ends. Les agents n’ont pas d’emploi de jour. La production est ce qui tombe de cet arrangement.

Comment fonctionne la file

Le samedi matin est le jour du dépôt. Je m’assois avec un café et j’écris des issues GitHub. Chacune est un morceau de travail nettement cadré dont le moteur a besoin ensuite. La forme est approximativement :

  • Un sous-système ou une fonctionnalité par issue
  • Un critère d’acceptation clair que l’agent peut auto-vérifier
  • Des pointeurs vers la documentation pertinente, la spec, et tout fichier existant que le travail devrait toucher
  • Une étiquette explicite « agent-queue »

Il y a aussi un flux de travail nocturne (issue #37 dans le dépôt runtime ce week-end) qui s’assure que la file ne descend jamais en dessous de quinze issues d’agent ouvertes. Si c’est le cas, le flux de travail ébauche des tâches d’emplacement réservé depuis la feuille de route. L’agent lit la file, reprend la suivante qu’il peut faire, ouvre une PR brouillon, itère, et finit par se marquer prêt pour revue.

Du samedi au dimanche je revois et fusionne. Là où l’agent a fait une erreur, je ferme la PR, j’affine l’issue, et je redépose. Là où l’agent a bien fait, la PR atterrit et l’issue se ferme. Le rythme est de déposer au début du week-end, de revoir pendant les deux jours, et de laisser une file fraîche derrière quand l’ordinateur portable se ferme dimanche soir. L’agent broie la file pendant que je suis de retour à mon emploi de jour.

C’est le flux de travail. Ce n’est pas subtil. La raison pour laquelle ça vaut la peine de le consigner, c’est que ça marche.

Ce qui a été construit

Les gros titres des 282 commits :

  • Une véritable boucle principale de runtime, pas juste un squelette
  • Un traqueur de latence qui mesure le timing de bout en bout depuis l’entrée capteur jusqu’au rendu
  • Un moniteur d’utilisation mémoire avec seuils configurables et rapports périodiques
  • Un sous-système de logging avec niveaux INFO / WARNING / ERROR, sorties console et fichier
  • Une gestion des erreurs avec gestionnaires de signaux pour un arrêt propre
  • Une API C exposant le runtime pour que le SDK puisse s’y lier
  • Un système de gestion de modules / agents dans l’API C pour l’intégration SDK
  • Le modèle de concurrence du runtime : files de tâches et threads de travail
  • Un harnais de test complet
  • Vérification ABI et validation de la liaison SDK
  • Spec de lunettes intelligentes AR1+ finalisée comme cible produit

Rien de tout cela n’est glamour. Tout cela est ce dont un runtime AR a besoin avant que les choses intéressantes ne puissent être construites par-dessus.

Le commit le plus important, avec le recul, est l’exposition de l’API C. Au moment où le runtime a eu une surface publique stable à laquelle le SDK pouvait se lier, le travail sur le runtime et le travail sur le SDK ont arrêté de se marcher dessus. Avant ce commit, chaque changement dans un dépôt devait être soigneusement synchronisé avec l’autre. Après, ils se sont découplés. Deux flux de travail écrit par des agents pouvaient tourner en parallèle sans produire de conflit de fusion.

Ce qui m’a surpris

Trois choses.

L’agent est plus rapide que je ne l’aurais été sur l’infrastructure ennuyeuse. Télémétrie, logging, gestion des erreurs, harnais de test. Ce sont les types de tâches où un humain se distrait parce que le travail n’est pas glamour. L’agent ne se distrait pas. Il fait simplement atterrir le diff.

L’agent est conservateur sur l’architecture. Donnez-lui une issue qui dit « implémenter un traqueur de latence qui mesure le temps capteur-vers-rendu », et il construit exactement cela. Il n’invente pas une métaphysique de ce que signifie la latence ni ne propose une forme différente pour l’API. C’est bien. L’architecture est mon travail. L’implémentation est le travail de l’agent.

Le réapprovisionnement de la file est le goulot d’étranglement. Quand l’agent livre quinze PR en une journée et que la file est vide le soir, le débit cesse de dépendre de la vitesse de travail de l’agent. Il commence à dépendre de la vitesse à laquelle je peux articuler le prochain ensemble de tâches. Cela a remodelé les matinées de samedi. La première heure est consacrée au dépôt d’issues.

Ce qui a cassé

Deux choses, aucune fatale.

Le build CMake a cassé deux fois quand l’agent a fait atterrir du code qui compilait isolément mais ne se liait pas au reste du runtime. Les deux fois, la solution était la même : l’agent n’a pas encore une pleine visibilité sur le graphe de liaison du projet. La solution est dans le cadrage des issues. Désormais, chaque issue qui touche une bibliothèque dit explicitement quelles autres bibliothèques s’y lient.

Le harnais de test a été ajouté tard dans la série et a immédiatement fait surface quatre bugs dans des PR antérieures qui avaient passé les tests de fumée manuels mais échouaient au nouveau harnais. La leçon là-dedans est celle qui n’est pas sexy : écrire les tests comme partie de la fonctionnalité, pas comme un suivi. L’agent fait cela quand l’issue le dit. Il ne le fait pas quand l’issue ne le dit pas. Le faire toujours dire.

Ce que je veux que les partenaires et bâtisseurs sachent

La forme de ce moteur est en train d’être construite en ce moment. D’ici la fin du mois prochain, la plupart des décisions fondamentales seront fixées. Si vous êtes dans un laboratoire de modèles et que vous avez des opinions sur comment la couche IA devrait se brancher, c’est la fenêtre où les opinions sont bon marché à incorporer. Si vous êtes un développeur qui pense à l’intégration Unity ou Unreal, le SDK est en train d’être façonné ce week-end et les liaisons reflètent ce que le runtime peut faire. Je préfère avoir de vos nouvelles en semaine six qu’en semaine soixante.

Le dépôt runtime est ouvert. Le dépôt SDK est ouvert. La file d’issues ouvertes est ouverte. Observer cela se produire en temps réel est tout l’intérêt.

282 commits, premier week-end sur le journal public. Dimanche en banque. Lundi ensuite.

Façonnez le runtime pendant que les opinions sont bon marché

Les décisions fondamentales se prennent en ce moment même, en public - si vous construisez des modèles ou des lunettes, c'est la fenêtre pour vous brancher.

← Tous les articles