Les équipes qui construisent avec l'IA finissent généralement par créer deux produits : l'objet qu'elles expédient et le système autour de leurs agents qui les rend utiles dans la construction de l'objet qu'ils expédient.
Nous avons construit un tel système pour nous aider à expédier Nimbalyst. Nous l’appelons notre harnais d’équipe. Cet article parle de ce que nous avons appris en le faisant.
Un harnais est la couche durable autour d'un modèle : instructions, outils, autorisations, contexte et vérification.
Claude Code et Codex sont des harnais en ce sens. Chacun enveloppe un modèle avec une invite système, une surface d'outil, un modèle d'autorisation et une boucle d'exécution. Anthropic et OpenAI possèdent cette couche.
Votre équipe possède la couche suivante : l'espace de travail dans lequel les agents travaillent à vos côtés, avec vos fichiers, tâches, diagrammes, différences et décisions. Cette couche contient les connaissances accumulées par votre équipe : comment vous construisez les choses, ce que vous avez déjà décidé, ce qui est connecté à quoi, où l'agent est autorisé à agir et comment il vérifie son propre travail.
La frontière entre le contexte et l’exploitation peut s’estomper. Un ticket ou une spécification est un contexte spécifique à une tâche, mais le mécanisme qui rend ce ticket consultable, connectable, versionné et récupérable par n'importe quel agent fait partie du harnais.
Presque rien dans un bon harnais n’est nouveau. Il s'agit principalement de pièces d'autres personnes assemblées autour de votre projet : Claude Code, Codex, MCP, Playwright, un tracker, un outil de création de diagrammes, un éditeur, un lanceur de tests, votre référentiel, vos documents. Le harnais est la manière dont ces éléments sont assemblés afin qu'un agent puisse extraire le bon contexte pour une tâche et vérifier ce qu'il a produit.
Le reste de cet article présente chaque pilier et ce que nous avons construit pour cela.
Objectif : connaître le projet.
En mode échec, cela répond : l'agent ne connaît pas votre base de code, vos règles, vos décisions ou vos conventions, il résout donc chaque problème comme il n'a jamais vu ce projet auparavant.
Le contexte désigne tout ce qui est spécifique à notre projet : code, spécifications, documents de conception, éléments de suivi, modèles de données, décisions passées, conventions, exemples et recettes.
Dans notre harnais, cela signifie :
CLAUDE.mdetAGENTS.mdcharger au début de la session et pointer l'agent vers le reste.Un code de rendu d'édition d'agent charge les règles React sans charger les règles iOS. Un agent corrigeant une régression trouve le bogue précédent, la cause première et le correctif avant d'écrire du code. Chaque session commence avec les décisions accumulées par l'équipe déjà dans la portée au lieu d'être dérivées de l'invite.
Objectif : retrouver le pourquoi.
En mode échec, cela répond : l'agent ne peut pas parcourir les liens entre les artefacts qui existent déjà, donc le raisonnement derrière chaque changement doit être réexpliqué ou redécouvert.
La provenance est la façon dont les modifications du code restent liées à l'intention qui les a produites. Un enregistrement persistant et typé de la raison pour laquelle chaque modification existe, navigable depuis n'importe quelle direction : depuis le fichier, depuis la session, depuis l'élément de suivi, depuis la validation. La structure de données sous-jacente est un graphique typé de liens entre les artefacts ; la val...
[Courte citation de 8% de l'article original]