Amp ouvre Portals aux machines locales : le serveur de dev s'affiche directement dans le thread

Une situation bien connue : l'agent a écrit le frontend, lancé le serveur de dev, et c'est maintenant à vous d'ouvrir un terminal, de chercher le port et de vérifier le résultat. Si l'agent tourne sur une autre machine, par exemple votre Mac à la maison, alors que vous êtes dans un café avec votre portable, la tâche tourne au casse-tête. L'équipe d'Amp, chez Sourcegraph, comble ce manque : Portals, qui ne fonctionnait jusqu'ici que dans les orbs cloud, marche désormais aussi sur votre propre runner.

Ce qui change

Un Portal est un onglet placé à côté du thread, dans lequel s'ouvre une page web créée par l'agent. Il n'était disponible que lorsque l'agent travaillait dans un orb. Le même mécanisme fonctionne désormais sur les machines locales : vous demandez à Amp de lancer un serveur de dev ou de construire un site, puis vous ouvrez le résultat dans l'onglet Portal du thread. Un détail important de l'annonce : « où que vous soyez ». Autrement dit, le runner peut se trouver sur une machine, et vous pouvez consulter le résultat depuis une autre.

L'exemple de l'annonce

Les développeurs d'Amp ont présenté un cas simple mais parlant. Dans un thread sur un runner macOS, l'utilisateur demande une page de synthèse sur l'utilisation du système de fichiers du Mac et de l'afficher dans le portal. L'agent répond par un lien vers le portal Disk Usage, et une petite application web s'ouvre à côté : 241 Go occupés sur 383 Go, une barre de capacité découpée par catégories, et un graphique en anneau montrant que les simulateurs et les données Xcode occupent 155 Go.

La valeur ne tient pas au graphique lui-même, mais à la boucle : question, code, page vivante, puis vous examinez aussitôt le résultat et précisez la demande. Les tableaux de bord internes jetables, que personne n'aurait pris la peine de coder à la main, deviennent quasi gratuits. Pour comprendre ce qui a rempli le disque, consulter des métriques de build ou vérifier une mise en page, il suffit de le demander à l'agent et d'obtenir une page plutôt qu'un pavé de texte dans le chat.

Comment l'activer et qui peut voir les portals

Il y a deux façons de faire. Dans l'application macOS, ouvrez Settings › Runner et activez Allow Portals. Si vous travaillez depuis le terminal, lancez le runner avec la commande amp --no-tui --remote-control-portals.

Par défaut, les portals de votre runner ne sont accessibles qu'à vous. Pour les montrer à vos collègues, lancez un runner partagé (shared runner) avec le drapeau --share, ou activez Share With Workspace dans l'application macOS. Tout membre du workspace pourra alors ouvrir les portals de ce runner. Les détails figurent dans la documentation d'Amp, à la section Portals on Your Runner.

Limites et conclusion pratique

Quelques points à garder en tête. L'option est désactivée par défaut, et c'est une bonne chose : c'est vous qui décidez si l'agent peut exposer des pages web depuis votre machine. Si vous activez le partage pour tout le workspace, souvenez-vous que vos collègues verront tout ce que l'agent affichera dans le portal.

Or, sur une machine locale, n'importe quoi peut se retrouver dans la page : chemins, noms de projets, données du système de fichiers. Le rapport sur le disque de l'exemple est inoffensif sur un Mac personnel, mais il ne faut pas le montrer à tout un workspace sans vérification. L'annonce ne donne aucun détail sur le fonctionnement de l'accès ni sur les limites techniques des portals ; pour les nuances, reportez-vous donc à la documentation.

La conclusion pratique est simple. Si vous utilisez déjà Amp avec un runner local, activez Allow Portals et essayez sur une tâche pour laquelle il fallait auparavant lancer un serveur à la main : prévisualisation d'un frontend, rapport sur les dépendances, tableau de bord de logs. En équipe, commencez en mode personnel et n'activez --share que pour les runners qui ne contiennent rien de sensible.

Et si vous concevez vous-même des agents, retenez cette idée. Pouvoir présenter un résultat sous forme de page vivante plutôt que de texte dans le chat est une fonctionnalité à part entière, largement sous-estimée. Elle raccourcit le chemin entre la demande et la vérification à l'œil, et c'est justement à cette étape que l'on perd d'ordinaire du temps.