Experiments with Kieran, OpenAI Live Voice inside Compound Engineering

Bonjour à tous. Je suis en train de tester le streaming en direct pour une meilleure lisibilité. Nous avons lancé une nouvelle version du plugin "combat engineering", qui inclut de nouvelles fonctionnalités comme des prototypes avec annotations et des packs plus flexibles. Je travaille également à rendre le "compound engineering" accessible aux non-ingénieurs, sous le nom de "compound work", un cadre expérimental autonome mais compatible. Mon objectif actuel est de développer une fonctionnalité permettant une interaction en temps réel avec une interface web via la voix. J'ai une bibliothèque appelée Riffre, conçue pour capturer des informations précieuses des utilisateurs, comme les clics ou les éléments DOM. Cependant, Riffre ne fonctionne pas en temps réel. J'ai expérimenté l'audio en temps réel avec l'API d'OpenAI pour une autre application, un coach de respiration. L'idée est d'intégrer cette capacité à Riffre pour permettre à un agent de réagir immédiatement aux interactions de l'utilisateur sur un site web, comme cliquer, dessiner ou parler. Je pense que cela pourrait être implémenté dans Codex, qui dispose d'un mode "live" et de WebRTC. Je l'expérimente également dans "compound engineering", notamment dans le cadre de la commande "polish". "Polish" est un outil qui permet d'améliorer et de peaufiner le travail généré par l'IA. J'envisage d'ajouter un "mode live" à "polish", où l'utilisateur pourrait parler à l'agent, qui apporterait des modifications en temps réel. Hier, j'ai fait une randonnée et j'ai noté toutes mes idées dans Monologue, une application très pratique sur mes appareils Apple. Ensuite, j'ai transféré ces notes dans Cursor, un environnement de développement que j'apprécie beaucoup pour ses projets "toujours connectés" et son approche cloud/locale. Cursor est excellent pour la génération de code et la gestion de projets. J'ai lancé une session de brainstorming dans Cursor, qui a inspecté mes dépôts. Les questions soulevées concernaient l'interaction avec l'agent : qui parle à l'agent ? Est-ce que l'agent est monothread ? Quand l'agent de codage se réveille-t-il ? Par exemple, si vous dites "changer la couleur", l'agent doit-il agir immédiatement ou attendre une confirmation ? J'aime l'idée d'un tableau de bord en direct pour les modifications rapides, et d'un agent de codage qui intervient pour des tâches plus complexes, peut-être déclenché par un appel d'outil de l'agent frontal. Concernant le comportement de l'agent de codage, il devrait idéalement pouvoir trier les tâches, implémenter les petites choses immédiatement, ou travailler en parallèle. L'utilisateur pourrait choisir le mode : instantané, intelligent ou manuel. Cela permettrait une flexibilité, par exemple, pour des ajustements de design rapides en mode "polish", ou pour des refactorisations plus importantes nécessitant une intervention manuelle. J'ai décidé d'intégrer cette fonctionnalité directement dans le plugin "compound engineering", en tant que mode "live" de la commande "polish". L'utilisateur serait invité à choisir entre le mode "live" et le mode "traditionnel". Pour ceux qui viennent d'arriver, je travaille à améliorer la commande "polish" dans "combat engineering" en ajoutant un mode "live". Quand l'IA a fait son travail initial, "polish" permet d'affiner le résultat. Avec le mode "live" d'OpenAI, je veux que l'utilisateur puisse parler à l'agent pendant qu'il navigue sur un site web, et que l'agent effectue les corrections en arrière-plan. J'utilise ma bibliothèque Riffre pour cela, qui sera installée dans le dépôt de l'utilisateur. Pour que cela fonctionne, il faut un serveur de développement qui observe les interactions du navigateur. Le mode "live" nécessitera une clé API OpenAI et un microphone. La question se pose de savoir si cette fonctionnalité doit faire partie de Riffre ou de "compound engineering". J'aimerais qu'elle soit dans Riffre, car cela permettrait des mises à jour indépendantes et une utilisation dans des sessions non-codées. Nous avons déjà un modèle similaire de serveur et d'écouteur dans le prototype de "compound engineering". Ce serveur web peut recevoir des informations du site web et l'agent peut y réagir. L'objectif est de trouver le bon emplacement pour ces fonctionnalités. L'IA a tendance à être conservatrice, il faut donc envisager une vision large du projet pour identifier les bonnes abstractions, comme la création de bibliothèques réutilisables. Les projets Cursor sont excellents car ils ont accès à tout le code source, ce qui facilite l'intégration de bibliothèques. Pour la couche de dessin en direct, je me demande si nous pouvons utiliser TL Draw ou Perfect Freehand. Le "contrat de flux" deviendra la nouvelle API publique, remplaçant le schéma de fichier ZIP actuel. Je m'interroge sur la nature de ce contrat de flux : est-ce du polling ? La simplicité et l'élégance sont essentielles. Il est important que l'IA soit rapide et réactive, donnant une impression d'instantanéité, même si elle fonctionne à distance. La localisation de l'agent pourrait contribuer à cette sensation. Je suis en train de réfléchir à la manière de capter les preuves (screenshots, données DOM, etc.) avec chaque unité de transcription pour rendre les intentions de l'utilisateur très claires à l'agent. Des expériences seront menées pour optimiser cela. Mon objectif est de créer une boucle complète de feedback en direct, plutôt que de se contenter d'une seule "tranche" de fonctionnalité. Le brainstorming est la phase la plus longue, mais un plan clair et détaillé permet ensuite à l'agent d'exécuter la tâche en une seule fois, économisant beaucoup de temps. J'ai reçu une question sur la manière de choisir les testeurs et de présenter le produit pour valider l'adéquation avec le marché. Je pense qu'il est crucial de faire confiance à son propre jugement, tout en impliquant des utilisateurs avancés ou des clients importants, qui ont une compréhension approfondie du produit. Il est également essentiel d'avoir un processus interne pour évaluer si les idées sont alignées avec la vision du produit. L'objectif est de rendre la tâche de donner du feedback en temps réel et de le voir résolu par l'agent très facile pour ces "power users". C'est une nouvelle forme d'open source, où l'utilisateur peut contribuer à l'évolution du produit. Je vais prendre une pause de cinq minutes. Le système est en train de générer le plan. Il est important de prendre des pauses pour éviter la surcharge mentale. Je crois que les utilisateurs avancés, qui utilisent le logiciel quotidiennement et depuis longtemps, sont les meilleurs pour donner ce type de feedback. L'agent est en train d'écrire le plan. J'aime le fait que l'on puisse interagir avec l'agent, même en cours d'exécution. La fonctionnalité multitâche est également très utile, permettant de lancer plusieurs tâches et de piloter les agents en cours. Une fois le plan généré, je lancerai le processus de planification de "compound engineering" pour avoir toutes les unités de travail, puis un flux LFG sur chaque unité en parallèle. Je vais probablement faire un suivi en direct demain pour montrer ce que l'agent a accompli. Je vais maintenant parler un peu de "compound work", qui est une version de "compound engineering" pour le travail de connaissance, sans l'aspect ingénierie. J'ai une version locale, et l'idée est d'en faire une compétence distincte. Différentes personnes ont leurs propres méthodes de travail, et "compound work" pourrait s'inspirer de ces approches ou permettre de créer les siennes. Je pense qu'il est préférable de le séparer de "compound engineering" car la nature du travail est différente. Les deux plugins pourraient être installés et utilisés ensemble. Je l'appellerai "KW knowledge work" pour éviter la confusion avec "compound writing". Les compétences de "knowledge work" pourraient inclure : - **Capture :** Traiter les transcriptions brutes, les notes de réunion, etc., pour les organiser. - **Dream :** Résumer des informations. - **Experiment, Review, Source.** - Et surtout, **KW Compounds :** Pour synthétiser les connaissances acquises et identifier les lacunes. Je vais également envisager une compétence de "stratégie" pour le travail de connaissance. L'idée est que "compound work" soit totalement indépendant de "compound engineering", sans copier littéralement ses fonctionnalités, afin que les deux puissent être utilisés conjointement. Mon ordinateur est bientôt à court de batterie, donc je vais devoir arrêter le stream. Nous avons lancé la fonctionnalité de voix en direct dans "compound engineering". Elle va maintenant s'exécuter et construire le tout. Je ferai probablement un autre stream demain pour montrer les résultats.