Alors, je suis en train d’écrire Busy, un outil de codage haute vélocité pour les programmeurs, qui sera open source. C’est un client personnalisé pour Claude avec des super-pouvoirs de code. Super intéressant. Vous savez quoi d’autre qui est intéressant ? Le fait que je me sois totalement plantée sur le schéma des commandes.
Voyez-vous, mon premier réflexe a été de parser la fenêtre de chat comme un langage de script. Inventer une interface de commande où on pourrait faire du pattern matching sur une expression lexicale pour en extraire les commandes. Mais c’est une façon très brouillonne de faire les choses.
Par contre, ce qui est cool, c’est que j’ai pigé que je pouvais mettre en place un contexte de commande qui est en gros une interface powershell verrouillée que Claude peut utiliser. Ça demande quelques fonctionnalités, comme l’éditeur de fichiers le plus léger jamais écrit, mais c’est d’une simplicité enfantine.
Et ça fait tellement moins de code.
J’aime l’élégance du truc. Dire à la machine... « Hé, regarde ce bout de code, documente tout et rédige un markup. Ensuite, fais de l’ingénierie inverse à partir de la spec. » Et ça marche.
Ça dépend de la complexité.
Mais, pas à grand-chose près.
La méthode que j’ai trouvée limite la taille des fichiers à moins de 6kb, ce qui est parfait pour les architectures de type microservices et une séparation claire des responsabilités au sein de n’importe quel module.
Je suis aussi en train de faire un gros nettoyage du système de métriques que j’ai pondu pendant les vacances et qui pilote la QA automatisée. Maintenant, tout va être piloté par base de données au lieu du JSON, et ça devrait être accessible depuis le contexte de commande.
C’est ça, le côté fun.