Amp de Sourcegraph apprend à surveiller ses propres PR : commentaires, revues et CI dans un seul fil

Amp, l'agent de codage de Sourcegraph, n'abandonne plus sa pull request dès qu'il l'a ouverte. Il s'abonne désormais aux commentaires, aux revues et aux résultats de CI portant sur le dernier commit de sa PR. Si un contrôle échoue ou si un relecteur pose une question, l'événement arrive dans le fil même où l'agent a écrit le code. Il a déjà le contexte de la tâche, inutile de lui réexpliquer quoi que ce soit. La mise à jour est sortie le 12 octobre 2026 et s'appuie sur une nouvelle intégration avec GitHub Webhooks.

Comment fonctionne l'abonnement

Amp prenait auparavant en charge, de façon plus générale, les webhooks d'événements pour les orbs (c'est ainsi qu'Amp désigne l'environnement de travail de l'agent). La nouvelle intégration GitHub fonctionne différemment : Amp reçoit lui-même toutes les requêtes entrantes de manière centralisée. Ensuite, c'est à vous ou à l'agent de décider où les transmettre : vers un orb précis ou vers un nouvel orb pour chaque événement.

L'agent peut s'abonner à certains événements, par exemple l'activité sur sa propre PR. Il peut aussi créer un abonnement qui génère de nouveaux orbs. Il n'est pas nécessaire de conserver le fil dans lequel vous avez configuré tout cela : l'abonnement vit indépendamment de lui, et Amp indique explicitement que ce fil peut être archivé.

Un nouvel orb pour chaque issue ou PR

Le second scénario vise les flux de tâches entrantes. Vous demandez à Amp de lancer un orb distinct pour chaque nouvel issue ou PR du dépôt. L'exemple donné dans l'annonce : chaque nouvel issue du dépôt acme/website. La sélection peut être restreinte à ceux ouverts avec un label donné.

Chacun de ces orbs lit son issue ou sa PR, et quand vous ouvrez le fil, un court résumé s'y trouve déjà. Les commentaires suivants arrivent dans le même fil, de sorte que la discussion ne s'éparpille pas sur plusieurs sessions.

Principaux paramètres de la mise à jour :

• trois types de signaux sur le dernier commit de la PR : commentaires, revues, CI ;
• deux modes de routage : vers un orb existant ou vers un nouvel orb pour chaque événement ;
• filtrage par label pour les orbs lancés automatiquement ;
• gestion des abonnements dans Settings → MCP & Integrations → GitHub : modification, mise en pause, liste des orbs lancés pour chaque abonnement ;
• la capture d'écran du tableau GitHub Event Subscriptions montre deux spawners d'orbs et un abonnement à une PR.

Que faire de tout cela

Il faut commencer par installer l'Amp GitHub App sur le dépôt concerné. Il suffit ensuite de demander à l'agent, dans un fil ordinaire, de s'abonner à la PR qu'il a ouverte ou de lancer des orbs sur les nouveaux issues. Le tableau des abonnements, dans les paramètres, permet de vérifier ce qui tourne et de mettre en pause ce qui est superflu.

La documentation décrit d'autres scénarios. Il est possible de surveiller la CI après un push sur main, de s'abonner à un issue ou à une PR existants, ou de demander à Puck ce qu'Amp suit actuellement.

En pratique, le gain tient au raccourcissement du cycle « PR ouverte, CI en échec, l'humain s'en aperçoit, revient vers l'agent ». L'agent réagit à une CI au rouge et aux remarques dans le contexte même où il a écrit le code. Un peu de prudence s'impose avec le spawner automatique : sur un dépôt actif, il crée un orb pour chaque issue ou PR, mieux vaut donc définir un filtre par label dès le départ. L'annonce ne précise ni les limites sur le nombre d'orbs ni les conditions de tarification : il faut consulter la documentation d'Amp.