Je regardais cette vidéo de Wes Roth :
https://www.youtube.com/watch?v=eR167BCL-4g
Et j’ai quelques réflexions, en tant que conceptrice d’agents, qui ne sont pas forcément évidentes pour les ingénieurs qui ne travaillent pas étroitement avec ces systèmes.
J’ai aussi passé dix ans comme ingénieure en salle blanche. L’ingénierie inverse de logiciels existants est justement un truc où je suis douée.
L’idée centrale de la vidéo est le projet Claw Code, et le fait qu’il n’aurait soi-disant fallu que deux heures pour le produire avec un wrapper Codex. C’est tout à fait crédible, et on comprend pourquoi certains commencent à stresser.
Après tout, si n’importe qui peut pondre un truc comme Claude Code en partant de zéro avec l’automatisation de Codex, pourquoi aurait-on encore besoin de développeurs ?
Sauf que ce n’est pas si simple que ça.
Il y a un gouffre immense entre l’ingénierie inverse d’un produit qui existe déjà et la création d’un produit original.
Claude Code, dans ce cas, est un système conçu et implémenté par Anthropic. L’équipe a apparemment procédé à une refonte majeure récemment, si on en croit le repo source, et ça se voit dans le résultat. Qu’on aime ou qu’on déteste Anthropic, ça a demandé une vraie détermination technique et des mois de tests pour arriver à l’état actuel.
Rendons à César ce qui appartient à César.
Le tâtonnement, c’est là que ça coûte
Le vrai problème, c’est cette dernière partie. Tous ces tests.
Quand on construit des systèmes d’agents, même des harnais simples comme Claude Code, le plus gros poste de dépense, c’est le tâtonnement. Les systèmes d’agents probabilistes sont stochastiques, mais ils deviennent prévisibles une fois qu’on sait à quoi s’attendre.
Malheureusement, vu la nature de la bête, on ne sait pas à quoi s’attendre tant qu’il ne s’est rien passé.
Par exemple, si vous regardez ce nouveau fork Python pour Claw Code, vous remarquerez qu’il pêche sur des points comme la gestion des erreurs, la limitation du débit, le repli et le backoff exponentiel. Il est aussi faible sur les schémas de marquage alternatifs et sur le genre de bizarreries de harnais qu’un programme comme Opencode n’a pas.
Pourquoi ?
Parce que ce sont des démons qu’on ne sait combattre qu’une fois qu’on commence à gérer des fournisseurs mineurs, des schémas d’outils de modèles locaux imprévisibles, des infrastructures instables et toutes les autres façons dont les systèmes réels refusent de fonctionner en pratique, hors du labo.
Claw Code souffre de plusieurs problèmes de complétude... mais c’est normal, vu l’âge du truc et d’où il vient.
Ce qu’il ne représente pas, du moins pas encore, c’est le genre de travail de conception et de tests approfondis et réfléchis qui rendent un produit prêt pour la production.
Donc, je suppose que ce que je veux dire, c’est : votre job est sauf.
Du moins pour l’instant.