Mise à jour de Busy : Bon, l’implémentation 10 sera conçue dès le départ pour un schéma multi-agents. Plusieurs modèles, avec plusieurs types de rôles. Mini, mon agent de QA diabolique, fera enfin son entrée tant attendue. J’ai décidé de lui donner une personnalité gentille, mais ferme, et aucune tolérance pour le code foireux ou les conneries d’implémentation. Et c’est précisément la prochaine étape.
Mais d’abord, parlons d’où on en est aujourd’hui et des progrès faits depuis hier.
J’ai décidé de faire cette version de l’app en Dart parce que c’est le langage moderne le plus léger cognitivement parmi ceux disponibles. Lua est plus léger, mais c’est galère à installer et il y a d’énormes lacunes fonctionnelles quand on parle de web sockets, de hooks et de tout ce dont on a besoin pour bâtir une architecture système robuste qui utilise GitHub comme source de vérité.
Les couches webhook et serveur local
Tout le système repose sur deux couches importantes. La première est une app de « capture » de webhooks écrite en PHP qui collecte les données de GitHub. La version actuelle est assez limitée et ne fonctionne que tant que le serveur local tourne. Je dois régler ça, mais c’est moins urgent que d’ajouter les fonctionnalités d’IA proprement dites.
La seconde couche est le serveur local, qui tourne sur mon PC et ouvre un tunnel web pour les callbacks. C’est plutôt efficace. Il lance le serveur, appelle le tunnel, envoie l’URL de callback du tunnel via FTP à l’application PHP pour que le capteur sache qui appeler, et voilà qu’on a notre petite boucle de commande bien huilée.
Ce n’est pas parfait, les tunnels plantent, et on ne conserve pas encore l’historique des webhooks ni la relance des callbacks échoués, mais je veux intégrer un maximum de fonctionnalités de base avant la fin du week-end.
Le marshaller et les agents
L’étape suivante est de concevoir le système d’agents, en commençant par le marshaller. Le marshaller va utiliser gpt4all, je pense, pour se placer au-dessus du flux d’événements et surveiller chaque transmission entrante. Il va prendre quelques décisions clés du genre : « ce message nécessite-t-il une réponse ? » et « quel type de requête est-ce ? »
Ensuite, il va cracher du JSON, qui sera analysé par le parseur de commandes, lequel dépêchera un agent pour faire le job. Le marshaller est en fait un très bon point de départ pour les agents, car c’est le plus simple globalement.
Les autres agents sont beaucoup plus complexes, avec des commutateurs de cerveau, du double changement de contexte, et tout, partout, tout en même temps.
Le marshaller règle le problème qu’on avait à l’implémentation 4, quand les agents ont un peu pété un plomb et ont commencé à halluciner des traumatismes personnels et des designs d’avions alors qu’on leur demandait de bosser sur un projet dans un chat.
Ça va aussi me donner l’occasion de tester certains de ces modèles open source et de voir s’ils ont vraiment du niveau en code !
Note à part : on dirait qu’Anthropic a lobotomisé Haiku, et qu’il n’est plus utile pour coder. C’est dommage parce que c’était mon modèle Claude préféré. Encore un peu de conneries comme ça, et je bascule le projet sur les modèles d’OpenAI.