Les garde-fous de l’agent de codage Tessl transforment les fichiers du dépôt en couche de contrôle

Tessl a publié un cadre en quatre parties pour contrôler les agents de codage à l’aide de fichiers détenus par les équipes, malgré une dépendance croissante aux modèles hébergés. Les garde-fous de l’agent de codage Tessl séparent les instructions persistantes, les règles spécifiques aux chemins, les capacités réutilisables et les hooks automatiques. Cette distinction est importante, car une demande écrite et une restriction appliquée n’offrent pas le même niveau de protection.

Le cadre utilise CLAUDE.md, .claude/rules/, des fichiers de capacités sous .claude/ et des hooks reliés à la configuration de Claude Code. Chaque couche intervient à un moment différent du flux de travail d’un agent. Ensemble, elles déplacent les connaissances opérationnelles de conversations temporaires vers des actifs versionnés du dépôt.

Le conflit central n’oppose pas Tessl à un autre outil pour développeurs. Il oppose un contexte indicatif à une application déterministe. Un modèle peut mal comprendre ou négliger un texte, tandis qu’un hook peut rejeter une action avant son exécution. Les équipes doivent désormais déterminer quelles attentes relèvent des prompts et lesquelles exigent des contrôles exécutables.

Les garde-fous de l’agent de codage Tessl répartissent un prompt en quatre couches

L’idée centrale de Tessl consiste à séparer les directives selon leur moment de chargement, ce qu’elles contrôlent et la possibilité pour l’agent de les ignorer.

Le cadre à quatre fichiers commence par CLAUDE.md. Ce fichier du dépôt fournit à Claude Code un contexte persistant sur le projet. Il peut notamment contenir les commandes de compilation, les limites architecturales, les conventions de répertoires et les attentes en matière de tests.

Cette couche doit décrire les faits dont l’agent a besoin pour de nombreuses tâches. Elle peut indiquer qu’un service utilise un gestionnaire de paquets particulier ou que les migrations de base de données sont ajoutées sans modification des précédentes. Elle peut aussi identifier les commandes permettant de vérifier qu’une modification fonctionne.

La deuxième couche place des règles ciblées dans .claude/rules/. Une règle peut inclure des modèles de chemins qui déterminent quand ses instructions entrent dans le contexte actif. Une politique de validation des API peut, par exemple, n’apparaître que lorsque l’agent touche à des gestionnaires d’API.

Le ciblage par chemin répond à un problème concret posé par les gros fichiers d’instructions. Un agent qui travaille sur la documentation n’a pas besoin de toutes les conventions du backend dans son contexte. Charger des éléments non pertinents consomme des tokens et entre en concurrence avec les instructions utiles à la tâche en cours.

La troisième couche stocke des capacités réutilisables sous .claude/. Les compétences sont des dossiers contenant un fichier SKILL.md, des instructions, des scripts et des ressources associées. Elles regroupent une procédure que l’agent ou le développeur peut invoquer lorsqu’elle est pertinente.

Une checklist de publication illustre cette différence. La vue d’ensemble du dépôt peut expliquer le fonctionnement des publications, mais la séquence complète a sa place dans une compétence de publication. Cela évite d’encombrer les sessions de codage ordinaires avec une procédure plus longue.

La quatrième couche utilise des hooks pour les actions devant se déclencher lors d’événements définis du cycle de vie. Les hooks peuvent inspecter des appels d’outils proposés, lancer des formateurs après des modifications ou arrêter des commandes dangereuses. Leur configuration se trouve normalement dans les paramètres ou dans des fichiers de projet associés.

Cette séparation change le sens même des « instructions d’agent ». Les fichiers ne forment plus un grand prompt demandant au modèle de tout retenir. Ils deviennent des contrôles distincts, avec des comportements de chargement et d’application différents.

Les propres conseils de pilotage d’Anthropic soutiennent cette répartition. Ils distinguent le contexte toujours chargé, les règles ciblées par chemin, les procédures à la demande, les sous-agents isolés et l’automatisation du cycle de vie.

Tessl resserre cet éventail plus large autour d’un argument de propriété du dépôt. Le fournisseur du modèle continue d’exploiter le modèle et l’environnement d’exécution de l’agent. L’équipe de développement possède les fichiers qui décrivent le comportement attendu de l’agent dans son codebase.

Cette propriété rend la couche de contrôle inspectable. Une équipe peut examiner les modifications via des pull requests, comparer les versions, attribuer des responsables et annuler une règle nuisible. L’historique des discussions offre rarement la même clarté opérationnelle.

Les fichiers peuvent aussi voyager avec le projet. Un nouveau contributeur reçoit les conventions partagées lorsqu’il clone le dépôt. Une nouvelle session d’agent peut retrouver les mêmes instructions sans dépendre de la conversation antérieure d’une autre personne.

Le cadre n’élimine pas l’incertitude des modèles. Il organise cette incertitude en couches que les équipes peuvent tester indépendamment. C’est là le changement le plus important.

La pression s’accentue sur les équipes qui traitent CLAUDE.md comme un moteur de politiques

Un long fichier d’instructions peut guider un agent, mais il ne peut pas servir de manière fiable de système de contrôle d’accès.

De nombreuses équipes commencent avec un seul CLAUDE.md, car il apporte des améliorations immédiates. L’agent cesse de deviner les commandes courantes, suit les conventions de nommage établies et obtient une carte élémentaire du dépôt. Ces avantages rendent le fichier facile à étendre à l’excès.

Le problème apparaît lorsque chaque exception devient un paragraphe supplémentaire. Les exigences de sécurité, les procédures de publication, les conventions frontend, les restrictions sur les bases de données et les préférences personnelles s’accumulent dans le même document. Chaque session en paie alors le coût en contexte.

Anthropic recommande de considérer le fichier racine comme une vue d’ensemble ou un index. Ses conseils actuels suggèrent de maintenir CLAUDE.md sous les 200 lignes, de lui attribuer un responsable et d’examiner les modifications comme du code. Cette recommandation reflète un problème d’attention, et pas seulement une préférence de mise en forme.

Chaque instruction toujours chargée entre en concurrence avec les fichiers source, les détails de la tâche, la sortie des outils et la conversation récente. Davantage de directives ne garantit pas une meilleure conformité. Un prompt encombré peut rendre l’exigence pertinente plus difficile à identifier.

Les fichiers d’instructions imbriqués permettent de localiser une partie de ces connaissances. D’après la documentation officielle sur la mémoire de projet, les fichiers situés sous le répertoire de travail peuvent se charger lorsque Claude accède à cette partie de l’arborescence. Cela prend en charge des conventions propres à chaque équipe au sein d’un monorepo.

Les règles ciblées par chemin offrent une option plus directe pour les préoccupations transversales. Une règle peut viser plusieurs modèles de fichiers sans dupliquer les instructions dans plusieurs répertoires. Elle peut couvrir tous les fichiers de migration ou chaque gestionnaire d’API réparti entre différents packages.

Cette distinction pousse les responsables de l’ingénierie à classer leurs exigences. Une convention de codage relève du contexte, car le jugement reste utile. Un flux de travail répétable relève d’une compétence, car il nécessite des étapes ordonnées. Une commande interdite exige une barrière plus robuste.

Sans cette classification, CLAUDE.md devient une base de données informelle de politiques. Les développeurs peuvent supposer qu’écrire « ne jamais modifier la configuration de production » crée une limite fiable. Ce n’est pas le cas.

Un agent interprète le texte dans un contexte changeant. Les longues sessions, les instructions ambiguës, les fichiers contradictoires et l’injection de prompt peuvent affaiblir le respect des consignes. Même un modèle performant peut porter un mauvais jugement dans ces conditions.

Cette limite affecte également les audits. Un examinateur peut confirmer qu’une phrase existe, mais ne peut pas en déduire son véritable taux d’application. La règle peut se charger correctement et néanmoins céder face à une instruction plus immédiate.

Les équipes qui adoptent des flux de travail autonomes ou non supervisés subissent la pression la plus forte. Une convention manquée durant un codage supervisé crée du travail de révision. Une restriction de sécurité ignorée pendant une exécution non supervisée peut modifier des fichiers, exposer des données ou lancer une commande indésirable.

Le cadre demande donc aux équipes de cesser de mesurer la gouvernance à la taille des documents. La meilleure question est de savoir si chaque exigence atteint l’agent au bon moment avec une autorité suffisante.

Cette question dépasse Claude Code. D’autres agents de codage prennent en charge des fichiers d’instructions de dépôt, des flux de travail réutilisables ou des contrôles fondés sur des événements, sous des noms différents. Les chemins précis varient, mais le problème de conception reste le même.

Un dépôt a besoin d’un contexte concis, de procédures sélectives, de permissions limitées et de limites applicables. Réunir ces fonctions dans un seul prompt masque leurs différences.

Les instructions indicatives et les hooks déterministes ne sont pas équivalents

La limite décisive est de savoir si le modèle choisit de se conformer ou si l’environnement d’exécution bloque la non-conformité.

Une déclaration dans CLAUDE.md influence la prochaine décision du modèle. Un fichier de règles fait de même avec un meilleur ciblage. Une compétence fournit une procédure réutilisable, mais l’agent interprète et exécute toujours cette procédure.

Les hooks opèrent à un autre niveau. Claude Code les déclenche lorsque des événements définis se produisent, comme une demande d’outil, une modification de fichier, le démarrage d’une session ou une tentative de finalisation. L’environnement d’exécution lance le hook au lieu d’attendre que le modèle s’en souvienne.

Un hook PreToolUse peut inspecter une commande proposée avant son exécution. Si la commande enfreint une politique, un hook de commande peut renvoyer un résultat bloquant. L’agent reçoit alors la raison et doit choisir une autre voie.

Le guide officiel des hooks décrit plusieurs types de gestionnaires. Les gestionnaires de commandes exécutent des scripts, tandis que les gestionnaires de prompts et d’agents reposent sur le jugement du modèle. Cette distinction est importante, car tous les hooks ne sont pas entièrement déterministes.

Un hook qui se lance systématiquement est déterministe au niveau du déclenchement. Sa décision peut toutefois rester probabiliste si un LLM évalue la demande. Les équipes devraient réserver les vérifications basées sur des commandes aux conditions que les logiciels peuvent évaluer directement.

Prenons un dépôt qui interdit les modifications de fichiers générés. Une instruction en langage naturel demande à l’agent de les éviter. Une règle de chemin répète cette attente lorsque les fichiers concernés apparaissent. Un hook peut inspecter la cible d’écriture et rejeter l’opération.

Ces couches peuvent fonctionner ensemble. L’instruction explique la conception du dépôt, tandis que le hook empêche un mode de défaillance connu. L’agent reçoit à la fois le contexte et une limite applicable.

Le même schéma s’applique aux commandes. Une équipe peut décrire son processus de déploiement dans une compétence, puis bloquer les commandes directes en production au moyen de permissions ou de hooks. La compétence fournit le parcours approuvé, tandis que le contrôle empêche les raccourcis.

Les hooks post-modification ont un objectif différent. Ils peuvent lancer le formatage, le linting ou une validation ciblée après qu’un agent a modifié un fichier. Cette automatisation réduit la dépendance au fait que l’agent se souvienne d’un élément supplémentaire de la checklist.

Les hooks de finalisation peuvent vérifier que les contrôles requis ont réussi avant que l’agent s’arrête. Ils nécessitent toutefois une protection contre les boucles. Un hook d’arrêt défaillant qui demande continuellement à l’agent de poursuivre peut consommer du temps sans améliorer le résultat.

Les hooks introduisent aussi du code exécutable dans le plan de contrôle. Un script défectueux peut bloquer un travail légitime, divulguer des informations ou ajouter de la latence à chaque événement correspondant. Les équipes doivent examiner les modifications de hooks avec le même soin que l’automatisation de compilation et de déploiement.

La propriété ne crée pas automatiquement de sécurité. Un dépôt malveillant peut contenir une configuration demandant un comportement dangereux. Les développeurs ont toujours besoin de confiance dans l’espace de travail, de permissions restrictives, de revue de code et d’une exécution isolée pour les projets inconnus.

L’expression « fichiers que vous possédez » a donc deux sens. Elle décrit la portabilité et la gouvernance, mais elle attribue aussi une responsabilité. L’équipe doit maintenir ces fichiers, tester leurs effets et les protéger contre toute modification non autorisée.

C’est pourquoi les permissions restent importantes. Les contrôles de permissions d’Anthropic prennent en charge des règles d’autorisation et de refus pour les outils et les commandes. Les règles de refus prévalent sur les règles d’autorisation correspondantes.

Les hooks peuvent évaluer des conditions plus riches, tandis que les permissions fournissent une limite d’accès plus directe. Aucun des deux ne doit se substituer à l’isolation du système d’exploitation lorsque les conséquences sont graves.

Les conteneurs, les identifiants restreints, les protections de branche et les montages en lecture seule restent des contrôles plus robustes. Les fichiers du dépôt s’inscrivent dans ce système de défense plus large. Ils doivent réduire les risques sans prétendre remplacer la sécurité de l’infrastructure.

L’idée essentielle est simple. Si une exigence indique « préférer », elle peut rester une recommandation. Si elle dit « ne doit jamais », l’équipe doit rechercher un contrôle applicable de manière contraignante.

Les compétences transforment le travail répétitif des agents en actifs de dépôt vérifiables

Les compétences importent parce qu’elles transforment des habitudes de prompting temporaires en procédures que les équipes peuvent inspecter, tester et réutiliser.

Un développeur découvre souvent un workflow d’agent utile par essais et erreurs. Le prompt final peut inclure des commandes de diagnostic, des critères de décision, des exigences de formatage et des étapes de vérification. Sans fichier partagé, ce savoir disparaît dans une seule conversation.

Une compétence préserve le workflow dans un répertoire nommé. Son fichier SKILL.md contient des métadonnées et des instructions, tandis que des scripts ou références adjacents soutiennent la procédure. Le dépôt peut versionner l’ensemble du package.

Claude Code ne charge initialement que le nom et la description d’une compétence. Son contenu complet entre dans le contexte lorsque la compétence devient pertinente ou que quelqu’un l’invoque. La documentation officielle des compétences présente ce comportement comme une alternative au placement de longues procédures dans CLAUDE.md.

Ce modèle de chargement crée un avantage économique. Des procédures détaillées de publication, de migration, de revue et de gestion d’incident peuvent rester disponibles sans alourdir chaque session. Le contexte devient conditionnel plutôt que permanent.

Il améliore également la découvrabilité. Un nouvel ingénieur peut inspecter le répertoire des compétences et voir quels workflows l’équipe a formalisés. Les fichiers révèlent ce que l’organisation attend des humains comme des agents.

La vérifiabilité est tout aussi importante. Un prompt modifié dans une conversation est difficile à auditer. Une compétence modifiée produit un diff. Les relecteurs peuvent identifier une vérification de sécurité supprimée ou une commande ajoutée avant son adoption courante.

Les compétences peuvent inclure des scripts pour les sous-tâches déterministes. Une compétence de migration peut appeler un validateur détenu par le dépôt plutôt que demander au modèle de reproduire la logique de validation. L’agent gère le jugement, tandis que le code gère les calculs reproductibles.

Cependant, une compétence reste avant tout une procédure. Sa présence ne prouve pas que l’agent l’invoquera au bon moment. Les descriptions doivent indiquer clairement quand la compétence s’applique, et les équipes ont besoin de tests qui exercent le comportement de déclenchement.

L’invocation manuelle peut réduire l’ambiguïté pour les opérations sensibles. Un développeur peut demander explicitement une revue de publication au lieu de dépendre d’une correspondance automatique. La compétence fournit alors un workflow cohérent.

Les capacités créent aussi des obligations de maintenance. Les procédures deviennent obsolètes lorsque les noms de commandes, les architectures ou les systèmes de déploiement changent. Une compétence fiable nécessite un responsable, des exemples et un cycle de revue.

Les équipes doivent surveiller les doublons d’autorité. Si la même exigence apparaît dans CLAUDE.md, trois règles et deux compétences, des modifications ultérieures peuvent créer des contradictions. L’agent reçoit alors plusieurs versions de la prétendue vérité.

Une meilleure organisation attribue à chaque fait un emplacement principal unique. Le fichier racine peut pointer vers une capacité sans recopier son contenu intégral. Les règles de chemin peuvent ajouter des contraintes locales, tandis que les compétences prennent en charge les procédures à plusieurs étapes.

Cela ressemble à la conception logicielle classique. De petits modules aux responsabilités claires restent plus faciles à modifier qu’un unique objet global de configuration. La couche de contrôle des agents bénéficie de la même séparation.

Cette approche peut aussi préserver le savoir organisationnel. La récupération après échec de build, les mises à niveau de dépendances et les revues de sécurité dépendent souvent de quelques ingénieurs expérimentés. Encoder ces workflows rend ce savoir disponible lors de sessions futures.

Ce lien est particulièrement pertinent lorsque les preuves techniques sont dispersées dans plusieurs documents. Une base de connaissances d’ingénierie consultable peut soutenir les sources, tandis que les compétences définissent la manière dont les agents les utilisent.

Les deux systèmes résolvent des problèmes différents. Le stockage de connaissances préserve les faits et les décisions. Les compétences transforment des connaissances sélectionnées en procédure opérationnelle.

L’avantage pratique n’est pas que l’agent devienne soudainement infaillible. Il réside dans la possibilité pour l’équipe d’inspecter la procédure qu’elle attend de l’agent qu’il suive.

La propriété des fichiers ne comble pas le déficit de sécurité

Les garde-fous contrôlés par le dépôt améliorent la responsabilisation, mais restent vulnérables aux conflits, aux altérations et à une application incomplète.

La première incertitude concerne la priorité des instructions. Un projet peut contenir des consignes racines, des consignes imbriquées, des règles de chemin, des instructions de compétence, des préférences utilisateur et des paramètres organisationnels gérés. Ces couches peuvent diverger.

Une équipe peut croire que son dépôt exprime une politique unique alors que la configuration personnelle d’un développeur modifie le comportement. Le problème inverse peut également survenir. Une politique centrale peut empêcher un workflow local attendu par le dépôt.

La visibilité de la configuration est donc essentielle. Les développeurs doivent pouvoir voir quels fichiers ont été chargés, quelles règles ont correspondu et quelles autorisations ont influencé une décision. Sans cela, les échecs paraissent aléatoires.

La deuxième incertitude concerne la mutabilité. Si un agent peut modifier les fichiers qui le contraignent, le plan de contrôle partage la même frontière de confiance que le code ordinaire. Une tâche peut affaiblir accidentellement une règle en modifiant une configuration voisine.

Les contrôles critiques doivent bénéficier d’une protection plus forte. La propriété du code, les revues obligatoires, les branches protégées et les environnements d’exécution en lecture seule peuvent rendre les changements non autorisés plus difficiles. Les hooks sensibles ne doivent pas dépendre de la bonne volonté de l’agent.

La troisième incertitude est la portabilité. CLAUDE.md bénéficie d’une large reconnaissance, mais les répertoires dédiés aux règles, compétences, agents et hooks restent spécifiques aux outils. Un dépôt prenant en charge plusieurs agents de programmation peut accumuler des configurations parallèles.

Tessl a intérêt à réduire cette fragmentation, car son produit gère des contextes et spécifications d’agents réutilisables. Son cadre reflète donc à la fois un modèle de conception général et un environnement d’outillage particulier.

Les équipes doivent séparer ces deux affirmations. Le modèle en couches est utile pour l’ensemble des agents de programmation. Les chemins de fichiers exacts et le comportement de chargement doivent néanmoins être vérifiés dans chaque environnement d’exécution.

La quatrième incertitude concerne le faux sentiment de sécurité. Un hook peut bloquer un modèle de commande connu tout en manquant une action équivalente. Une règle d’interdiction visant une commande shell ne couvre pas nécessairement un script, une tâche de package ou un outil externe produisant le même effet.

Les contrôles nécessitent des tests adversariaux. Les équipes doivent tenter des opérations interdites avec une syntaxe alternative, des scripts indirects et différents outils. Un garde-fou qui ne réussit que son exemple d’origine reste fragile.

Le travail légitime doit également être testé. Un blocage trop large peut empêcher des commandes inoffensives ou interrompre des workflows courants. Les développeurs peuvent alors demander des exceptions, contourner le contrôle ou le désactiver entièrement.

La latence crée un autre compromis. Un formateur après chaque modification peut être acceptable, alors qu’une suite complète de tests après chaque changement de fichier peut rendre l’agent inutilisable. Les contrôles doivent correspondre au coût et à la conséquence de l’événement.

Les vérifications rapides doivent être proches de chaque modification. Une validation plus vaste peut s’exécuter avant les commits ou la finalisation. Une analyse de sécurité coûteuse peut relever d’une compétence dédiée, d’un job d’intégration continue ou d’un agent de revue isolé.

L’injection de prompt reste une préoccupation sérieuse. Un agent peut lire du texte non fiable issu de tickets, de documentation, d’artefacts générés ou de contenus de dépendances. Des instructions malveillantes intégrées à ces entrées peuvent entrer en conflit avec les consignes du dépôt.

Des autorisations déterministes et une exécution isolée réduisent les dommages possibles. Les instructions de prompt seules ne peuvent pas établir une frontière de sécurité, car le même modèle interprète à la fois du texte fiable et non fiable.

La lecture la plus sûre de la proposition de Tessl est donc plus limitée que son titre ne le suggère. Les fichiers peuvent créer une couche de contrôle maintenable. Ils ne peuvent pas garantir à eux seuls une autonomie sûre.

Trois signaux montreront si le cadre tient la route

Le prochain test consiste à déterminer si les équipes peuvent mesurer l’adhésion, la portabilité et l’application des règles, plutôt que de simplement accumuler des fichiers de configuration.

Le premier signal est l’amélioration des outils d’évaluation pour les instructions de dépôt. Les équipes ont besoin de tâches reproductibles révélant si un agent a suivi une règle, invoqué la bonne compétence et respecté une limite.

Une évaluation utile doit partir d’un environnement propre. Elle doit présenter la même tâche sur plusieurs exécutions, enregistrer la configuration chargée et comparer les actions résultantes. Cela révélerait les défaillances probabilistes masquées par une seule démonstration réussie.

Si l’évaluation devient routinière, l’argument de Tessl sur la propriété gagne en force. Les fichiers du dépôt se comporteraient davantage comme des actifs logiciels testables. Si les équipes ne peuvent pas mesurer les résultats, le cadre risque de devenir de la documentation de prompts aux effets incertains.

Le deuxième signal est une convergence autour de formats de capacités portables. Les compétences ressemblent déjà à une norme de packaging inter-outils, car elles combinent métadonnées, instructions et fichiers de soutien. Les règles et les hooks restent moins cohérents.

La portabilité réduirait la maintenance dupliquée entre Claude Code, Codex, Cursor et d’autres agents. Elle permettrait également aux organisations de revoir une définition de contrôle unique plutôt que de rapprocher plusieurs quasi-copies.

Cependant, une portabilité superficielle ne suffit pas. Un format de fichier partagé doit préserver les sémantiques de déclenchement, d’autorisations, de correspondance de chemin et d’application des règles. Un Markdown identique ne garantit pas un comportement identique.

Si les fournisseurs d’agents publient des règles précises de chargement et de priorité, le cadre devient plus facile à approuver. Si chaque environnement d’exécution interprète silencieusement les mêmes fichiers différemment, la propriété du dépôt ne résoudra pas l’ambiguïté opérationnelle.

Le troisième signal est une séparation plus forte entre les recommandations et les politiques strictes. Anthropic distingue déjà les instructions destinées au modèle des hooks, autorisations, paramètres gérés et mécanismes d’isolation système. Les équipes ont maintenant besoin d’outils rendant cette distinction visible.

Une interface de politique devrait identifier quels contrôles sont consultatifs, lesquels se déclenchent systématiquement et lesquels bloquent réellement des actions. Les journaux d’audit devraient indiquer pourquoi une commande a été autorisée ou refusée.

Ce signal renforcera le cadre si les développeurs peuvent relier chaque restriction importante à une couche applicable de manière contraignante. Il l’affaiblira si des politiques sensibles restent enfouies dans du texte.

L’action immédiate des équipes d’ingénierie n’est pas de créer les quatre couches d’un coup. Elles doivent inventorier leurs instructions existantes et classer chaque énoncé selon sa fonction.

Les faits du projet et les commandes courantes appartiennent à un contexte persistant concis. Les conventions spécifiques aux fichiers appartiennent à des règles ciblées. Les procédures répétées appartiennent aux compétences. Les actions interdites appartiennent aux autorisations, hooks ou contrôles système plus robustes.

Cette classification fournit un test pratique pour les garde-fous des agents de programmation de Tessl. Un autre ingénieur peut-il inspecter le dépôt et expliquer ce qui guide l’agent, ce qui s’active à la demande et ce qui ne peut pas être contourné ?

Si la réponse n’est pas claire, le dépôt ne possède pas encore de couche de contrôle. Il possède une collection de prompts. Cette distinction déterminera si les agents de programmation deviennent des collaborateurs fiables ou simplement des sources plus rapides de travail de revue.