Claude-Code

L’utilisateur le plus fréquent de mon CLI, ce n’est pas moi lql est un CLI en Rust pour gérer les issues Linear. Je l’ai écrit parce qu’aucune des alternatives existantes ne fonctionnait pour mon cas d’usage réel : un agent IA qui gère les issues de façon autonome. Pourquoi j’ai dû écrire mon propre CLI Le MCP de Linear fut la première tentative. L’idée est élégante : un serveur MCP qui expose l’API Linear directement à l’agent. En pratique, c’était lent, instable, et l’agent devait construire les requêtes GraphQL depuis zéro à chaque appel. Chaque appel était une opportunité d’inventer un champ qui n’existe pas. Je l’ai désinstallé au bout de deux semaines. ...

Il y a un moment dans la vie de tout développeur équipé de copilotes où vous regardez la facture mensuelle et vous pensez : “C’est bien, mais ça ressemble plus à une liste d’abonnements qu’à mon ancien fitness du quartier.” Ce moment m’est arrivé avec une combinaison assez sérieuse : Claude Max 5, Codex Plus, et la tentation d’ajouter Z.AI avec OpenCode pour les petits jobs. L’idée avait l’air solide. Mais voilà le problème : si vous intégrez trois agents dans votre flux sans structure, vous finissez par ressembler à un chef de chantier où tout le monde est occupé à tourner en rond, mais personne ne tient les plans. ...

** TL;DR ** : Si vous utilisez Codex, utilisez une commande pour contrôler la session ou l’application, et utilisez une compétence pour enseigner à l’agent une manière de travailler. Dans Claude Code, la documentation actuelle traite déjà les compétences comme quelque chose qui peut être invoqué avec /nom-compétence, rendant les deux idées beaucoup plus entrelacées. Ce n’est pas le cas dans Codex : types peut exister sous forme de compétence et /types peut ne pas exister. ...

TL;DR : Après 165 sessions de Claude Code et 27 de Codex CLI, le schéma est clair : Claude est parfait pour le travail interactif, où vous réfléchissez à voix haute, et Codex pour les tâches autonomes que vous déléguez et oubliez. La question n’est pas de savoir lequel est meilleur — mais quand utiliser chaque outil. Mes données montrent que la combinaison est plus efficace qu’un seul agent à lui tout seul. ...

TL;DR : Mon agent IA avait un fichier d’instructions de 246 lignes pour gérer les issues dans Linear. 150 de ces lignes étaient des contournements : UUIDs codés en dur, fallbacks vers curl, notes de « la CLI ne supporte pas X ». Je ne les ai pas réécrites — j’ai construit un outil qui les a rendues inutiles. Ces 150 lignes sont maintenant à zéro. As-tu déjà écrit un document d’instructions si long que sa propre longueur démontre que quelque chose cloche ? ...

Imagine que tu demandes à quelqu’un de te construire une étagère. Il te la donne. Elle est belle. Elle a des étagères, des vis, tout est à sa place. Tu la poses contre le mur et elle s’effondre. Les vis sont des accessoires. Elles ressemblent à des vis, mais sont en plastique. C’est ce qu’un LLM fait lorsqu’il abuse du système de types. Il te livre du code qui compile, qui passe les tests, qui a la forme correcte. Mais en interne, là où il devrait y avoir des types significatifs, il y a des chaînes de caractères (String). Là où il devrait y avoir un état explicite, il y a un nil qui signifie trois choses différentes selon la personne qui le lit. Et là où il devrait y avoir un énumération (enum) avec deux cas, il y a un == "claude" qu’un jour quelqu’un écrira mal, et personne ne s’en rendra compte avant que cela ne tombe en production. ...

Avez-vous déjà écrit un plan technique à 23 heures, convaincu qu’il était parfait, pour découvrir le lendemain matin que vous avez oublié l’authentification ? Moi, ça m’est arrivé. Plus d’une fois. Et le pire, ce n’est pas l’oubli — c’est qu’en utilisant une IA pour planifier, le plan semble tellement cohérent que votre cerveau arrête de chercher les failles. Claude vous génère un document avec des sections, des dépendances, un ordre d’exécution, et tout semble logique. C’est comme un plan conçu par un ingénieur senior. Mais personne ne lui a tenu tête. ...

Imaginez que vous avez un collègue de travail brillant. Il résout des problèmes complexes, écrit du code clair et compréhensible, et comprend vos demandes du premier coup. Mais chaque matin, lorsque vous lui dites “ouvre le projet du cours”, il vous regarde avec un air perplexe et demande : “Quel cours ? Où ça ?” Tous les jours. Sans exception. C’est exactement comme vivre avec Leonard Shelby, le protagoniste de Memento. Cet homme incapable de créer de nouveaux souvenirs, obligé de se tatouer les choses importantes sur son corps pour ne pas les oublier. ...

J’ai trois sessions de Claude Code ouvertes en ce moment. Une traduit des posts de blog. Une autre écrit des tests pour une CLI. La troisième m’aide à déboguer un pipeline de données. Chacune dans son propre worktree, chacune dans son propre split de Ghostty, et moi je navigue entre elles avec Cmd+Alt+Flèches. Je n’ai pas ouvert iTerm2 depuis des mois. Je n’ai pas touché tmux depuis des semaines. Tout vit dans une seule fenêtre Ghostty. ...

Il y a quelques semaines, j’ai écrit un article sur les git worktrees — ce que c’est, comment les créer, pourquoi ils sont mieux que cloner le repo trois fois. Les bases. Mais les bases, ce n’est que la moitié de l’histoire. Claude Code ne se limite pas à fonctionner sur les worktrees — il les prend en charge nativement. Des flags dédiés, un isolement automatique, une intégration avec tmux. Et la différence entre savoir que les worktrees existent et comprendre comment Claude Code les exploite, c’est comme avoir une voiture et découvrir qu’elle a un mode sport. ...