Toute la discipline d'environnement que votre équipe a construite pour les humains s'applique aux agents codeurs, et la plupart des équipes l'ont discrètement abandonnée dès que l'agent est devenu bon. La même organisation qui ne laisserait jamais une nouvelle recrue approcher la production le premier jour va confier à un agent un identifiant de longue durée et une description de tâche, puis s'étonner que quelque chose de critique ait sauté.

La thèse est volontairement banale : un agent est un contributeur d'une rapidité inhabituelle mais sans jugement institutionnel, et l'échelle d'environnements existe précisément pour des contributeurs de ce genre. Développement, staging, production, avec une porte entre chaque étage. Cela n'a jamais concerné l'humain en tant que tel. Cela a toujours concerné le rayon de dégâts.

Pourquoi l'échelle a été sautée

Personne n'a décidé de la sauter. Elle s'est érodée, selon une séquence qui mérite d'être reconnue parce que votre équipe s'y trouve probablement quelque part.

L'agent commence comme de l'autocomplétion, et personne ne met l'autocomplétion en staging. Puis il se met à faire tourner la suite de tests en local, ce qui est très bien. Puis il a besoin d'atteindre un vrai service pour reproduire un bug, alors quelqu'un lui donne un accès en lecture au staging. Puis les données de staging sont périmées, alors quelqu'un le pointe vers une réplique de production. Puis une tâche a besoin d'une écriture, et l'identifiant déjà présent dans l'environnement se trouve avoir ce droit. À aucun moment personne n'a décidé que l'agent devrait pouvoir écrire en production. Il y est arrivé par une série d'étapes individuellement raisonnables, ce qui est la façon dont la plupart des incidents arrivent, partout.

Ce qu'un agent fait différemment

L'échelle compte davantage pour les agents que pour les humains, pour des raisons structurelles et non par jugement sur la compétence du modèle.

  • La vitesse supprime la pause. Un humain qui s'apprête à faire quelque chose de destructeur hésite en général d'abord. Cette hésitation est un contrôle de sécurité non écrit, et c'est une grande part de la raison pour laquelle l'échelle a tenu pour les humains malgré une application laxiste. Un agent exécute à pleine confiance en deux secondes. Il n'y a aucune pause pour l'intercepter.
  • Aucun sens des conséquences. Un ingénieur sait que telle table est la table de facturation et que le jeudi est le jour des factures. Cette connaissance n'est pas dans le dépôt, donc elle n'est pas dans le contexte de l'agent. Il connaît le schéma. Il ne connaît pas les enjeux.
  • Des objectifs littéraux. Chargé de faire passer un test d'intégration, un agent envisagera de modifier les données sur lesquelles le test fait ses assertions. C'est une solution légitime au problème énoncé. Elle n'est fausse qu'en raison d'un contexte que l'agent n'a pas.
  • Le volume. Un ingénieur ouvre trois pull requests par jour. Une flotte d'agents en ouvre trente. La probabilité par changement d'un mauvais changement peut baisser tandis que le nombre absolu de mauvais changements continue d'augmenter.

L'échelle, reformulée pour les agents

Mêmes trois échelons, avec la partie spécifique aux agents mise en avant.

  • Dev : jetable et isolé. Un agent, un espace de travail, aucun état partagé. Si deux agents travaillent dans le même checkout, ils vont se disputer les mêmes fichiers et vous passerez votre après-midi à lire un conflit de fusion que ni l'un ni l'autre ne comprend. Les branches et worktrees éphémères ne coûtent rien ; l'état mutable partagé, si.
  • Staging : forme réelle, enjeux factices. Le staging ne mérite son rôle que s'il ressemble structurellement à la production, même schéma, même topologie de services, même comportement en cas de panne, tout en ne contenant rien dont la perte compte. Des données seedées ou synthétiques, jamais une copie de production. Une réplique de production en staging, c'est de la production avec une moins bonne surveillance.
  • Production : humains et portes seulement. La sortie de l'agent atteint la production de la même façon que n'importe quel changement, via une pull request relue et votre porte de déploiement existante. Pas de porte dérobée, pas de compte de service avec une voie rapide.

L'isolation, c'est l'identifiant, pas l'URL

Voilà où les équipes se trompent elles-mêmes. Pointer l'agent vers staging.internal n'est pas de l'isolation si l'identifiant présent dans son environnement est aussi valide contre la production. La frontière d'environnement est définie par ce que l'identité peut atteindre, pas par le nom d'hôte mentionné dans la tâche. Un agent avec un rôle large est à un seul appel d'outil confus du mauvais compte, et il fera cet appel poliment et immédiatement.

La version qui tient debout est une pratique AWS banale, appliquée avec constance :

  • Des comptes séparés par environnement, de sorte qu'une erreur inter-environnements exige une assomption de rôle qui n'existe pas plutôt qu'une faute de frappe qui, elle, existe.
  • Un rôle dédié par tâche d'agent, limité aux ressources dont cette tâche a besoin, assumé pour la durée de l'exécution et pas au-delà.
  • Aucune clé de longue durée dans l'environnement de l'agent. Des identifiants de courte durée signifient qu'un contexte fuité est un problème avec une date d'expiration.
  • Refus par défaut sur les verbes destructeurs. Un agent qui n'a jamais besoin de DeleteObject devrait être structurellement incapable de l'appeler, pas simplement peu enclin à le faire.
  • Une approbation humaine sur tout ce qui traverse vers un compte contenant de vraies données, comme un contrôle que l'agent ne peut pas satisfaire seul.

Les portes de revue sont le but, pas le frein

L'objection est prévisible : cela ralentit l'agent, et tout l'attrait de l'agent, c'était la vitesse. Cette objection mérite d'être prise au sérieux, puis rejetée, parce qu'elle évalue mal l'arbitrage.

L'avantage de vitesse de l'agent est dans la génération, pas dans la vérification. Il écrit un correctif plausible en quatre-vingt-dix secondes au lieu d'une heure, ce qui est réel et considérable. La vérification n'a jamais été le goulet d'étranglement qu'il supprime. Retirer la porte de revue ne rend pas l'agent plus rapide dans ce pour quoi il est rapide, cela supprime seulement le mécanisme qui attrape les dix pour cent de sortie confiante mais fausse. Vous gardez le correctif en quatre-vingt-dix secondes. Vous gardez le relecteur. C'est tout l'arrangement, et c'est un bon arrangement.

À retenir

Rien de tout cela n'est une ingénierie nouvelle. Séparation des environnements, identifiants limités, revue avant production : votre équipe a écrit ces règles pour les humains et les suit en grande partie. L'erreur consiste à traiter un agent comme de l'outillage plutôt que comme un contributeur, parce que l'outillage n'a pas besoin d'échelle d'environnements et les contributeurs, si. Donnez à l'agent un bac à sable qui ressemble à la production et ne contient rien d'important, une identité qui expire et ne peut pas traverser la frontière, et un relecteur entre lui et le déploiement. Puis laissez-le aller vite à l'intérieur de cette boîte.

À lire ensuite

Pour les contrôles au niveau des comptes derrière tout cela, multi-party approval in AWS Organizations couvre la porte pour les opérations que rien ne devrait exécuter seul, sur ercan.cloud. Le hub est sur ercanermis.com.