Amp.

Un environnement distinct pour chaque tâche

Amp se présente comme un agent et un environnement de développement. Au lieu d'un unique dossier de travail partagé, la plateforme propose des orbs : des machines préparées pour une session précise, avec son code et ses outils. Une tâche distante peut continuer après la fermeture du portable, et vous pouvez y revenir depuis d'autres clients.

Cette approche convient aux vérifications longues ou à plusieurs modifications indépendantes. Elle exige aussi de savoir où sont stockés les fichiers, quels secrets ont été transmis et ce qui arrive lorsque la machine est arrêtée. L'absence de terminal ouvert sur votre ordinateur ne signifie pas que le processus s'est arrêté ou qu'il ne consomme plus de ressources.

Modèles et règles du projet

Amp utilise plusieurs modèles et propose des modes adaptés aux tâches. Les règles dans AGENTS.md, les skills, les plugins et MCP permettent de transmettre les conventions et les outils du projet. Une règle courte donnant le nom d'une vérification et le résultat attendu est généralement plus utile qu'une consigne générale d'éviter les erreurs.

Les systèmes connectés ne doivent pas être considérés comme un texte de référence sans conséquences. Si l'outil sait écrire dans un référentiel ou lancer un déploiement, il élargit les capacités de l'agent. Pour la nouvelle automatisation, déterminez d'abord les actions autorisées et l'artefact final vérifiable; puis décidez des informations d'identification dont elle a vraiment besoin.

Exemple : stabiliser un test

Supposons qu'un test dans le navigateur échoue parfois à attendre le chargement d'une liste. Fournissez le test initial, le message d'erreur et une contrainte : ne pas augmenter le délai d'attente sans en expliquer la cause. Demandez de reproduire le problème, de trouver un indicateur fiable que la liste est prête et d'apporter une modification minimale.

Une seule exécution réussie renseigne peu sur l'instabilité. Répétez le test plusieurs fois dans le même environnement et vérifiez qu'il détecte toujours une vraie panne. Le compte rendu devrait préciser la commande, le nombre d'exécutions et les erreurs restantes. C'est un exemple pédagogique de formulation d'une tâche, pas le résultat de notre essai d'Amp.

API et deux types de coûts

Amp possède sa propre External API dédiée aux données de l'espace de travail : fils de discussion, projets, membres et métriques. Cette interface ne lance pas l'agent et ne pilote pas les environnements orb ; pour automatiser le travail d'Amp lui-même, la documentation renvoie au CLI et au SDK. Lors de l'intégration, choisissez l'interface appropriée et vérifiez les droits des identifiants d'accès.

Le plan Hobby actuel permet d'utiliser ses propres runners, des self-hosted orbs et des jetons externes selon leurs conditions ; les orbs hébergés par Amp sont facturés séparément. Les plans payants incluent un volume d'utilisation. L'accès gratuit à la plateforme ne couvre pas le coût d'un modèle cloud utilisé avec votre clé. Avant une tâche longue, évaluez l'inference et le temps machine, puis examinez le diff final et les vérifications réellement effectuées.

Si la tâche se poursuit à distance, il est utile de déterminer un point d'arrêt clair: un changement préparé, une vérification terminée ou l'attente d'une décision humaine. Cela permet d'éviter une modification sans fin du projet, en particulier lorsque l'environnement a accès à des systèmes externes et continue de fonctionner sans client ouvert.

Pour quelles tâches convient-il

• Effectuer des tâches longues dans un environnement séparé
• Poursuivre une session sur plusieurs appareils
• Connecter les règles et outils de l'équipe
• Obtenir les données de l'espace de travail via l'API externe