Mon parcours d’adoption de l’IA

• 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

[GN⁺]

Avis sur Hacker News

• La clé, c’est de découper la session en unités de travail claires et actionnables
  Si on donne des consignes trop détaillées, il n’y a plus vraiment de raison d’utiliser un LLM, et à l’inverse, si on demande quelque chose de trop vaste comme « crée-moi une app Facebook pour chiens », on n’obtient qu’un prototype inutile
  Au fond, bien exploiter un LLM pour coder consiste à trouver cette bonne échelle

  • Ce que j’aime le plus quand j’utilise des outils d’IA, c’est justement de développer cette intuition
    Comprendre quels types de tâches donnent de bons résultats et ajuster le périmètre en conséquence procure un plaisir proche de la modularisation en programmation
  • J’ai échoué en faisant une demande trop ambitieuse, comme dans l’exemple « Facebook for dogs »
    Avec Lovable, j’avais l’impression que même l’onboarding poussait vers l’échec, alors qu’avec Claude Code, en découpant le travail en petites étapes, ça s’est beaucoup mieux passé
  • Utiliser un LLM simplement pour chercher un exemple de syntaxe for est pratique, car cela réduit le changement de contexte
    Au début, je m’en servais beaucoup comme simple assistant d’écriture de code
  • À mesure que les modèles progressent, on a l’impression que la limite supérieure de cette bonne échelle monte tous les 6 à 8 semaines
  • Parfois, j’ai dit « affiche la sortie », et il a littéralement réagi en ajoutant seulement print(output)
    Le fait d’alterner entre langage naturel et code est même psychologiquement plus confortable

• 2025 a été l’année où les outils de codage IA sont vraiment entrés dans une phase pratique
  Avant, les premiers modèles comme GPT-3 ne faisaient que montrer un potentiel, ce qui a nourri à la fois un hype excessif et du scepticisme
  Mais aujourd’hui, beaucoup de développeurs intègrent réellement l’IA à leur workflow
  Si vous êtes encore sceptique, je recommande de lire l’article de Mitchell et d’essayer directement Claude Code

  • Je pense pareil. Je me demande quel moment précis on retiendra comme point de bascule dans dix ans
    À une époque, on parlait beaucoup des « limites des données », mais avec l’arrivée de Claude Code, Sonnet 4.5 et Opus 4.5, l’ambiance a complètement changé
  • Je me demande s’il y a une vraie raison d’utiliser Claude Code plutôt que Codex ou Gemini
    Les deux modèles me semblaient comparables, mais je ne l’ai pas encore essayé à cause des retours disant que les quotas d’utilisation du forfait fondent très vite avec Claude
  • Mais je reste inquiet face à une industrie toujours structurée autour du hype
    J’ai peur que les dirigeants, obsédés uniquement par la vitesse et le volume, finissent par produire des amas de code intenables

• L’approche « Don’t draw the owl » correspond aussi à mon expérience
  Le problème, c’était que les LLM dérivaient de plus en plus loin des contraintes du réel
  J’ai donc séparé les usages : le chat pour les discussions de conception, et les agents uniquement pour des diffs étroits et vérifiables
  Une fois cette boucle stabilisée, ce n’était plus un jouet mais un véritable levier, et j’ai déjà déployé plusieurs fois des fonctionnalités sur de vrais projets

  • On m’a fait remarquer que le style d’écriture de l’article ressemblait à celui d’un LLM
    C’est intéressant de voir que ce genre de structures de phrases standardisées devient aussi plus fréquent chez les humains
  • Cela me donne aussi l’impression que cette approche n’est au fond pas si différente de la manière dont on aurait toujours dû développer du logiciel

• Comme il y a de plus en plus de discussions autour d’Opus 4.5, je l’ai essayé moi-même, et j’ai senti que le paradigme des agents était devenu clairement utile
  Pour l’instant, surtout sur des tâches simples, mais c’est satisfaisant

• Les LLM ne me conviennent pas
  La capacité de réflexion et la créativité humaines sont ce qui nous distingue, et j’ai l’impression qu’en les déléguant à une machine, on s’affaiblit soi-même
  En tant que développeur Rails, j’ai essayé Zed, Claude Sonnet 4.x et Opus, mais j’ai senti que ma capacité à écrire des RSpec diminuait progressivement
  Au final, je suis revenu à neovim et je travaille sans agent
  La commodité peut au bout du compte entraîner une atrophie de la réflexion
  Les LLM sont le meilleur outil de confort jamais créé par l’être humain, mais moi, je choisis de préserver mes compétences et ma façon de penser

• Cet article paraît bien plus pratique et moins exagéré que les autres publications en une

  • Enfin un guide étape par étape que même les sceptiques peuvent essayer
    On est loin des exagérations du genre « j’ai construit un OS en vibe coding » ; ici, l’approche est réaliste

• C’est intéressant de voir que tout le monde traverse un parcours d’adoption de l’IA assez similaire
  On utilise plusieurs modèles en parallèle sur différentes parties de la codebase, et on les fait se valider mutuellement
  Je fais encore souvent des git reset, mais j’apprends peu à peu à les éviter plus efficacement
  J’ai l’impression de vivre à l’ère de l’autocomplétion du cerveau

• Quelqu’un disait qu’« un agent doit pouvoir lire des fichiers, exécuter des programmes et faire des requêtes HTTP »,
  ce qui est quasiment au même niveau que le « trio fatal » dont parle Simon Willison

  • Pour ma part, je n’ai absolument pas l’intention de faire tourner ça sur ma machine locale

• Devoir continuellement expliquer à l’agent ce qu’il doit améliorer est agaçant
  Il faut modifier agent.md à chaque fois pour lui donner du feedback, alors j’aimerais qu’il apprenne et s’améliore tout seul

  • Mais ce que quelqu’un considère comme une amélioration peut être perçu comme une mauvaise odeur de code par quelqu’un d’autre
    Ajouter quelques lignes dans AGENTS.md, ce n’est pas non plus énorme
    Si on crée une commande /fix pour qu’il corrige et documente automatiquement, on peut gagner pas mal de temps
  • Moi, au contraire, j’aime bien donner du feedback
    Ça me donne l’impression de garder la main sur l’ingénierie
    C’est particulièrement agréable pour itérer rapidement sur la recherche et l’implémentation de nouvelles fonctionnalités

• Si vous voulez voir à quoi ressemble concrètement ce genre d’approche,
  vous pouvez consulter l’ancien billet de blog de l’OP, « Non-trivial Vibing », ainsi que la discussion HN à son sujet