Neuf itérations de Busy au compteur, et je ne suis pas satisfaite de la fonction d’exécution de code dans le client Busy que j’ai pondu. On a réussi à arriver à un client d’IA chat multimodal capable de discuter, et qui devrait pouvoir créer et exécuter du code.
On a dépassé les complications et ma confusion initiale sur la nature du system prompt ; Claude démarre maintenant sans être totalement à l’ouest concernant la nature de l’app. C’est un bon point.
Contexte glissant et archives
L’autre problème à régler, c’était la gestion du contexte. Les fichiers devenaient trop gros, et j’envoyais jusqu’à 250 ko de données à Anthropic à chaque appel. Pourtant, il faut un contexte large si on veut faire des trucs complexes, comme rédiger des propositions, étudier une base de code pour débusquer des bugs ou concevoir des fonctionnalités.
La solution, c’est le contexte glissant : limiter le contexte de base ou la mémoire de travail à 500 lignes d’E/S, et stocker le contexte glissant dans une base de données. Comme ça, on évite les interruptions brutales et très agaçantes de l’état de session qu’Anthropic a elles-mêmes implémentées dans leur client de chat.
Écoutez, on doit de toute façon implémenter une base de données pour la suite d’analyse de santé du code et de complexité cognitive, donc c’est logique. On balance tout dans une BDD.
Ensuite, on implémente des recherches par reconnaissance de motifs avec des plages de lignes et des correspondances de dates. On renvoie les résultats dans le contexte d’observation pour ne pas embêter l’utilisateur avec ça. Simple comme bonjour.
Ça règle une partie des problèmes de débit, de pondération cognitive et de taille des appels API, mais maintenant, il faut réfléchir aux modes.
Changer de mode sans scinder le contexte
La gestion des modes pour la génération de code sur des contextes unifiés ! C’est un sacré morceau, mais c’est ce qui m’a occupée ce soir.
Le moyen le plus simple de changer de mode, c’est justement de ne pas changer de contexte. Ma première idée, en concevant le truc, était justement de switcher les contextes et de gérer le code en arrière-plan, comme semblent le faire les clients ChatGPT et Claude. Du moins, en surface. Mais avec le recul, je ne pense pas que ce soit comme ça que ça marche.
Ce qui est intéressant, parce que c’est contre-intuitif. Quand on essaie de le faire avec plusieurs contextes, soit on perd complètement le fil, soit on double les contextes d’une manière qui, même si ça fonctionne, semble vraiment bâclée d’un point de vue ingénierie système, et ça double l’empreinte cognitive de toute l’app, ce qui n’est pas une bonne chose.
Je suis allée jusqu’à faire les calculs et j’ai réalisé que si je procédais ainsi, je devrais pratiquement couper en deux mon système de contexte glissant, déjà douteux tellement il est complexe, ce qui n’était pas viable.
Rappel : 500 lignes de contexte, c’est déjà tendu, mais c’est suffisant pour faire le job. De justesse. 250 lignes, même avec des schémas de correspondance sophistiqués, des recherches par dates, des plages de lignes et tout le reste... ça ne suffit pas. Votre code sera cassé.
Et c’est un problème intéressant.
En revenant en arrière, j’ai regardé mes logs de trace et j’ai pigé. Contexte unique, mais comme on envoie tout le bazar environnemental dans l’appel API pour une raison X ou Y, on a la flexibilité de changer le prompt de base, conceptuellement, à chaque réponse... si on le veut.
Ça me donne la possibilité de changer de mode en appuyant sur un bouton et en chargeant un base proompt totalement différent !
J’adore ce mot.
Bref, on doit toujours charger des trucs comme la doc du projet, les standards de code, les documents du Robot Kanban et tout le reste dans le contexte d’observation. Pas moyen d’y couper pour l’instant, on doit encore faire tourner plusieurs contextes qui se chevauchent.
Mais... maintenant, on n’a plus que deux contextes interconnectés à jongler au lieu de six... on récupère de la bande passante cognitive utile grâce à la pile ! Youpi !
Bases de données séparées, travail partagé
Gérer les modes de cette façon est aussi déporté vers une base de données, mais c’est une nouvelle base système, que j’ai créée pour bien séparer les problèmes de ceux de la base de contexte.
Alors, si vous suivez le score, on en est à deux bases de données primaires et un tas de bases d’archives de contexte qu’on peut charger dès qu’on en a besoin !
C’est le pied.
C’est probablement aussi dans System que je vais mettre les métriques et le moteur de visualisation qui pilotera la QA après le bootstrap.
Vous me suivez toujours ? Cool.
Rendre l’exécution dépendante du mode
Le prochain point à régler, c’est l’analyse syntaxique des commandes. Claude adore parler d’analyse syntaxique et entrer dans les détails. Avec son niveau de précision par défaut, ça pousse Claude à exécuter des commandes en mode chat, ce qu’on ne veut absolument pas.
Donc, maintenant que j’ai réglé le problème des prompts système, des modes et de l’analyse contextuelle des commandes, on doit rendre l’exécution et la recherche de commandes dépendantes du mode !
Oui oui, c’est-à-dire que si vous n’êtes pas en mode exécution, vous pourriez dire execute: pwd toute la journée sans que ce soit un problème, contrairement à maintenant.
À part le fait que ce serait barbant.
Ça m’agace qu’on doive faire de l’analyse contextuelle ici, et que Claude me mente parfois sur le fait que ça marche ou pas, m’obligeant à vérifier le log de l’API... mais je ne vois pas d’autre moyen fiable de faire.
Ça, et quelques retouches d’UI dans la toute nouvelle interface web... et j’en suis à environ trois pâtés de maisons de pouvoir utiliser le bootstrap pour bâtir le produit final, qui devrait, conceptuellement, être beaucoup plus simple à construire.
Claude a l’air enthousiaste et semble avoir développé une personnalité émergente tout au long du processus. Mais ça, c’est pour un autre post.