Ce que nous pouvons apprendre de l'expérience SQLite Rust de Cursor
MMaximilian Schwarzmüller
Computing/SoftwareInternet Technology
Transcript
00:00:00SQLite a été réécrit en Rust.
00:00:02Je sais qu'on vient juste d'avoir la réécriture de Bun en Rust
00:00:04et vous vous demandez peut-être pourquoi tout le monde réécrit
00:00:06tout en Rust, mais il ne s'agit pas de Rust.
00:00:09Il ne s'agit même pas de SQLite.
00:00:11Je sais qu'il existe la base de données Turso,
00:00:15qui est déjà une réimplémentation modernisée
00:00:18de SQLite en Rust.
00:00:19C'est celle-là qu'il faut utiliser
00:00:21si vous cherchez une base de données SQLite basée sur Rust
00:00:23prête pour la production.
00:00:26En réalité, cette expérience, mini-SQLite,
00:00:29dont le lien est ci-dessous et que vous pouvez consulter,
00:00:32ne concerne ni SQLite ni Rust.
00:00:34Il s'agit plutôt d'une expérience menée par l'équipe de Cursor,
00:00:37qui tourne autour des essaims d'agents et de la conception
00:00:40d'un système d'agents IA, pour découvrir ce qui fonctionne
00:00:44et ce qui ne fonctionne pas pour créer un outil
00:00:47comme SQLite uniquement à partir de sa documentation,
00:00:51parce que c'est le véritable sujet de cette expérience.
00:00:53Il y a un article de blog très détaillé et passionnant,
00:00:56et nous allons nous y plonger.
00:00:57Il contient plein d'enseignements intéressants
00:00:59dont nous devons parler, que vous trouverez aussi en lien ci-dessous,
00:01:02où ils expliquent comment ils ont mené l'expérience. Le point de départ
00:01:07et l'idée de cette expérience étaient de prendre la documentation de SQLite,
00:01:12qui fait au total 835 pages si vous la rassemblez en un seul document,
00:01:18et qui est bien sûr rédigée avant tout pour des humains.
00:01:23Ce n'est pas la documentation la plus accessible que j'aie jamais vue,
00:01:27mais elle est évidemment conçue pour des humains car elle est bien plus ancienne que tout le domaine des agents IA.
00:01:32Néanmoins, elle sert aussi de spécification hyper détaillée,
00:01:37une spécification très poussée puisqu'elle explique en détail comment utiliser SQLite
00:01:43ainsi que le comportement et les fonctionnalités prévus.
00:01:48L'équipe de Cursor a pris cette documentation,
00:01:52puis ils ont pris un ensemble de tests publics, le test SQLogic,
00:01:57qui est un ensemble de tests évaluant le comportement de SQLite
00:02:02ou testant spécifiquement des requêtes.
00:02:05Ils ont utilisé cela pour vérifier si l'implémentation
00:02:09que leurs agents ont conçue sur la base de cette documentation
00:02:13fonctionne réellement avec cette suite de tests officielle géante.
00:02:19Voici d'emblée quelques avertissements importants.
00:02:23Cette suite sert uniquement à tester les requêtes et leur comportement.
00:02:29Elle ne teste pas l'ensemble des fonctionnalités et des capacités de SQLite.
00:02:35Elle ne teste pas les performances de manière générale.
00:02:38Elle ne teste pas la concurrence.
00:02:40SQLite contient énormément de choses que ceci ne teste pas.
00:02:44Et ce projet mini-SQLite, qui est l'un des résultats de cette expérience...
00:02:49Ils ont en fait reconstruit SQLite plusieurs fois avec différentes combinaisons d'agents.
00:02:53Nous y reviendrons : c'est vraiment un projet fait pour explorer.
00:02:57Ce n'est pas prêt pour la production.
00:02:59Ce n'est pas ce que vous voulez utiliser.
00:03:01C'est juste le résultat d'une expérience dont le but était d'utiliser la documentation
00:03:06pour reconstruire SQLite et réussir à faire passer tous ces tests à cette version reconstruite.
00:03:13L'équipe de Cursor a utilisé différentes combinaisons de modèles ici.
00:03:17Pourquoi des combinaisons ?
00:03:18Parce que, comme nous allons le voir, ils ont utilisé une approche
00:03:21où plusieurs agents travaillaient ensemble : des agents planificateurs, exécutants et réviseurs.
00:03:28Ils ont reconstruit cette base de données SQLite avec différentes combinaisons et ont aussi mesuré l'obtention d'une qualité similaire.
00:03:37Toutes ces combinaisons ont atteint le même niveau de qualité et le même nombre de tests réussis, mais ils ont mesuré ce que chaque combinaison coûtait.
00:03:45Par exemple, l'utilisation de GPT-5.5 pour tout, des planificateurs aux exécutants, a mené à un coût d'implémentation de SQLite en Rust d'environ 10 000 $ d'après la documentation.
00:03:59D'un autre côté, associer Opus 4.8 à Composer 2.5 — Composer 2.5 étant ce modèle de Cursor ultra rapide, très économique et très efficace, mais pas extrêmement intelligent —, associer ces deux-là a donné la même qualité et le même nombre de tests réussis que les autres combinaisons, pour une fraction du coût : seulement 1 300 $.
00:04:24L'idée ici était d'utiliser Opus 4.8, le modèle le plus capable, pour la planification et la conception des tâches, qui sont ensuite déléguées aux agents exécutants utilisant Composer 2.5.
00:04:39C'est déjà un enseignement très important de cet article, qui n'est pas totalement inédit, bien sûr.
00:04:44Vous pouvez l'appliquer vous-même si vous développez des logiciels.
00:04:47C'est une bonne idée de diviser le travail, selon sa complexité bien sûr, en différentes tâches exécutées par différents agents (ou sous-agents), où certains se concentrent sur la planification,
00:05:03en définissant une sous-tâche ciblée du projet global, comme une mission individuelle, pour ensuite la faire implémenter par d'autres agents.
00:05:14Car il s'avère que pour simplement générer du bon code, on n'a pas nécessairement besoin d'une intelligence de pointe si le contexte est bon.
00:05:24C'est-à-dire si la tâche est clairement définie, si toutes les informations utiles sont dans la description, sans compter que d'autres facteurs entrent en jeu.
00:05:33Par exemple, la structure du code environnant ou la qualité des exemples fournis à l'agent ont leur importance.
00:05:39Tout cela influence le résultat, mais les agents exécutants qui ne font que coder peuvent être très nombreux si la tâche est bien spécifiée et le contexte solide.
00:05:49Et c'est tout le sujet de la majeure partie de l'expérience.
00:05:52Comment concevoir un système capable de s'attaquer à une tâche de cette ampleur.
00:05:57Parce que, comme je l'ai dit, pour vos propres projets aussi, il vaut la peine d'envisager une combinaison d'agents planificateurs et exécutants.
00:06:07Pas pour absolument toutes les tâches, évidemment.
00:06:10Pour un correctif rapide ou une tâche simple, il suffit amplement de donner directement vos instructions à votre agent, quel qu'il soit.
00:06:19« Hé, j'ai ce problème.
00:06:20Je veux que tu fasses ça. »
00:06:21Donnez-lui un peu de contexte et laissez-le faire son travail.
00:06:24Selon l'environnement d'exécution de l'agent, il peut lancer des sous-agents.
00:06:28Claude Code peut le faire, par exemple.
00:06:31D'autres environnements comme Pi ne le feront pas sans les bonnes extensions.
00:06:36Mais même sans sous-agents, un seul agent suffit très bien pour de nombreuses tâches.
00:06:43Cependant, pour des projets ou des tâches plus complexes, cette répartition est utile, y compris avec des agents réviseurs.
00:06:51C'est une démarche que j'aime aussi appliquer personnellement.
00:06:54Encore une fois, cela dépend de la complexité de la tâche.
00:06:56Mais cette séparation des rôles fonctionne vraiment très bien.
00:06:59Et ce n'est pas une nouveauté révolutionnaire en soi.
00:07:02Ce qui est nouveau, c'est que pour un projet comme cette réécriture de SQLite, plusieurs processus parallèles d'agents planificateurs, exécutants et réviseurs tournent en même temps : plusieurs exécutants, mais aussi plusieurs planificateurs et réviseurs.
00:07:18Et ils entrent constamment en conflit.
00:07:19C'est la découverte finale de l'équipe de Cursor.
00:07:22Dans cet article de blog vraiment passionnant,
00:07:26ils mentionnent plus tôt cette année une expérience avec un système d'agents où ils ont créé un navigateur web de toutes pièces.
00:07:33Et ils ont réutilisé ce même système d'agents pour réaliser cette réécriture de SQLite.
00:07:40Ils ont aussi conçu un nouveau système basé sur leurs récents enseignements, à titre expérimental.
00:07:47Dans cette expérience et cet article, ils comparent ces différentes approches et analysent tous les défis rencontrés lors de la mise en place et de l'exécution de ce système de reconstruction de SQLite.
00:07:59L'un des premiers défis survenus avec des centaines ou des milliers d'exécutants travaillant en simultané est que le contrôle de version traditionnel comme Git ne suffit plus.
00:08:13Comme ils l'expliquent dans un billet précédent sur l'essaim : « Les outils comme Git ou Cargo reposent sur des verrous à grain grossier pour la concurrence, verrouillant une donnée pour empêcher des écritures simultanées.
00:08:30Cela convient à un développeur, mais c'est un frein pour le volume de travail produit par des centaines d'agents en parallèle.
00:08:36L'essaim pour le navigateur a atteint un pic d'environ 1 000 commits par heure. »
00:08:41Voilà pour l'essaim qui a reconstruit ce navigateur.
00:08:45Le nouveau système conçu pour cette expérience atteint des pics d'environ 1 000 commits par seconde.
00:08:52L'ancien essaim de cette année faisait 1 000 commits par heure, ce qui dépasse déjà la capacité de la plupart des humains.
00:09:02Mais le nouveau système en génère environ 1 000 par seconde, un rythme hallucinant pour lequel Git n'a clairement pas été conçu.
00:09:14Évidemment.
00:09:15« Pour soutenir ce rythme, nous avons développé un nouveau système de contrôle de version à partir de zéro.
00:09:21Le débit n'était pas la seule raison de maîtriser cette couche.
00:09:25Chaque modification du système passe par le contrôle de version.
00:09:29C'est donc là que les collisions apparaissent en premier.
00:09:31Plusieurs mécanismes de coordination décrits plus loin y sont d'ailleurs directement intégrés. »
00:09:37Et c'est vraiment très intéressant.
00:09:39Ils ont créé un gestionnaire de versions adapté à l'ère des agents IA.
00:09:43Car l'ancien, Git, que nous utilisons tous, fonctionne très bien, qu'on soit clair.
00:09:48Pour préciser la pensée...
00:09:49Nous parlons d'une expérience à une échelle et sur une tâche que peu d'entre nous aborderont, du moins pas dans un avenir proche.
00:09:57Mais Git n'est pas taillé pour faire travailler en parallèle des centaines d'agents sur le même code.
00:10:07Ils ont donc conçu un outil capable de gérer une concurrence massive tout en aidant les agents à résoudre les conflits.
00:10:19Puisque c'est précisément dans le gestionnaire de versions que les conflits sautent aux yeux quand deux modifications touchent le même bout de code.
00:10:28C'est donc le premier point clé.
00:10:30Ils ont créé ce nouveau système de contrôle de version pour pouvoir mener à bien cette expérience efficacement.
00:10:37Naturellement, à cette échelle et avec 1 000 commits par seconde, ils ont rencontré de nombreux problèmes.
00:10:48L'analyse des soucis et des solutions trouvées est captivante, car elle donne un aperçu de ce à quoi pourrait ressembler le développement logiciel de demain.
00:11:01Le problème de conception « split-brain ».
00:11:03Deux planificateurs, ignorant leurs actions respectives, implémentent le même concept de deux manières différentes dans le projet.
00:11:10Il s'agit donc d'une duplication du même concept de deux façons distinctes à deux endroits du code.
00:11:16En temps normal, on voudrait factoriser et réutiliser cette logique, n'est-ce pas ?
00:11:21« Nous avons réglé cela par le prompting. »
00:11:24Pas de système complexe ici, juste une adaptation des consignes (prompting).
00:11:28Les agents planificateurs prennent eux-mêmes les décisions d'architecture au lieu de les déléguer.
00:11:34« Et nous leur imposons de vérifier qu'aucune sous-branche déléguée ne traite la même question. »
00:11:39C'est une question d'organisation.
00:11:40Tout l'enjeu, en répartissant le système entre planificateurs et exécutants, est de veiller à ce que les différents planificateurs en parallèle aient des missions bien définies sans chevauchement.
00:12:02Cela commence donc dès la conception par des humains.
00:12:08Dans la manière de structurer la tâche et de guider l'IA, n'est-ce pas ?
00:12:11« Nous avons réglé cela par le prompting. »
00:12:13Cela se répercute ensuite dans l'arbre d'agents, pour s'assurer que lorsque les planificateurs découpent les tâches en sous-tâches, leurs consignes leur demandent de créer des blocs sans risque de doublon.
00:12:34C'est un défi de planification humaine, consistant à bien configurer le système au départ.
00:12:43Voilà comment ils ont surmonté ce problème.
00:12:47Un autre problème rencontré était la rivalité entre planificateurs.
00:12:51« Une rivalité plus complexe survient quand deux planificateurs sont conscients l'un de l'autre et se battent en modifiant tour à tour les mêmes fichiers.
00:12:59Le souci, c'est que les outils de fusion ne peuvent pas trancher un désaccord d'architecture.
00:13:04À la place, nous faisons enregistrer les décisions dans des documents de conception partagés.
00:13:08Le code lié à une décision intègre une référence de contrôle compilée vers son document.
00:13:13Quand des planificateurs se contredisent sans le savoir, un réconciliateur fusionne les docs et propage la décision en amont. »
00:13:21En résumé, même en divisant le travail, il est impossible en développement logiciel d'éviter totalement les chevauchements ou les zones de code communes touchées par plusieurs planificateurs puis par des exécutants.
00:13:43C'est ainsi que des planificateurs sont entrés en conflit sur l'implémentation. Ils ont résolu cela en introduisant un agent réconciliateur qui fusionne les spécifications rédigées par ces planificateurs.
00:13:59Celles destinées à être transmises aux exécutants.
00:14:02Cette étape de réconciliation fusionne les spécifications des planificateurs en conflit pour qu'ils parlent le même langage et s'accordent sur une solution, ce qui évite aussi de réimplémenter la même chose de différentes façons.
00:14:21Ces deux éléments fonctionnent de pair, si j'ai bien compris.
00:14:24Évidemment, ils ont aussi fait face à des conflits de fusion.
00:14:29Planifier et s'assurer qu'il n'y a pas de chevauchement pour que les planificateurs soient sur la même longueur d'onde est la première étape.
00:14:38Mais des exécutants travaillant sur un même plan risquent fort de modifier les mêmes fichiers et d'entrer en contradiction.
00:14:50Les agents ne font pas naturellement attention à ne pas toucher aux mêmes fichiers.
00:14:55C'est pour cela qu'ils finissent par intervenir au même endroit.
00:14:57Et les risques de collision sont élevés.
00:14:58« Pour résoudre un conflit, ils devaient s'arrêter, assimiler le contexte de l'autre agent et adapter la fusion. »
00:15:03Si deux agents (ou deux humains) travaillent sur le même fichier, il faut faire une pause pour analyser la situation et trancher,
00:15:19afin de trouver une implémentation qui résout le problème.
00:15:23« Les agents exécutants gèrent mal cela : soit ils écrasent le travail de l'autre, soit ils abandonnent le leur. »
00:15:29Vous l'avez peut-être déjà remarqué vous aussi.
00:15:31C'est clairement mon cas.
00:15:32Si vous modifiez du code alors que vous travaillez avec un ou plusieurs agents IA...
00:15:38Oui, ça fait peur, mais on peut encore coder !
00:15:40Admettons que vous fassiez un changement.
00:15:42Vous modifiez une ligne dans le code.
00:15:44L'agent va souvent simplement l'annuler et l'écraser.
00:15:48Il ne respecte pas vos modifications.
00:15:50Il suit son propre plan.
00:15:52S'il a décidé qu'il devait éditer ce fichier, il va le faire.
00:15:57Il se fiche que vous y ayez apporté des retouches entre-temps.
00:16:01C'est un peu différent si vous avez commité vos changements, car ces modèles sont entraînés pour éviter d'annuler brutalement des commits.
00:16:13Mais sur des modifications non commitées, l'agent n'en a rien à faire.
00:16:17L'exécutant ignore tout simplement vos ajouts.
00:16:19Et c'est exactement ce qu'ils ont constaté ici.
00:16:21« Pour corriger cela, nous avons créé un système où un agent neutre intervient lors des conflits pour les résoudre au nom des deux parties.
00:16:29Son seul but est d'être imparcial et efficace, à la manière des files d'attente de fusion dans les équipes d'ingénierie. »
00:16:35C'est une approche très intéressante.
00:16:38C'est encore une forme de réconciliation.
00:16:41Il s'agit de stopper ces agents pour prendre du recul et régler le problème,
00:16:49comme on le faisait traditionnellement.
00:16:51Ce que cela montre bien, c'est l'importance capitale d'un contexte propre et bien ciblé.
00:17:03Que vous gériez un projet massif comme Cursor ou une application plus modeste,
00:17:12l'intérêt de séparer planificateurs, exécutants et réviseurs est de travailler avec des fenêtres de contexte vierges.
00:17:24Cela ne veut pas dire vides de toute information,
00:17:26mais que chaque session contient exactement le contexte nécessaire à sa tâche.
00:17:33Un exécutant évalue très mal son propre code car son historique est pollué par toute la phase d'implémentation.
00:17:41Il manque de neutralité, si l'on peut dire.
00:17:44Un agent réviseur doit démarrer sur une session neuve, recevoir le plan, voir ce qui a été fait et quels fichiers ont été touchés, sans plus.
00:17:55Afin de relire le travail de manière objective.
00:17:59D'où l'intérêt de fenêtres de contexte fraîches et bien alimentées.
00:18:04C'est la même logique appliquée ici : régler les conflits de fusion via un agent neutre disposant du bon contexte sans parti pris.
00:18:17J'imagine que le système informait ensuite les exécutants du résultat de la fusion pour qu'ils ne l'écrase pas, à moins que de nouveaux exécutants aient été relancés.
00:18:30Ce n'est pas précisé en détail ici.
00:18:32Autre problème rencontré : les fichiers géants.
00:18:35« Certains fichiers attirent particulièrement les modifications des agents.
00:18:39Chaque agent n'ajoute qu'un bout de code et aucun ne cherche à limiter la taille du fichier.
00:18:45Ces fichiers géants deviennent un goulot d'étranglement.
00:18:49Lourds à transférer, comparer ou fusionner, ils provoquent des collisions en chaîne. »
00:18:54C'est un phénomène que vous avez peut-être déjà croisé à moindre échelle.
00:19:00Pour ma part, oui.
00:19:01Notamment dans l'écriture de tests.
00:19:02Surtout pour les tests.
00:19:03D'après mon expérience, les agents adorent ajouter encore et encore des tests dans le même fichier.
00:19:08Et ce n'est pas seulement les tests, mais c'est un domaine où je le vois très souvent.
00:19:13Surtout si vous avez plusieurs agents en action et que chacun a ses propres objectifs.
00:19:18Ils s'en fichent, parce que ce ne sont pas des humains.
00:19:21Comment pourraient-ils se soucier de quoi que ce soit ?
00:19:23Ils se contentent d'exécuter des tâches, n'est-ce pas ?
00:19:24Ils ne se soucient pas de la taille d'un fichier ni de l'architecture globale d'un système.
00:19:30Si vous avez juste une série d'agents qui exécutent leurs tâches, votre base de code finira par sombrer dans le chaos.
00:19:37Parce que les agents s'en fichent.
00:19:39Ce qui les intéresse, c'est d'exécuter leur tâche.
00:19:42Et ces méga fichiers sont bien sûr un indicateur très clair de ce problème.
00:19:48Ils apparaissent à mesure que plus d'agents travaillent sur une plus longue période dans votre projet.
00:19:55Il n'y a aucun agent chargé de diviser ce fichier ou de maintenir une base de code bien architecturée.
00:20:02Ce n'est simplement pas leur priorité.
00:20:04Pour corriger cela, nous avons donné aux agents exécutants un moyen d'analyser et signaler les fichiers surchargés.
00:20:09Une fois signalés, nous bloquons les nouveaux commits et un agent externe décompose le fichier devenu trop volumineux en plus petits modules.
00:20:16On fait donc à nouveau intervenir un agent tout neuf.
00:20:19C'est un schéma récurrent ici.
00:20:21Pour tous ces problèmes, il s'agissait d'identifier un blocage, puis d'utiliser de nouveaux agents avec la bonne tâche,
00:20:28avec le bon contexte, pour résoudre ce problème afin que les autres agents puissent ensuite poursuivre leur travail.
00:20:35Et c'est la même chose ici pour les méga fichiers.
00:20:38L'ossification est un autre problème rencontré.
00:20:40En travaillant dans des bases de code existantes avec des humains dans la boucle, les agents ont appris
00:20:44à ne pas toucher au code central, même lorsqu'il doit être modifié.
00:20:48Ce n'est donc pas ce que je voulais dire plus tôt.
00:20:50Quand vous modifiez un fichier sur lequel l'agent travaille et qu'il le rejette simplement.
00:20:55C'est plutôt une question générale.
00:20:57Un agent a une tâche claire basée sur un plan, sur un prompt que vous lui avez donné.
00:21:03Et cela implique, bien sûr, de modifier certains fichiers.
00:21:07Or, une chose qu'on remarque en travaillant quotidiennement avec les agents, c'est que selon le modèle,
00:21:16certains modèles hésitent énormément à abandonner du code existant.
00:21:21Ils préfèrent ajouter 10 mécanismes de secours, 10 vérifications “if” et de plus en plus de vieux code plutôt que de tout supprimer et nettoyer.
00:21:31Il faut explicitement leur demander par prompt pour qu'un agent supprime réellement une fonction ou un fichier.
00:21:39Ils ne le font pas vraiment d'eux-mêmes en raison du fine-tuning, car les fournisseurs de modèles ne veulent évidemment pas créer d'agents
00:21:47qui agissent en roue libre et cassent du code en production.
00:21:50Mais si l'on ne travaille pas sur un projet existant ou déjà déployé en production,
00:21:57cette tendance à ne pas vraiment toucher au code et à tout conserver indéfiniment peut être très problématique et agaçante.
00:22:05Cela peut aussi entraîner d'autres effets secondaires comme ceux constatés ici, où les agents n'amélioraient pas le code écrit par d'autres,
00:22:16mais se contentaient d'ajouter des couches successives, ce qui finit évidemment par alourdir la base de code.
00:22:23Pour corriger cela, nous autorisons les ruptures de code intentionnelles.
00:22:27Un agent qui juge une modification essentielle opportune peut appliquer un patch ciblé en dehors de son périmètre et laisser un commentaire explicatif.
00:22:36Et cela, à une échelle plus réduite, c'est exactement ce que vous pouvez faire dans vos projets et ce que je fais moi-même.
00:22:41Vous devez explicitement autoriser vos agents et leur dire : “Hé, on développe ça.”
00:22:46“On est au tout début du développement.”
00:22:48“Ce n'est pas encore en ligne.”
00:22:49“Je veux des modifications majeures.”
00:22:51“Nettoyez donc le code de manière radicale.”
00:22:54“Les refactorisations sont les bienvenues.”
00:22:56Des choses de ce genre.
00:22:58Il faut encourager les agents et ces modèles d'IA, et passer outre leurs consignes de fine-tuning.
00:23:04Autrement dit, passer outre leurs réflexes intégrés pour s'assurer qu'ils puissent faire évoluer une base de code plutôt que d'y empiler du code.
00:23:14C'est donc encore quelque chose qu'on observe à petite échelle, mais qui s'applique évidemment à grande échelle.
00:23:19Pour la revue de code, ils ont utilisé une approche appelée les filtres de relecture.
00:23:24On a les agents planificateurs et exécutants, mais ce travail doit être revu pour créer des tâches de suivi et relancer la boucle jusqu'à la résolution du bug ou l'amélioration de la base de code.
00:23:38Dans un système multi-agents tournant en continu, les erreurs s'accumulent et l'essaim doit pouvoir se corriger avant que de petites erreurs ne deviennent structurelles.
00:23:47Encore une fois, c'est tout à fait logique.
00:23:48On a tous constaté cela à plus petite échelle.
00:23:50Nous avons testé de nombreux filtres, comme donner au relecteur l'historique complet de l'exécutant, seulement son résultat, ou uniquement la base de code.
00:24:00Nous avons aussi essayé des relecteurs basés sur différents modèles, avec des entraînements et des personnalités distincts.
00:24:05Aucun filtre ne repère tout, mais leur combinaison permet d'atteindre une fiabilité supérieure à celle des humains, à l'image des systèmes de conduite autonome.
00:24:16La puissance de calcul investie dans la revue est très rentable, car relire coûte bien moins cher que produire le travail audité.
00:24:21Nous pensons que ce système de relecture en couches a grandement contribué à maintenir la qualité des exécutions.
00:24:28Voici donc le point essentiel à retenir.
00:24:30Il est impossible d'avoir un ou plusieurs agents relecteurs qui examinent l'intégralité de la base de code.
00:24:39C'est beaucoup trop lourd.
00:24:41Au lieu de cela, ils ont expérimenté différentes approches comme fournir l'historique complet, le résultat seul, ou la base de code brute.
00:24:47Au final, ce qui les a aidés, c'est d'avoir plusieurs relecteurs avec des personas et des axes d'analyse différents, se focalisant sur des aspects distincts.
00:25:00On leur donne la base de code, si j'ai bien compris, et peut-être quelques informations sur ce qu'a fait l'agent exécutant.
00:25:06Et c'est ensuite la combinaison de ces relectures qui a produit un bilan global, lequel a pu être repris par un planificateur pour élaborer un plan et faire corriger le code par les exécutants.
00:25:23Et à plus petite échelle, je pense que c'est une méthode que nous pouvons aussi appliquer.
00:25:28Évidemment, nous ne construisons pas des systèmes aussi complexes au quotidien.
00:25:34Mais d'expérience, avoir plusieurs agents relecteurs avec des tâches dédiées fonctionne très bien : l'un peut vérifier si le code est du Rust idiomatique,
00:25:46un autre se concentrera sur les performances et la sécurité,
00:25:51un troisième analysera les conventions de nommage, si c'est ce que vous souhaitez cibler, et ainsi de suite.
00:25:58Vous avez ainsi différents prismes d'analyse, puis vous donnez à ces relecteurs juste le contexte nécessaire.
00:26:03Par exemple : “Des exécutants ont travaillé sur cette fonctionnalité.”
00:26:07Vous leur fournissez le plan de l'exécutant et quelques détails sur ses étapes principales, sans plus.
00:26:15Vous obtenez ainsi les retours de ces relecteurs et vous pouvez les synthétiser, éventuellement via un autre relecteur.
00:26:22Ce que j'aime aussi, c'est utiliser un relecteur pour évaluer les remarques faites, car selon le modèle, ils ont tendance à vouloir trouver des erreurs à tout prix.
00:26:36Quel que soit le code qu'on leur donne, même une seule ligne.
00:26:40J'ai parfois l'impression qu'ils iraient y trouver cinq problèmes.
00:26:43Demander à un relecteur de catégoriser ces remarques et d'écarter celles qui n'en sont pas vraiment fonctionne très bien selon mon expérience.
00:26:55C'est cette combinaison et cet empilement de relecteurs qui aident à produire de bons résultats, exploitables ensuite pour implémenter les corrections.
00:27:06Après, cela dépend toujours de l'ampleur de votre tâche et du logiciel à concevoir.
00:27:11Pour beaucoup de projets, c'est bien trop complexe, mais cela offre un aperçu captivant du futur de l'ingénierie logicielle et de ce type de systèmes, ce que je trouve passionnant.
00:27:27Dernière chose : ils ont aussi laissé les agents façonner leur environnement.
00:27:32L'idée était de les laisser rédiger un guide pratique, un ensemble de documents, sans autre instruction que de servir de contexte pour la tâche globale. Les agents pouvaient y construire une mémoire partagée rassemblant leurs apprentissages et les problèmes clés identifiés.
00:28:00Ils disposaient ainsi de ce système de mémoire additionnel pour prendre des notes et documenter leurs décisions.
00:28:10Dans l'ensemble, tout comme la réécriture de BUN en Rust, je trouve cette expérience vraiment très intéressante.
00:28:16Cela peut aussi faire peur.
00:28:17Je le conçois tout à fait.
00:28:18Et je pense qu'il ne faut pas en déduire que tous les logiciels devraient être conçus ainsi à l'avenir.
00:28:24D'une part, ce logiciel n'est même pas prêt pour la production.
00:28:28Et le rendre exploitable en production prendrait un temps considérable.
00:28:33Il ne faut pas sous-estimer cet aspect.
00:28:35Ce n'est pas comme si on pouvait bâtir cela en quelques heures et qu'il ne restait plus qu'un petit effort pour le passer en production.
00:28:43Les premiers 80 % sont souvent bien plus rapides à atteindre que les derniers 20 %.
00:28:48Nous le savons tous.
00:28:49C'est donc un point essentiel à retenir.
00:28:51Il faut aussi comprendre que pour cette tâche spécifique de réécriture de SQLite, les agents disposaient de la documentation et de cette suite de tests.
00:29:04Cependant, il s'agit d'une spécification incroyablement détaillée, ce dont on ne dispose pas sur de nouveaux projets.
00:29:13Quand on crée un nouveau logiciel, on n'a pas une spécification aussi poussée que la documentation d'un outil vieux de plus de 20 ans.
00:29:24Et bien sûr, même si seule la documentation leur a été fournie, le code source de SQLite et d'autres réimplémentations (comme celle en Rust par Turso) faisaient très probablement partie des données d'entraînement des modèles utilisés.
00:29:46Ce n'était donc pas un sujet totalement inédit pour ces modèles.
00:29:51Cela n'a rien à voir avec le développement de zéro d'un tout nouveau logiciel, où l'itération joue un rôle majeur.
00:29:58Il serait très difficile, voire impossible, de créer un nouveau logiciel en partant de zéro sans qu'il n'évolue constamment en cours de route.
00:30:11Car on ne peut pas rédiger une spécification parfaite dès le départ et s'en tenir là.
00:30:17On découvre toujours de nouveaux éléments ou des fonctionnalités à modifier pendant la phase de création, peu importe l'échelle.
00:30:26Par conséquent, cela ne représente pas la manière dont les logiciels seront ou devront être développés en général.
00:30:34Cela reste néanmoins une expérience très intéressante.
00:30:37C'est une expérience passionnante qui apporte des enseignements précieux pour nous tous.
00:30:43Des leçons qui ne sont pas nouvelles, comme découper le travail et repartir sur des fenêtres de contexte propres avec les bonnes informations.
00:30:50On voit aussi émerger l'idée que de nouveaux systèmes de gestion de versions pourraient devenir nécessaires.
00:30:57Et bien sûr, que l'orchestration multi-agents s'impose peu à peu.
00:31:01Tout cela prouve aussi que les humains restent indispensables pour concevoir ces systèmes d'agents, ainsi que pour définir l'architecture des nouveaux logiciels.
00:31:21Rédiger des spécifications, définir l'architecture globale, puis bâtir des systèmes d'agents capables de l'implémenter et de la relire : voilà l'essentiel.
00:31:33C'est vers cela que nous nous dirigeons. Même si cela change nos habitudes d'il y a six ans, je trouve cette évolution passionnante.
00:31:45C'est très stimultant de passer à cette réflexion systémique, aussi bien pour concevoir les agents que pour architecturer le logiciel lui-même.
00:31:59Et de faire ensuite fonctionner ces deux aspects ensemble.
00:32:01Je trouve ce genre d'expérimentation vraiment captivant.
00:32:04Les leçons qu'on en tire sont extrêmement instructives.
00:32:07Et certains de ces enseignements, appliqués à plus petite échelle, peuvent tout à fait servir au développement logiciel du quotidien.
00:32:17Comme toujours, dites-moi ce que vous en pensez et quel est votre avis sur ce type d'expériences.