Ma configuration de programmation avec l’IA : agents, skills, terminaux et worktrees

De nos jours, je code rarement une fonctionnalité complète à la main. Les agents ont tellement évolué au cours des deux dernières années qu’il est maintenant possible de décrire une fonctionnalité entière, la façon dont tu veux que son code soit organisé, et l’agent écrira toute la logique. Tests inclus.

J’ai donc dû préparer mon environnement de développement local pour travailler plus vite et plus intelligemment avec différents agents, qu’ils soient distants ou locaux.

Je dois toutefois dire que j’utilise moins les agents locaux, parce que cela prend plus de temps d’obtenir leurs réponses et de parcourir de plus grandes bases de code.

Agents

Choisis les agents selon leur rôle

J’utilise soit Claude, soit Codex pour le travail et mes projets personnels, mais pas les deux en même temps. Mon entreprise paie l’accès à l’un d’eux et est à l’aise que je l’utilise pour mes projets personnels, donc la disponibilité fait aussi partie de la décision. Les deux ont des avantages et des inconvénients, mais je n’assigne pas le travail uniquement selon le nom du modèle. Je choisis un agent selon le type de travail dont j’ai besoin : recherche et planification, mise en œuvre quotidienne ou révision.

Pour la recherche et la planification, j’utilise Fable ou Sol lorsque j’ai besoin qu’un agent lise des documents, croise de l’information et propose une ébauche de solution. Ils sont aussi utiles lorsque j’ai besoin de résumer une conclusion en recoupant beaucoup de logs provenant de différentes applications.

Pour le travail de mise en œuvre lorsque je connais déjà la marche à suivre, j’utilise Sonnet ou Luna (Max). Il m’arrive d’utiliser Terra à la place. C’est le genre de tâche où je fournis autant d’information que possible : le plan, les fichiers pertinents, l’organisation attendue des fichiers et les contraintes. Ça m’aide à passer d’un plan clair à l’exécution sans traiter chaque tâche comme un problème de recherche.

Pour les révisions, j’utilise Terra avec Opus pour revoir mon code et laisser des commentaires sur les pull requests des autres. L’important n’est pas d’utiliser un modèle précis pour chaque révision. C’est de s’assurer que l’agent a assez de contexte pour suivre le changement, comprendre les patterns existants et relever les lacunes avant que le code soit fusionné.

Skills

Les scripts de Matt

Je connais Matt depuis que j’ai suivi son cours sur totaltypescript.com. C’est là que j’ai vu qu’il s’était vraiment plongé dans la programmation avec l’IA au cours des derniers mois. C’est à ce moment que j’ai regardé les skills qu’il créait, non seulement pour avoir un point de vue technique, mais aussi pour aider l’agent à vraiment comprendre la fonctionnalité avant de se mettre à coder.

grill-with-docs

Grill with docs modifiera l’objectif de l’agent jusqu’à ce qu’il puisse comprendre les règles d’affaires que tu veux atteindre. Une fois l’accord établi, il créera un ADR avec la portée, les objectifs et les concepts de domaine non écrits pour le développement futur avec des agents. Avec cette skill, la qualité et la portée de mes fonctionnalités ont été beaucoup plus clairement définies, et elle m’a aidé à penser aux cas limites avant que le code soit écrit.

Skill personnalisée pour les commits

Une skill personnelle qui est essentiellement un ensemble d’instructions pour regrouper les fichiers ou les hunks selon la fonctionnalité, puis commencer à faire les commits. L’agent te demandera si le regroupement est logique avant de faire le commit. Il te demandera aussi de créer une nouvelle branch si nécessaire.

Terminal

Herdr

Mon gestionnaire d’agents de terminal préféré est Herdr. Il a gagné en popularité récemment et, pour moi, c’est la prochaine étape après Tmux. L’an dernier, j’utilisais beaucoup Tmux. Mais une fois passé à Herdr, je n’ai eu aucun problème à créer de nouveaux onglets et panneaux. Il n’y avait plus d’erreurs pendant l’initialisation du shell dans le terminal, et le nombre de plugins augmente chaque jour.

Organisation des panneaux

J’utilise une disposition à trois panneaux, et ce, depuis mes années avec Tmux. Le panneau de gauche est le plus grand, et je l’utilise pour la conversation avec l’agent parce que j’ai besoin d’espace pour LIRE. Oui, tu as bien lu. Pour moi, lire est la partie la plus importante du travail avec un agent; autrement, je le verrai commencer à halluciner si mes instructions ne sont pas assez claires.

Le panneau supérieur droit est habituellement utilisé pour lazygit, ce qui me donne de la visibilité sur les fichiers que mes agents modifient. Aussi, s’il est plus rapide et moins coûteux de faire le commit moi-même, je suis généralement plus rapide à le taper que de demander à l’agent de le faire, surtout s’il n’y a que quelques fichiers modifiés.

Le panneau inférieur droit sert à lancer des commandes, des builds, des déploiements ou toute autre commande shell que je veux exécuter. Je peux aussi les lancer par l’intermédiaire de l’agent. Mais parfois, pendant que l’agent réfléchit, je préfère avoir la sortie visuelle d’une commande que je suis en train d’exécuter.

Worktrees

Worktrees avec Treehouse

Habituellement, j’ai trois copies du même projet sur mon ordinateur. Certaines personnes diraient que je gaspille de l’espace disque. Mais je pense que c’est l’équilibre parfait pour ce que je veux faire.

La première copie sert au développement de fonctionnalités. La deuxième sert à la recherche dans les logs, au recoupement de la documentation et à la planification. La troisième sert aux expériences et aux correctifs urgents.

En plus de ça, je travaille avec des worktrees. Il y a plusieurs façons de travailler avec des worktrees, notamment avec des outils de Claude et Codex. Tu peux configurer plusieurs agents pour commencer une recherche à l’aide d’un worktree, mais tu dois maintenir le lien symbolique entre les bibliothèques installées, surtout pour les projets TypeScript, et t’assurer d’avoir les mêmes fichiers .gitignore dans le projet d’origine et dans le worktree.

J’utilise Treehouse, de Kunchenguid. Treehouse te permet de gérer facilement tes worktrees avec des hooks et des commandes utiles. De plus, lorsque l’agent lit les commandes de Treehouse, il peut comprendre à quel point il peut facilement travailler avec l’outil.

Treehouse prendra le commit le plus récent de ta branch main ou master et commencera à travailler à partir de ce commit. Tu peux ensuite créer une nouvelle branch à partir de celui-ci.

Le seul inconvénient est que tu dois utiliser une longue commande :

treehouse

Mais comme j’ai déjà des connaissances en Bash, c’est assez facile pour moi de configurer des alias pour certaines de mes commandes les plus utilisées.

alias th="treehouse"
alias ths="treehouse status"
alias the="treehouse enter"

L’autre jour, je me disais : je veux avoir une seule commande pour ouvrir un nouvel onglet Herdr avec une disposition - les 50 % de gauche comme d’habitude, avec le côté droit séparé horizontalement.

Et après une séance de programmation avec Codex, c’était possible.

# Onglet de worktree avec Treehouse + Herdr
function treehouse_herdr_tab {
  local name="$1"
  if [[ -z "$name" ]]; then
    echo "usage: thw <name>" >&2
    return 1
  fi
  if ! exist treehouse || ! exist herdr || ! exist jq; then
    echo "thw: requires treehouse, herdr, and jq" >&2
    return 1
  fi
  if [[ -z "$HERDR_WORKSPACE_ID" ]]; then
    echo "thw: must be run from inside a herdr pane" >&2
    return 1
  fi

  local worktree_path
  worktree_path=$(treehouse get --lease --lease-holder="thw:$name") || return 1

  local tab_json root_pane right_pane
  tab_json=$(herdr tab create --workspace "$HERDR_WORKSPACE_ID" --cwd "$worktree_path" --label "🌳 $name" --focus) || return 1
  root_pane=$(jq -r '.result.root_pane.pane_id' <<< "$tab_json")

  right_pane=$(herdr pane split --pane "$root_pane" --direction right --ratio 0.5 --cwd "$worktree_path" | jq -r '.result.pane.pane_id') || return 1
  herdr pane split --pane "$right_pane" --direction down --ratio 0.5 --cwd "$worktree_path" >/dev/null
}

alias thw=treehouse_herdr_tab

Pour chaque worktree créé avec ce flux Treehouse, le script ajoute l’emoji 🌳 à l’étiquette de l’onglet Herdr. Ça rend les onglets de worktree faciles à reconnaître parmi le reste de mes sessions.

En utilisant l’alias thw <feature-name>, Herdr ouvrira un nouvel onglet, séparera les panneaux et entrera automatiquement dans le worktree dans chacun d’eux. Je peux ainsi commencer à expérimenter ou à travailler sur une fonctionnalité.

Notion

Notion est devenu mon organisateur personnel pour la vie de tous les jours, y compris pour la documentation technique. Au fil des ans, j’y ai tout géré : mes abonnements personnels, des itinéraires de voyage, une calculatrice de dépenses mensuelles, des snippets de code privés et du contenu copié sur Internet.

Maintenant qu’ils ont ajouté le support MCP, connecter mon code à Notion est devenu plus facile que jamais : créer des résumés de livres sur la conception de systèmes, stocker des snippets de patterns que je peux réutiliser dans d’autres projets et rédiger les premières idées de mes billets de blogue. Tout est lié et inclut un agent d’IA qui m’aide avec la grammaire avant que j’écrive les versions finales de mes billets.

Conclusion

Au cours de la dernière année, mon workflow s’est concentré sur l’écriture de code le plus vite possible. J’ai encore ces outils installés, mais faire évoluer mes workflows pour qu’ils soient davantage centrés sur l’IA est maintenant devenu une partie normale de ma routine. Recouper le plus d’information possible, puis créer davantage de contenu à partir de celle-ci - du code et de l’écriture - a été une astuce de productivité utile pour moi. Je m’attends à ce que cela devienne normal pour toutes les personnes qui sont aussi à l’aise de travailler avec un ordinateur.