Comment l'équipe d'Anthropic elle-même utilise Claude Code (et ce que j'ai copié)

Un an après le lancement de Claude Code, la façon dont les gens qui l’ont construit s’en servent vraiment n’a rien à voir avec “tape un prompt, regarde-le écrire du code”. Les ingénieurs d’Anthropic font tourner des flottes d’agents en même temps, corrigent le système plutôt que l’instance, et font de la vérification quelque chose qu’un agent peut mener seul. Le plus intéressant n’est pas l’outil, ce sont les habitudes de travail, et la plupart se transposent directement à la manière dont nous devrions tous construire.

Je construis avec Claude Code tous les jours, le système d’outbound dont j’ai parlé et les pipelines d’agents derrière Geonimo vivent tous les deux dedans. Alors quand l’équipe d’Anthropic a partagé sa façon de travailler, j’ai été attentif à ce qui collait à ma propre expérience et à ce que je faisais encore mal. Voici les habitudes qui valent la peine d’être volées.

Arrête de corriger l’agent. Corrige le système.

L’habitude de loin la plus importante : quand Claude fait quelque chose de travers, ne te contente pas de lui dire de faire autrement cette fois-ci. Inscris la correction dans un endroit durable, une règle dans CLAUDE.md, ou une compétence réutilisable, pour qu’il ne refasse plus jamais cette erreur. Corrige l’instance et tu te répètes à l’infini ; corrige le système et l’agent se bonifie. C’est la différence entre un chatbot et un collègue.

Ça a fait tilt pour moi parce que c’est exactement ce qui a rendu mon système d’outbound efficace. Les “directives” sur lesquelles je m’appuie là-bas reposent sur la même idée : encoder le jugement une fois, puis laisser l’agent l’exécuter de façon constante. L’artefact que tu construis vraiment, ce n’est pas la sortie, c’est l’ensemble d’instructions qui produit une bonne sortie tout seul.

Laisse Claude t’interviewer

Le pire prompt, c’est “améliore-le”. Le deuxième pire, c’est celui où tu essaies de spécifier chaque détail d’emblée. À mesure que les modèles gagnent en capacité, le bon réflexe est de résister à l’envie de trop les contraindre. Tes vrais besoins sont latents : tu sais ce que tu veux quand tu le vois, mais tu es mauvais pour l’articuler à froid, exactement comme tes utilisateurs. Un modèle capable est souvent meilleur pour t’extraire ces besoins que toi pour les coucher par écrit.

Alors demande un entretien dans ton prompt. Nomme les sujets qui te tiennent à cœur, le public, les contraintes, puis demande à Claude de te questionner avant de construire. Tu obtiendras une spec qui reflète ce que tu voulais vraiment dire, pas ce que tu as réussi à taper à 9h. Pour tout ce qui est visuel, examine le résultat sous forme de page rendue et de capture d’écran plutôt qu’un mur de texte ; il est bien plus facile de réagir à quelque chose de concret que de l’imaginer à partir d’une spécification.

La vérification est le vrai déblocage (et ce ne sont pas tes tests unitaires)

Demande à une entreprise ce qu’est la vérification des agents et elle pense aussitôt aux tests unitaires, au linting, aux vérifications de types. Tout ça était déjà automatisé. La vérification qui compte pour les agents est différente : l’agent peut-il lancer la chose et confirmer qu’elle fonctionne vraiment ? C’est rarement aussi simple qu’une suite de tests, et c’est la capacité qui sépare un agent qu’il faut materner d’un agent qui peut tourner seul.

Le geste concret, c’est de rendre la vérification native à l’artefact plutôt que de la greffer dessus. L’équipe d’Anthropic construit ses applications pour que l’état d’exécution soit lisible par un agent (exposé dans le DOM, avec des fixtures, des états connus et des invariants que l’agent peut sonder), puis laisse Claude lancer les contrôles, sortir du chemin nominal, et même consigner le résultat comme preuve à partager. La leçon se généralise bien au-delà du code front-end : si tu veux qu’un agent travaille sans surveillance, donne-lui un moyen de se prouver à lui-même que le travail est correct. C’est ça, plus que la qualité brute du modèle, qui rend les agents au long cours sûrs à qui faire confiance.

Fais assez confiance à l’agent pour t’éloigner

Tu ne peux pas faire tourner plus d’un agent à la fois si tu lis chaque demande de permission. Le changement qui a débloqué les flottes, c’est le passage de “approuver chaque appel d’outil” à l’auto-acceptation, avec un modèle qui contrôle la sûreté de chaque action. De façon contre-intuitive, c’est plus sûr que l’approbation manuelle : quand tu approuves 99 % des demandes, ton regard se brouille et tu valides machinalement le 1 % dangereux. Router le contrôle vers un classifieur fait qu’on ne te sollicite que pour les appels réellement suspects.

Cette confiance gagnée change l’unité de travail. Au lieu d’un agent que tu supervises, tu en lances plusieurs, tu passes à autre chose, et tu reviens vérifier, exactement comme je fais tourner plusieurs agents sur les pipelines de Geonimo. Le goulot d’étranglement n’est plus la vitesse à laquelle tu tapes, mais la qualité de tes idées et de ta vérification.

Sois minimaliste avec le contexte

Il y a eu une saison pour le prompt engineering et une saison pour le context engineering, chacune correspondant à l’état des modèles à l’époque. Avec les modèles de frontière actuels, le conseil s’est inversé : donne le system prompt viable minimal et l’ensemble minimal d’outils, et laisse le modèle trouver le reste. Surcharger le contexte est une forme de micromanagement, ça écarte le modèle de meilleurs chemins qu’il aurait trouvés tout seul. Dis-lui seulement ce dont il a vraiment besoin, et laisse de la place à son jugement.

Ce que ça veut dire pour ta façon de construire

Mets tout ça bout à bout et le métier change de forme. Tu n’es plus la personne qui tape le code ; tu es celle qui cadre le problème, encode les règles, conçoit la vérification, et décide de ce qui vaut la peine d’être construit. Chez Anthropic, les rôles ont visiblement fusionné, designers, PM, et même les équipes finance et data science travaillent dans Claude Code, et les ingénieurs livrent des produits de bout en bout. Les équipes qui en tirent le plus traitent l’agent comme le centre du processus, pas comme un outil greffé sur le côté.

C’est le même pari que je fais dans mon propre travail : le levier, c’est d’être la personne qui a le goût produit et la propriété de bout en bout, capable de transformer une idée en système qui tourne. L’outil est remarquable, mais il récompense l’opérateur qui y apporte du jugement. Vois ce que j’ai construit de cette façon, ou la stack avec laquelle je construis.

J’utilise ces habitudes pour livrer de vrais produits avec Claude Code, des systèmes d’outbound aux pipelines LLM derrière Geonimo. Si tu veux de l’aide pour construire de cette façon, prenons contact.