Série : Apprendre à coder avec l’IA

Le goulot d'étranglement n'a jamais été la frappe au clavier

Cinq agents parallèles, un week-end : le goulot d'étranglement est de décider, pas de taper.

Le goulot d'étranglement n'a jamais été la frappe Un humain, cinq agents parallèles, 112 commits Vous cadrage & sélection Portages WASMbranche 1 iOS Metalbranche 2 Packs de contenubranche 3 Combat de cartesbranche 4 Perf webbranche 5
Moins de frappe. Plus de tri. Le rôle senior passe de la production à la sélection.

L'IA n'a pas seulement rendu la frappe plus rapide — elle a entièrement déplacé le goulot d'étranglement. Les équipes qui apprennent à faire tourner des agents en parallèle deviendront méconnaissables pour celles qui attendent encore un diff à la fois.

La première version de ma boucle de développement avec l’IA était simple. Demander à l’assistant de faire la chose A. Attendre. Relire le diff. Passer à la chose B. L’assistant était un partenaire de programmation en binôme plus rapide. Toujours un binôme. Toujours une chose à la fois.

Ce modèle a duré environ trois mois. Ce n’est pas comme ça que je travaille maintenant.

Ce que je fais maintenant, c’est faire tourner plusieurs assistants de codage IA en parallèle sur la même base de code, chacun dans son propre worktree git, chacun sur sa propre branche, chacun travaillant sur un problème différent en même temps. À tout moment, il y a cinq à dix branches actives à travers les dépôts. Différents agents qui poussent sur différentes parties du moteur simultanément. Je relis et je fusionne au lieu d’écrire et d’attendre.

Le changement dans mon métier est le sujet de ce billet.

À quoi ressemble un vrai week-end

Un week-end à la mi-mars. À travers les cinq dépôts, 112 commits ont atterri entre le petit-déjeuner du samedi et le dîner du dimanche. 66 avaient une IA comme auteur officiel. 47 m’avaient moi. Le reste était des fusions et des nettoyages pilotés par relecture.

Le travail n’était pas un seul projet. C’en était cinq. Portages WASM pour neuf genres. Intégration du moteur de rendu Metal iOS. Un exécuteur de pack de contenu avec vingt et un assets à travers un pipeline en sept étapes. Étapes cinq à sept du genre combat de cartes. Optimisations de performance pour le build web. Tout cela s’est produit sur les deux mêmes jours dans des branches parallèles qui atterrissaient tout au long de chaque après-midi et soirée.

Aucun humain seul ne tape 112 commits en un week-end à un bureau de cuisine. Aucun humain seul ne peut tenir cinq flux de travail parallèles dans une seule tête et écrire le code pour chacun d’eux. Le modèle que j’avais il y a trois mois n’aurait pas pu produire ce week-end.

Le modèle que j’ai maintenant le fait.

Le goulot d’étranglement se déplace

Quand le travail est séquentiel, le goulot d’étranglement est la frappe. La prochaine ligne de code n’existe pas tant que quelqu’un ne l’écrit pas. L’IA a rendu cette ligne plus rapide. Elle n’a pas changé quelle étape était lente.

Quand le travail est parallèle, le goulot d’étranglement est la sélection. Quatre agents reviennent avec quatre diffs. Deux sont bons. Un va dans la bonne direction mais a besoin de travail. Un n’aurait pas dû être écrit. L’étape lente est de décider lequel est lequel et de fusionner les deux qui survivent.

C’est un métier complètement différent de celui pour lequel je me suis formé. Moins de frappe. Plus de tri. Moins de synthèse. Plus de sélection.

La forme du week-end :

  • Samedi matin : cadrage. Quels quatre problèmes valent quatre tentatives parallèles. Quel est le critère de succès pour chacun. Quelle est la forme approximative d’une réponse acceptable.
  • Tout au long des deux jours : vérification ponctuelle. Les agents sont-ils sur la bonne voie ? L’un d’eux a-t-il produit avec assurance quelque chose de faux dans les trente premières minutes ? Quelqu’un est-il bloqué ?
  • Fin d’après-midi, les deux jours : relecture et fusion. Les diffs arrivent. Lire chacun en gardant le critère de succès à l’esprit. Fusionner ceux qui touchent juste. Relancer ou fermer ceux qui ne le font pas. Capturer ce que les tentatives échouées m’ont appris sur le problème.
  • Fin du dimanche : noter ce que le week-end a livré et quels sont les quatre prochains problèmes.

C’est plus comme être tech lead d’une équipe de quatre que d’être IC senior avec un copilote. Cela utilise des muscles différents. Ceux qu’il utilise sont étonnamment fongibles à travers les domaines.

Où cela se combine avec les fichiers .raku

Les fichiers d’expérience que notre moteur exécute sont des fichiers .raku : JSON, versionnés par schéma, validables, relisibles comme du code. Le format a été conçu en pensant à ce flux de travail d’agents parallèles.

Quand un agent édite un fichier .raku, le diff apparaît de la même façon qu’un diff de code. Un second agent peut relire le travail du premier agent. Je peux faire tourner un troisième agent pour vérifier ponctuellement les deux. La décision de fusion est la mienne. Le tout s’inscrit dans la même discipline de pull request que j’utilise pour le runtime.

Si .raku avait été un asset binaire, rien de tout cela ne fonctionnerait. Le choix du format et le choix du flux de travail sont en aval du même choix architectural : les expériences sont du code, le travail de développement est de la relecture de code, les agents participent à la boucle parce que la boucle accepte du code.

Le format de fichier est porteur. C’est ce qui permet à l’équipe de monter en charge grâce aux agents plutôt qu’aux effectifs.

Ce qui fonctionne en pratique

Trois schémas dans lesquels je me suis installé.

Un : jumeler des agents sur un problème. Quand quelque chose est non trivial, deux assistants avec des entraînements différents ont tendance à être en désaccord de manière productive. Je les fais tourner sur des branches séparées avec le même prompt, puis je diffe leurs réponses. Les désaccords sont là où va la vraie attention de relecture.

Deux : dédier un agent à la relecture. Je garde l’un des quatre assistants dans un rôle de relecture uniquement chaque jour donné. Il n’écrit jamais le premier jet. Il ne fait que critiquer les diffs que les autres produisent. Le coût de faire tourner un relecteur dédié est faible. Le taux de capture de bugs est significatif.

Trois : garder le contexte de l’agent étroit. Un seul agent sur une seule branche sur un seul problème est rapide. Un seul agent sur un problème tentaculaire avec cinq heures de contexte dérive et produit un travail de moindre qualité. Le correctif est de découper les problèmes en morceaux plus petits et de faire tourner le contexte fréquemment.

Ce qui casse

Honnête sur ce qui ne fonctionne pas.

La surcharge de coordination est réelle. Deux agents sur le même fichier en même temps produisent des conflits de fusion que je dois résoudre. Le coût est faible par conflit mais s’accumule. Atténuation : garder les agents sur des fichiers différents quand possible, et accepter que l’étape de convergence fasse partie du flux de travail.

La fatigue de relecture est réelle. Relire quatre diffs à la fin de chaque jour est plus difficile que relire quatre diffs séquentiels sur quatre jours. Les décisions sont plus denses. Je coupe la journée de travail plus tôt les jours d’agents parallèles que je ne le faisais quand le travail était séquentiel.

La tentation de tout garder est réelle. Quand deux agents produisent tous deux quelque chose de raisonnable, le geste paresseux est de fusionner les deux. Le geste discipliné est d’en choisir un. Fusionner les deux pollue la base de code avec deux façons de faire la même chose, ce qui coûte plus cher que de simplement relancer le perdant.

La dérive de contexte à travers de longues sessions parallèles est réelle. Une branche ouverte depuis une journée accumule des suppositions que l’agent a faites sur la base de code au moment où elle a démarré. Le soir venu, ces suppositions peuvent être périmées. Le correctif est des branches à courte durée de vie, sans pitié.

Tout ne se parallélise pas. Les refactors transversaux avec des invariants subtils veulent une seule passe minutieuse, pas quatre tentatives parallèles. La compétence est de savoir quels problèmes se divisent proprement et lesquels ne le font pas. Certains jours sont encore des jours séquentiels.

Ce que cela signifie pour les leaders d’ingénierie

Si votre équipe fait tourner le modèle séquentiel avec de l’IA boulonnée dessus, la prochaine étape n’est pas « utiliser un meilleur modèle ». C’est « utiliser plusieurs agents à la fois ». Le plafond de capacité est plus haut. Le plafond de compétence est aussi plus haut, et il déplace le rôle senior de la production vers le cadrage, la validation, et la sélection. C’est la même direction de déplacement que je vois dans chaque autre discipline qui utilise bien l’IA en ce moment.

Les équipes qui trouveront les flux de travail d’agents parallèles au cours des deux prochaines années deviendront méconnaissables pour les équipes encore sur le modèle séquentiel. C’est la forme du travail qui change. Pas l’outillage.

112 commits sur deux jours. Fermer l’ordinateur portable le dimanche avec la plupart au vert.

Construisez à la vitesse d'une équipe d'agents

RakuAI est le runtime spatial natif à l'IA conçu pour le flux de travail d'agents parallèles — les expériences comme du code, la relecture comme la boucle. Voyez ce que votre équipe peut livrer quand taper cesse d'être le goulot d'étranglement.

← Tous les articles