Gemini Conductor : Le nouvel outil de Google pour améliorer le codage IA

L'auteur introduit le sujet en mentionnant que Google a publié un nouveau workflow d'ingénierie de contexte appelé Gemini Conductor, mais annonce d'emblée qu'il n'est pas meilleur que les autres workflows existants et présente de nombreux problèmes. Avant d'expliquer les défauts de Conductor, il fait une pause sponsorisée pour présenter Automata, leur service qui aide à donner vie aux idées en créant des applications et sites web. Le service s'adresse à ceux qui ont des idées mais pas d'équipe technique, en appliquant les workflows d'IA enseignés à des millions de personnes directement aux projets des clients. Cette introduction établit le contexte critique de la revue à venir tout en présentant l'expertise de l'auteur dans le domaine des workflows d'IA.

L'auteur commence l'explication technique de Conductor en présentant l'article officiel avec un lien dans la description. Conductor s'installe comme une extension dans Gemini CLI, similaire aux plugins de Claude, qui sont des ensembles de commandes, MCP et règles regroupés en package partageable. Après l'installation via une commande, l'utilisateur obtient accès à cinq commandes slash principales qui contrôlent le workflow : setup, implement, status, new track et revert. Cette section établit les bases techniques nécessaires pour comprendre comment Conductor fonctionne. L'auteur compare cette approche à celle d'autres outils pour contextualiser l'architecture de Conductor.

L'auteur explique en détail le fonctionnement de la commande setup, qui est la première étape du workflow. Cette commande vérifie d'abord l'existence de fichiers Conductor préexistants pour savoir si un projet a déjà été initialisé. Au lieu de 'stories', Conductor crée des fichiers appelés 'tracks' qu'il complète progressivement, initialise un nouveau dépôt GitHub et demande ce qu'il faut construire. Pour tester le système, l'auteur a créé un projet simple mais volontairement demandé qu'il soit prêt pour la production et évolutif pour tester si l'architecture recommandée serait appropriée. Conductor crée ensuite le fichier product.md avec le concept du projet et pose des questions de clarification, bien que l'auteur note que ces questions étaient simplistes et ne menaient nulle part, le forçant à tout générer automatiquement.

Après l'approbation du guide produit, Conductor crée un fichier de directives produit axé sur le style et les principes de conception. Ensuite vient la définition de la pile technologique, et c'est là que l'auteur identifie un problème majeur : Conductor a mal géré les recommandations technologiques malgré une compréhension complète du projet. L'auteur a dû faire corriger la pile technologique manuellement. Conductor possède également des guides de style de code pour différents langages qu'il ajoute automatiquement pendant l'initialisation. Le workflow par défaut est décrit comme plutôt bon, incluant une couverture de test de code à 80%, l'écriture de tests pendant le développement, la validation des modifications après chaque tâche et l'utilisation de notes git pour le suivi. Cette section révèle la première faille significative de Conductor dans la sélection technologique.

Après la configuration initiale, Conductor crée des exigences produit de haut niveau pour commencer la première track (piste). L'auteur critique cette première piste comme étant trop large et nécessitant d'être divisée en pistes plus petites avec trop de risques d'erreurs si tout est fait simultanément. Pour démarrer le travail, on utilise la commande implement qui traite les différentes pistes dans le dossier tracks. Chaque piste contient deux fichiers : plan.md avec les tâches à implémenter une par une, et spec.md avec l'objectif et les détails techniques extraits de la pile technologique. La commande implement examine le fichier tracks.md où le statut de chaque piste (vide = non démarré, en cours, ou complété) détermine les actions à prendre. Cette structure organisationnelle est l'un des aspects positifs du système.

L'auteur présente les autres commandes disponibles dans Conductor. La commande status fournit un rapport d'état montrant les pistes en cours et terminées. La commande new track pose des questions pour créer une nouvelle tâche. L'auteur a également testé Conductor sur un dépôt préexistant, où le processus était légèrement différent car le système examinait les fichiers existants et posait seulement des questions de clarification sans demander de nouvelle piste automatiquement. La commande revert est présentée comme une fonctionnalité intelligente qui atténue les dommages grâce à une intégration git consciente, permettant de revenir en arrière si l'agent se trompe. Cette section montre la polyvalence du système mais aussi ses limitations dans différents contextes d'utilisation.

L'auteur commence à détailler les nombreuses erreurs rencontrées lors de l'utilisation de Conductor. Bien que la gestion et la structure des fichiers soient décentes, et que l'implémentation et le suivi des tâches soient plutôt bons, les instructions et fichiers de commande sont mal écrits et ne gèrent pas correctement la boucle de contexte. La première erreur majeure est que pendant le processus initial, Conductor n'a pas correctement disséqué l'idée du projet malgré de nombreuses questions, obligeant l'auteur à beaucoup le guider avant de laisser le système générer automatiquement. Lors de la définition de la pile technologique, Conductor a raté beaucoup d'éléments essentiels malgré la demande explicite d'une application évolutive pour un grand nombre d'utilisateurs, nécessitant des clarifications manuelles. Ces erreurs suggèrent des problèmes fondamentaux dans l'implémentation des commandes plutôt que dans le modèle Gemini lui-même.

L'auteur révèle des erreurs encore plus graves dans le fonctionnement de Conductor. Le schéma de base de données généré pour la première piste était totalement incomplet, manquant des éléments cruciaux pour configurer l'application, nécessitant à nouveau un guidage manuel. L'erreur la plus grave s'est produite lorsque l'auteur a demandé de changer NPM pour PNPM après coup : Conductor a tenté de faire une sauvegarde mais a fini par supprimer le dossier conductor entier contenant tous les fichiers de planification. Après cette suppression, le système cherchait continuellement le dossier manquant et a finalement déclaré qu'il allait reconstruire tout le dossier conductor en utilisant son contexte et sa mémoire. Cette erreur majeure contraste fortement avec des workflows comme Be Mad où un changement n'affecte que les fichiers de contexte principaux et les fichiers liés à la tâche spécifique, démontrant une défaillance architecturale fondamentale.

L'auteur continue à documenter les problèmes rencontrés lors de l'implémentation réelle. Lorsque Conductor a initialisé le projet et les services principaux, il a rencontré un problème majeur avec les variables d'environnement pour la connexion Supabase. Au lieu de demander les vraies credentials, le système a automatiquement marqué la tâche comme terminée tout en insérant clairement une clé factice dans la configuration. Il n'a pas demandé de configurer le projet Supabase ni de fournir une vraie clé, puis a automatiquement tenté de pousser le schéma de base de données, ce qui a échoué en raison de l'absence de vraie clé. Cette séquence d'événements révèle que les tâches ne sont pas correctement mises à jour et que le système ne les suit pas correctement, posant des questions sérieuses sur la fiabilité du workflow pour un développement réel.

L'auteur conclut sa revue en déclarant qu'il n'utiliserait pas Conductor pour le moment pour le développement de spécifications de bout en bout, recommandant plutôt Be Mad comme une bien meilleure option. Pour les petits projets, il préfère encore créer ses propres fichiers de contexte manuellement. Il termine la vidéo en invitant les spectateurs à soutenir la chaîne via le bouton Super Thanks et remercie l'audience. Cette conclusion ferme résume l'opinion négative de l'auteur sur Conductor malgré quelques aspects positifs comme la structure de fichiers et l'intégration git, soulignant que les problèmes fondamentaux d'implémentation et de gestion des tâches rendent l'outil non recommandable dans son état actuel.