Alors, voilà ce qui me trotte dans le crâne. Cette expérience de création d’un langage de script avec Claude 3.5 a été intéressante. Ce que j’en retire, c’est que n’importe qui peut se lancer et pondre un truc aussi complexe qu’un langage de script avec Claude... à condition de déjà savoir comment concevoir un langage de script. Et ça, c’est fascinant.
Quelques autres points intéressants. La meilleure façon d’aborder Claude, c’est d’être formelle. On discute du sujet à fond, et on rédige une spécification technique. Par défaut, Claude va vouloir prendre des raccourcis, donc il faut lui expliquer clairement vos standards de documentation.
Une fois que vous avez votre spec technique, il faut aussi dire à Claude de passer en mode Kanban. Aucun autre processus formel n’a vraiment de sens avec ce workflow. Et comme il faut maintenir le contexte entre les sessions, l’astuce consiste à demander à Claude de rédiger un SOW complet, à chaque fin de session.
Maintenir le contexte
Pour faire ça, il faut passer par les projets. Les projets sont utiles, mais ils ont un défaut majeur. Anthropic est complètement à côté de la plaque sur l’estimation de leur fenêtre de contexte. Vraiment. Donc, pour les longues réunions de design ou les chats d’implémentation, gardez l’utilisation du contexte de votre projet sous les 13 %.
Utilisez Git, parce que Claude arrive occasionnellement à se mettre dans un état second et à nuker votre projet.
Modèles et QA
Le processus de QA est intéressant lui aussi. Mon modèle préféré pour coder, c’est Claude 3.5 Haiku. Mais Sonnet fait aussi (généralement) très bien l’affaire. J’utilise une combinaison d’Opus et de @ChatGPT (mini) pour la documentation technique et la QA.
Mini est aussi efficace pour la récupération de code quand Claude pète un plomb et décide de sortir toute l’appli dans un seul fichier, mais il subit un crash cognitif dès que l’appli dépasse la taille d’une boîte à pain.
1o Mini est absolument incroyable pour la QA technique et 4o est presque comparable. D’après mon expérience, 1o n’a aucune personnalité, alors que 4o a un côté créatif sauvage et est plus fun à utiliser.
Ce qui a changé dans le workflow
Tout compte fait, je suis passée de la planification à la spécification technique, puis au MVP de base en environ une semaine. Maintenant, je bosse sur l’après-MVP et les améliorations organisationnelles. Une API basique, et plus de types de sorties utiles.
Pour vous donner une idée, même si tout le système est poussif avec les coupures de session et les copier-coller entre différents modèles sur différentes plateformes pour limiter les biais et traquer les erreurs... ça a été une putain de semaine.
Le dernier langage de script que j’ai construit a pris 18 mois pour être au point, en y travaillant tous les jours. Il était écrit en C++ et l’actuel est en Go. Et le nouveau est plus simple, il cible moins de plateformes, donc il faut prendre ça en compte.
De plus, bosser en Go par défaut règle pas mal de problèmes avec le code généré par IA, parce que le langage a des avis tranchés sur des trucs comme les imports et les variables inutilisées.
Au final, en faisant le calcul et en tenant compte des inefficacités du processus... c’est un gain de performance d’environ 9 000 % par rapport à un travail manuel.
Ça marche, si vous savez concevoir, coder et faire de la QA. Il faut en quelque sorte avoir les compétences de toute une équipe de production. Et je suis un cas particulier pour pouvoir faire ce genre de choses, je pense.
Le niveau de complexité ici est assez élevé.
Mais je m’éclate.
C’est une façon de bosser vraiment plaisante.