- Mitchell Hashimoto, après son exit de HashiCorp et alors qu’il développe Ghostty, retrace le processus qui l’a mené à intégrer des outils d’IA dans son travail réel
- Il distingue trois étapes — inefficacité → adaptation → gain de productivité — et documente concrètement les tâtonnements et apprentissages à chaque phase
- Après avoir identifié les limites du codage basé sur les chatbots, il a commencé à voir une vraie valeur en passant à des outils basés sur des agents
- En s’entraînant à faire reproduire par un agent des commits qu’il avait auparavant réalisés manuellement, il a compris que la décomposition des tâches, la séparation planification/exécution et la vérification automatique étaient essentielles
- En utilisant les 30 dernières minutes de sa journée pour lancer des tâches automatisées nocturnes, et en déléguant aux agents des tâches simples et répétables, il obtient un gain de productivité concret
- Aujourd’hui, il en est au stade où il fait toujours tourner un agent, tout en menant en parallèle un travail de « harness engineering » pour maximiser l’efficacité de la collaboration entre l’IA et l’humain
Contexte d’adoption et approche
- Chaque fois qu’un nouvel outil est introduit, il faut passer par trois étapes : inefficacité → adaptation → innovation
- L’adoption initiale est inconfortable parce qu’on est habitué au workflow existant, mais à long terme cela conduit à un gain de productivité
- Plutôt que de tomber dans l’enthousiasme excessif ou la critique des outils d’IA, il propose une vision équilibrée fondée sur l’expérience d’usage réelle
Étape 1 : sortir du chatbot
- Le codage via des interfaces de chatbot comme ChatGPT ou Gemini repose sur l’entraînement préalable, et la correction d’erreurs dépend de retours humains répétés, ce qui le rend inefficace
- Son premier moment « bluffant » a été de coller dans Gemini une capture d’écran de la palette de commandes de Zed pour la reproduire en SwiftUI, ce qui a servi de base à la palette de commandes macOS de Ghostty
- Mais dans le contexte de projets brownfield (base de code existante), les chatbots produisaient souvent de mauvais résultats, et le processus de copier-coller du code et des sorties était moins efficace que de faire directement le travail
- Pour en tirer de la valeur, il faut absolument utiliser des agents ; un agent est ici un outil permettant à un LLM d’appeler de manière répétée des actions externes, avec au minimum la lecture de fichiers, l’exécution de programmes et des requêtes HTTP
Étape 2 : faire reproduire son propre travail par un agent
- Lorsqu’il a utilisé Claude Code pour la première fois, il n’était pas satisfait du résultat, et les corrections prenaient plus de temps que de faire le travail lui-même
- Au lieu d’abandonner, il a répété un entraînement consistant à faire reproduire à l’identique par un agent des commits réalisés manuellement
- C’était un processus pénible, puisqu’il fallait faire le même travail deux fois (manuellement + avec agent), mais ce type de friction est naturel lors de l’adoption d’un outil
- Il en a tiré trois principes clés :
- Décomposer les sessions en unités de travail claires et exécutables
- Pour les demandes ambiguës, séparer une session de planification d’une session d’exécution
- Donner à l’agent des moyens de vérifier son propre travail afin qu’il puisse corriger ses erreurs et éviter les régressions
- Identifier les domaines dans lesquels l’agent n’est pas performant, et savoir quand ne pas l’utiliser, est aussi un facteur majeur d’efficacité
- À ce stade, il ne ressentait pas encore de gain net d’efficacité, mais il avait commencé à adopter l’agent de façon satisfaisante comme outil
Étape 3 : utiliser les agents en fin de journée
- Il a mis en place une routine consistant à consacrer les 30 dernières minutes de chaque journée au lancement de tâches pour les agents
- L’hypothèse était qu’un gain d’efficacité était possible si l’agent progressait pendant les heures où lui ne travaillait pas
- Trois types de tâches se sont révélés efficaces :
- Sessions de deep research : étude de bibliothèques sous une licence précise dans un langage donné, avec génération de synthèses multi-pages sur les avantages/inconvénients, l’activité de développement et les réactions de la communauté
- Exploration d’idées ambiguës avec des agents parallèles : non pas pour livrer tel quel, mais pour découvrir des variables inconnues avant le travail du lendemain
- Classification/revue d’issues et de PR : utilisation de
gh (GitHub CLI) avec des agents parallèles pour faire du triage d’issues ; les agents ne répondent pas directement, mais produisent seulement un rapport à consulter le lendemain
- Il ne faisait pas tourner les agents en boucle toute la nuit ; la plupart des tâches se terminaient en moins de 30 minutes
- En remplaçant un moment de fatigue en fin de journée par du travail d’agent, il obtenait un effet de « warm start » le lendemain matin
Étape 4 : déléguer des tâches avec confiance
- Une fois identifiées les tâches que les agents réussissent presque à coup sûr, il les délègue à des agents en arrière-plan pendant qu’il se concentre sur autre chose
- Chaque matin, il filtre manuellement les résultats du triage de la veille pour sélectionner les issues adaptées aux agents, qu’il lance ensuite une par une
- Pendant ce temps, au lieu de consulter des réseaux sociaux ou des vidéos, il effectue lui-même un travail de réflexion profonde selon ses méthodes d’avant l’IA
- Le fait de désactiver les notifications desktop des agents est crucial : le coût du changement de contexte est élevé, donc il est plus efficace que l’agent n’interrompe pas l’humain, et qu’on vérifie les résultats lors de pauses naturelles
- En réponse à l’article de recherche d’Anthropic sur la formation des compétences, il accepte de renoncer à la formation de compétence sur les tâches déléguées aux agents, tout en continuant naturellement à la développer sur les tâches qu’il fait encore à la main
- À ce stade, il a atteint un niveau « impossible de revenir en arrière », et le principal avantage est de pouvoir se concentrer sur les tâches qu’il aime
Étape 5 : harness engineering
- Les agents sont les plus efficaces lorsqu’ils produisent le bon résultat du premier coup, ou avec seulement des corrections minimales
- Le concept de « harness engineering » consiste à concevoir une solution pour qu’un agent ne refasse plus jamais la même erreur chaque fois qu’il se trompe
- Il en distingue deux formes :
- Amélioration implicite des prompts (
AGENTS.md) : lorsqu’un agent exécute une mauvaise commande ou identifie une mauvaise API, on consigne cela dans le fichier AGENTS.md pour corriger le problème — il existe un exemple réel dans le dépôt Ghostty
- Outils programmés : écriture de scripts pour des tâches comme la capture d’écran ou l’exécution filtrée de tests, puis indication dans
AGENTS.md que ces outils existent
- Il se trouve actuellement à cette étape et investit activement pour empêcher les mauvais comportements des agents et valider les bons
Étape 6 : toujours avoir un agent en cours d’exécution
- En parallèle de l’étape 5, il vise un état où un agent tourne toujours en arrière-plan
- Il préfère des modèles lents mais produisant des résultats de haute qualité, comme le deep mode d’Amp (basé sur GPT-5.2-Codex), qui peut prendre plus de 30 minutes
- Pour l’instant, il ne fait pas tourner plusieurs agents en parallèle, estimant qu’un bon équilibre existe entre un agent et le travail manuel
- En pratique, seuls 10 à 20 % du temps de travail correspondent actuellement à un agent tournant en arrière-plan, et il cherche encore à améliorer ce ratio
- Le but n’est pas de faire tourner un agent pour le principe, mais seulement lorsqu’il y a un travail réellement utile à lui confier ; construire des workflows de délégation de haute qualité reste important, avec ou sans IA
Situation actuelle et point de vue
- Il obtient des résultats concrets avec les outils d’IA et les aborde avec une vision équilibrée ancrée dans le réel
- Il n’a aucun lien d’emploi, d’investissement ou de conseil avec une entreprise d’IA, et sa motivation centrale reste le plaisir de construire en tant qu’artisan du logiciel, indépendamment de la survie ou non de l’IA
- Il est profondément préoccupé par le problème de formation des compétences chez les développeurs juniors ayant des bases fragiles
- Comme l’innovation sur les modèles progresse vite, il faut réévaluer en permanence ce que les agents ne savent pas faire
- L’usage ou non de l’IA relève d’un choix personnel, et ce texte a pour but de partager un cas personnel d’exploration et d’utilisation d’outils
Aucun commentaire pour le moment.