La nouvelle façon de Mitchell Hashimoto d'écrire du code

Comment Mitchell Hashimoto garde un agent en action à tout moment

Mitchell Hashimoto — co-fondateur de HashiCorp, créateur de Terraform, et actuellement en train de construire Ghostty — rejoint Gergely Orosz sur The Pragmatic Engineer pour partager une méthodologie profondément réfléchie sur le développement assisté par IA. Ce n’est pas du battage médiatique ni des critiques hâtives. C’est un praticien avec 20 ans d’expérience décrivant comment il a fondamentalement restructuré son flux de travail quotidien autour d’agents IA.

La discipline fondamentale : “I endeavor to always have an agent doing something at all times. I want an agent if I’m coding, I want an agent planning. If they’re coding, I want to be reviewing. There should always be an agent doing something.” (J’m’efforce toujours d’avoir un agent qui fait quelque chose à tout moment. Je veux un agent si je code, je veux un agent qui planifie. S’ils codent, je veux être en train de réviser. Il devrait toujours y avoir un agent qui fait quelque chose.)

Avant chaque transition — quitter la maison, se rendre quelque part, arrêter sa journée — Mitchell passe 30 minutes à se demander : « Quelle est la tâche lente que mon agent pourrait faire ensuite ? » Il donne aux agents des tâches de recherche, des évaluations de bibliothèques et des analyses de cas limites qui n’ont pas besoin d’attention en temps réel. De façon critique, il désactive toutes les notifications d’agent : « Je choisis quand j’interromps l’agent. Il n’a pas le droit de m’interrompre. »

Sur ce que l’IA vous apporte réellement : “It’s really allowed me to choose what I want to actually think about. I always felt limited — I’m going to have to spend the next two hours doing this boilerplate. But now I don’t have to learn about it.” (Cela m’a vraiment permis de choisir sur quoi je veux vraiment réfléchir. J’ai toujours eu l’impression d’être limité — je vais devoir passer les deux prochaines heures à faire ce code type. Mais maintenant, je n’ai pas besoin de l’apprendre.) Ce n’est pas une question de produire plus de code. C’est une question de rediriger l’énergie cognitive vers le travail qui compte.

L’ingénierie des harnesses : la stratégie de qualité composée

La contribution la plus originale de Mitchell au discours sur le codage assisté par IA est l’ingénierie des harnesses — son terme pour construire des outils que les agents peuvent appeler pour prévenir les erreurs répétées.

Le modèle : Quand un agent commet une erreur, au lieu de simplement la corriger, construisez un harness de test, un script de validation ou une règle de linting que l’agent peut invoquer pour s’auto-vérifier. Ajoutez la règle à votre fichier CLAUDE.md ou agents.md. L’agent ne fera plus jamais cette erreur spécifique.

Cela se compose au fil du temps. Chaque session améliore le harness. Chaque amélioration du harness rend les sessions d’agent subséquentes plus fiables. Mitchell considère cela comme l’un de ses objectifs clés pour 2026 et le voit comme l’investissement en infrastructure critique pour les équipes utilisant des agents IA.

Le besoin de test élargi : L’IA est « orientée vers un objectif » — elle cassera les choses en dehors de sa portée de tâche actuelle pour atteindre son objectif immédiat. Cela signifie que la couverture de test doit être beaucoup plus extensive que ce qui était suffisant pour le développement avec humains uniquement. Chaque erreur d’IA devrait aboutir à une amélioration du harness, pas seulement à une correction.

Qualité dépendante du contexte : de zéro révision à chaque ligne

Mitchell applique des normes de qualité complètement différentes selon le projet :

• Ghostty (terminal open-source, longévité) : Révise chaque ligne de code généré par IA. La performance à 9 microsecondes par image compte.
• Projets jetables (site web de mariage familial) : Zéro révision de code. « S’est-il rendu correctement dans trois navigateurs ? Déployez-le. Il ne sera en ligne que 2 mois. »

Ce pragmatisme s’étend aux exécutions d’agents compétitives. Pour les tâches difficiles où la confiance est faible, il exécute deux agents en parallèle — Claude Code vs. Codex — et choisit le meilleur résultat. Il se décrit comme « le maire » gérant au maximum deux agents à la fois.

Pourquoi Git pourrait ne pas survivre à l’ère agentique

La prédiction la plus provocatrice : “This is the first time in like 12 to 15 years that anyone is even asking that question — will Git be around? — without laughing.” (C’est la première fois en 12 à 15 ans que quelqu’un pose cette question — Git sera-t-il encore là ? — sans rire.)

Mitchell affirme que Git et GitHub forges « ne fonctionnent pas avec l’infrastructure agentique aujourd’hui. » Quand le churn des agents est 10-100 fois supérieur au churn humain, les files de fusion deviennent impossibles, l’espace disque explose et les réviseurs humains ne peuvent pas suivre le rythme. Il conseille une startup opérant en toute discrétion spécifiquement sur ce problème.

Sa vision pour l’avenir du contrôle de version : conserver beaucoup plus de branches, d’expériences échouées et d’historique — jamais supprimer. C’est le « moment Gmail pour le contrôle de version. » Mais cela nécessite des outils fondamentalement meilleurs pour trouver un contexte pertinent dans les énormes dépôts.

Les contributions open source générées par IA détruisent le signal

Ghostty reçoit 2-3 PRs générées par IA de faible qualité quotidiennement. Mitchell les ferme maintenant sans les lire si elles n’ont pas de numéro de problème associé. “AI makes it trivial to create plausible looking but incorrect and low-quality contributions. Open source has always been a system of trust. Before we had default trust. Now it’s default deny.” (L’IA rend trivial de créer des contributions qui semblent plausibles mais qui sont incorrectes et de faible qualité. L’open source a toujours été un système de confiance. Avant, nous avions une confiance par défaut. Maintenant, c’est un refus par défaut.)

Il souhaite que les outils agentiques « fassent une pause sur l’ouverture de PRs » — la friction qu’ils causent aux mainteneurs dépasse la commodité pour les contributeurs. Il identifie même la signature de Claude : ouvrir un brouillon de PR sans corps, éditer le corps, puis le rouvrir — un modèle qu’aucun humain ne suit.

6 principes du flux de travail IA de Mitchell Hashimoto

• Toujours avoir un agent en action — Utilisez les transitions (conduire, pauses, fin de journée) pour mettre en queue des tâches d’agent lentes. Les agents ne devraient jamais être inactifs pendant les heures de travail
• Séparer la planification de l’exécution — Une étape de planification dédiée avant le codage d’agent améliore dramatiquement la qualité de la sortie
• Construire des harnesses, pas seulement des correctifs — Chaque erreur d’agent devrait produire des outils qui préviennent la récurrence, pas seulement une correction
• Choisir ce sur quoi vous réfléchissez — La valeur de l’IA n’est pas plus de code par heure mais rediriger la cognition vers l’architecture, le design et les besoins des utilisateurs
• Rigueur de révision dépendante du contexte — Le code de production reçoit une révision ligne par ligne ; les prototypes jetables reçoivent zéro révision. Adaptez l’effort aux enjeux
• Investir dans la courbe d’apprentissage — « C’est comme si quelqu’un avait essayé Git pendant une heure et avait décidé que ce n’était pas productif. Cela prend un effort soutenu pour devenir compétent »

Ce que cela signifie pour les organisations d’ingénierie

Mitchell cadre la valeur de l’IA non pas comme des gains de productivité bruts mais comme une capacité élargie à expérimenter. Les preuves de concept qui prenaient une semaine peuvent maintenant être faites en un jour. Mais il est notamment prudent : “I hesitate to say more productive. There’s an expectation they could do more. You should be able to build a full demo, design, everything — you don’t need a team to do that anymore.” (J’hésite à dire plus productif. Il y a une attente selon laquelle ils pourraient en faire plus. Vous devriez être capable de construire une démo complète, un design, tout — vous n’avez pas besoin d’une équipe pour faire ça anymore.)

Pour les organisations, les implications sont concrètes : exiger une compétence en outils IA lors de l’embauche, traiter les fichiers de configuration d’agent (CLAUDE.md) comme une infrastructure de première classe, investir dans l’ingénierie des harnesses, et accepter que les pipelines CI/CD ont besoin d’une refonte fondamentale pour gérer les tests élargis que le code généré par IA exige. Tout dans l’infrastructure d’ingénierie — éditeurs, forges, CI/CD, tests, observabilité, sandboxing — est sur la table pour changement en même temps. Comme Mitchell le dit : « C’est la première fois en ma carrière professionnelle de 20 ans que tant de choses sont sur la table pour changement en même temps. »