Pour une transition agents, investissez le temps dans le setup initial

Depuis deux semaines, sur scène et en réunion avec des dirigeants, je répète trop souvent la même chose : le travail agent se gagne sur le setup initial. En poussant les tokens à fond, j’ai vu que le coût n’est pas le prompt malin. C’est de savoir si l’environnement connaît déjà votre façon de travailler.

Je me demandais si c’était mon biais. Puis la note de Boris Cherny, lead de Claude Code, s’est alignée presque exactement.

Ce que les bons ingénieurs faisaient déjà

Boris pointe une vieille habitude : automatiser le travail autour du travail (vim, lint, e2e) pour multiplier sa sortie, avant même les agents.

L’automation se multiplie par le nombre d’agents

Un meilleur DevX accélérait une personne. La même règle partagée accélère toute la flotte.

Mettre un problème en code peut retirer une classe entière

L’agent peut re-corriger le même bug à chaque fois, brûler des tokens et rater des cas. Une règle lint ou une étape CI retire la catégorie. La « boucle », ce n’est pas le retry infini : c’est supprimer une classe de problèmes.

L’automation permet aux autres de contribuer

On voit déjà des commits le jour 1 et des non-devs au niveau d’un siège eng. Le mur restant est le savoir de domaine dans les têtes. L’onboarding doit devenir écriture : docs, règles, exemples, standards de revue.

Ce qui peut devenir infra s’est élargi

Commentaires, skills, CLAUDE.md, mémoire d’agent portent presque tout jugement énonçable. Rejeter une PR avec « on n’utilise pas ce framework » sans encoder la règle, c’est un échec d’infrastructure.

Le devoir de chaque équipe

Écrire CLAUDE.md, REVIEW.md, skills et docs jusqu’à ce qu’un agent travaille sans contexte collé à chaque tour.

Le setup initial paraît lent. Le sauter, c’est acheter des modèles chers et réexpliquer les mêmes standards à une fenêtre vide toute la journée.