Le week-end où un agent autonome a livré dix sous-systèmes

Un moteur construit PAR des agents dès le premier jour ressort sous une forme différente de celui où l'IA est boulonnée après coup. Cette forme est exactement celle dont a besoin un runtime quand l'IA est une primitive - pas une fonctionnalité à côté.

Ouvert l’ordinateur portable samedi matin. Le dépôt runtime avait pris 139 commits pendant la nuit. La plupart d’entre eux avaient atterri par un agent de codage autonome qui avait travaillé contre une file d’issues que j’avais déposées le week-end dernier. Dix pull requests de taille sous-système, toutes prêtes pour la revue.

Quand les gens me demandent à quoi ressemble réellement la construction d’un runtime 3D avec des agents IA dans l’équipe, ils supposent généralement l’une de deux choses. Soit les agents sont de l’autocomplétion habillée d’un panneau de chat, soit ce sont une fonctionnalité qu’on ajoute plus tard, une fois que le « vrai » moteur a été construit par des humains.

Aucune des deux n’est la version dans laquelle je me trouve ce week-end.

Sur samedi et dimanche, le dépôt runtime a pris 139 commits. 110 d’entre eux ont été écrits par un agent autonome. 20 étaient sous le compte de l’ère fondatrice BladeWireless. 10 étaient les miens. À travers ces 139 commits, dix pull requests de sous-système ont atterri :

• Système d’animation squelettique
• API d’édition de scène en runtime
• Sérialisation de scène
• Occlusion culling
• Streaming de niveau
• Système de préfabriqués
• Systèmes de particules GPU
• Rendu avancé
• Systèmes de terrain et d’environnement
• Pipeline de post-traitement

Aucun de ces sous-systèmes n’est de l’IA. Ce sont les pièces ennuyeuses et porteuses dont un runtime 3D a besoin pour être un runtime 3D. Et ils ont été livrés sur un seul week-end, dans des branches parallèles, majoritairement écrits par un agent tournant de façon autonome pendant que je cadrais, revoyais, et fusionnais.

Voici le billet sur ce que signifie le fait que la fondation soit construite PAR des agents, pas construite POUR des agents.

La différence est dans chaque décision architecturale

Il y a une version de cette histoire où vous construisez un moteur « normal » de la façon dont les moteurs ont toujours été construits, puis vous ajoutez l’IA par-dessus. L’IA atterrit comme une fonctionnalité. Elle se boulonne dessus. Elle vit en dehors du moteur parce que le moteur n’a pas été conçu pour l’héberger. C’est le schéma dominant dans l’industrie en ce moment, et ce n’est pas un mauvais schéma. C’est juste celui que vous obtenez quand vous décidez à quoi devrait ressembler le moteur avant que l’IA ne soit dans l’équipe de développement.

Quand des agents IA sont dans l’équipe dès le premier jour, la forme du moteur ressort différente. Trois choses changent.

Un. Chaque sous-système se déploie à travers une revue de code. Parce que les agents doivent participer à la boucle de revue, la boucle doit accepter des diffs écrits par des agents. Chaque PR. Chaque diff. Chaque fusion. Cette discipline ne fait pas que permettre les agents. Elle s’avère aussi être exactement la discipline que vous voulez si l’IA doit un jour être une primitive de runtime plutôt qu’une fonctionnalité d’éditeur. Le même pipeline de revue qui attrape la faute de frappe d’un agent dans un en-tête de culling attrapera la faute de frappe de l’agent dans un arbre de comportement. Le pipeline ne se soucie pas de quelle couche de la stack elle habite.

Deux. Chaque sous-système a des interfaces publiques propres. Plusieurs agents travaillant sur plusieurs sous-systèmes en parallèle produisent des conflits infusionnables chaque fois que les frontières sont floues. Le remède est de dessiner les frontières strictement avant que quiconque n’écrive du code. Une fois les frontières strictes, les sous-systèmes deviennent adressables de partout, ce qui est exactement ce dont vous avez besoin si vous voulez que le moteur héberge des comportements IA qui peuvent appeler dans le reste du runtime sans couplage.

Trois. Chaque sous-système est testable indépendamment. Un samedi à 139 commits ne peut pas être vérifié à la main. Les tests doivent être livrés avec le diff sinon le diff n’atterrit pas. C’est ainsi que l’humain dans la boucle fait confiance au diff du tout. L’effet secondaire est une surface de test qui vous permet d’échanger des implémentations sans réécrire les appelants, ce qui est la discipline dont un moteur a besoin pour évoluer du tout.

Rien de tout cela n’est des fonctionnalités IA. Ce sont des conséquences du processus de développement d’avoir des agents dans l’équipe. Le processus de développement façonne l’architecture.

À quoi ressemble réellement le flux de travail

Le schéma qui a produit ce week-end :

• J’ai cadré quels sous-systèmes le moteur avait besoin ensuite.
• Un agent autonome a tourné en parallèle sur dix branches, chacune implémentant un sous-système.
• Chaque branche a produit une PR avec implémentation, tests, et documentation.
• J’ai revu et fusionné. Là où l’agent a fait une erreur, j’ai fermé la PR ou demandé des changements.

Ce qui me frappe, assis ici à la fin du week-end, c’est à quel point une grande partie de cela fonctionne déjà. La boucle de développement est la boucle de développement. L’agent fait le travail pour lequel j’aurais embauché dix personnes il y a cinq ans. Je fais le jugement architectural et les décisions de fusion. C’est un genre différent de long week-end que les longs week-ends que j’avais l’habitude d’avoir.

L’agent autonome de ce week-end particulier n’est pas une pile multi-fournisseurs de quatre assistants. C’est un seul agent (l’agent SWE de Copilot) tournant à travers de nombreuses tâches parallèles. Je m’attends à ce que le schéma multi-assistants arrive, et arrive vite. Le schéma est déjà là sous forme d’agent unique.

Ce qui est difficile

Honnête à ce sujet, parce que c’est authentiquement difficile.

Les agents ne sont pas gratuits. Un week-end à 139 commits a un coût de revue à 139 commits. Chaque PR a besoin d’une attention réelle parce que les sous-systèmes ne sont pas familiers et je ne peux pas les survoler. Je suis fatigué. La fatigue est réelle et vaut la peine d’être budgétée.

Faire confiance à un agent autonome sur du travail inédit est une compétence. L’agent SWE de Copilot qui a livré la plupart des sous-systèmes de ce week-end est bon. Il n’est pas infaillible. La compétence est de savoir quand fusionner vite, quand ralentir, et quand jeter un brouillon. J’ai déjà fusionné des choses que j’aurais dû relancer. J’apprends en payant le coût.

L’architecture doit être esquissée avant que les agents ne tournent. Donnez à un agent le prompt « construis-moi un moteur de rendu » et vous obtiendrez un moteur de rendu qui ne s’adapte pas au reste de votre moteur. Donnez-lui « implémente un sous-système d’occlusion culling qui exporte cette API C et s’intègre au graphe de scène à travers ces handles » et vous obtenez quelque chose qui atterrit proprement. Le travail de cadrage est le travail. L’agent fait la frappe.

Les tests sont non négociables. J’ai failli laisser une des PR de ce week-end atterrir avec une couverture de test mince. C’est une future régression à laquelle je m’engage discrètement à lutter contre. Le remède est de faire de l’exigence de test une partie du prompt de l’agent dès la première ligne.

Ce que je retiens du week-end

Deux observations.

Les agents vont évidemment continuer à s’améliorer. Plus rapides, plus précis, capables de tenir plus du moteur dans une seule tête. C’est la prédiction facile.

La prédiction moins facile est ce qui arrive au rôle humain à l’intérieur de ce flux de travail. Ce n’est déjà plus le rôle pour lequel je me suis entraîné en tant qu’ingénieur senior. Moins de frappe, plus de cadrage. Moins de synthèse, plus de sélection. Moins « je suis le goulot d’étranglement sur cette ligne de code » et plus « je suis le goulot d’étranglement sur la décision architecturale qui détermine si cette branche valait la peine d’être lancée du tout ».

C’est un métier différent. Il utilise des muscles différents. Je pense que les muscles qu’il utilise sont anormalement transférables entre domaines, et je pense que les gens qui les développent au cours des deux prochaines années regarderont le reste de l’industrie de la façon dont l’industrie regarde actuellement les gens qui construisent encore sans contrôle de version.

C’est plus qu’assez de réflexion pour un week-end.

Fermeture de l’ordinateur portable dimanche soir. Retour à ça samedi prochain.