Alors, pendant ces vacances de Noël, j’ai essayé de voir comment rendre Claude Sonnet plus performant et structuré pour coder. Le processus a été intéressant. J’ai eu quelques idées pour y arriver, environ 60 % ont fonctionné. C’est positif.
En ce moment, je tente de résoudre un problème de recherche et de data mining musical qui me semble important. Je bosse sur la création d’un outil à usage unique appelé Grimes.
Une fois terminé, il extraira les données et bâtira un modèle de données bien costaud en JSON pour chaque piste, regroupant toutes les données compositionnelles liées à la mélodie et au rythme.
Pour la partie modélisation, j’implémente partiellement la spécification de modélisation de données Crunchy 0.3.4 que j’ai écrite la semaine dernière. Ça me donne de la flexibilité et produit un modèle compositionnel utilisable pour l’analyse ou l’entraînement d’IA.
Il sortira aussi un midi très basique contenant une représentation simple des données rendues. Si une réparation sonore est nécessaire pour effectuer l’analyse, il s’en chargera. Il générera une série de fichiers, quelques rapports basiques et un journal de projet.
Comme son homonyme, il fait une seule chose, et une seule, mais il la fait bien.
Et tout ça tourne sur votre GPU (peu importe le modèle), donc on peut l’utiliser sur le corpus d’un million de chansons que vous avez justement sous la main. Enfin, je veux dire, qui n’est pas dans ce cas ? Tout le monde n’a pas littéralement un million de chansons sur son disque dur ? Allez, à quoi else sert un disque dur de 30 To ? Franchement.
Bref, il n’existe aucun outil convivial pour effectuer ce genre de data mining et d’analyse à grande échelle spécifiquement conçu pour les chansons pop et leurs dérivés, alors je me suis dit que j’allais prendre le temps d’en construire un.
Le processus d’ingénierie
J’utilise Claude pour faire ça. Et comme je l’ai dit, rester organisée et garder un processus cohérent a été un puzzle vraiment intéressant.
Pour y parvenir, je gère l’étape actuelle en générant un document à la fin de la session. Pour éviter que le cerveau de Claude ne fonde face à la complexité du truc, j’ai développé un concept appelé « logic mapping » qui couvre les détails critiques de base du code écrit en Go et en Python. Go est un meilleur outil pour ce genre d’application, parce qu’on ne peut pas créer accidentellement des variables ou des imports inutilisés. Et si ça ne marche pas... ça ne compile pas.
J’ai dû concocter un standard de codage pour que Claude programme en Go comme il le fait en Python, mais maintenant qu’on y est, ça roule plutôt bien.
Toute l’appli a été écrite en une journée.
Je suis dans les dernières étapes du débogage.
Tout ça sera beaucoup plus propre la semaine prochaine, quand ma stratégie d’amorçage d’agents sera opérationnelle.