Comment travaillent les coders

Un coder, c'est un conteneur Docker qui fait tourner un agent IA câblé avec un modèle, un ensemble d'outils (édition de fichiers, shell, git, MCP) et — pour chaque tâche qu'il prend — un clone de votre workspace. Les coders ne sont pas lancés un par tâche : ce sont des consommateurs de file mutualisés, et ARDS agrandit ou réduit le pool selon la demande.

Cycle de vie du conteneur

Les tâches s'empilent dans des files par outil de codage et par variante (standard, browser, android). ARDS compare régulièrement la profondeur de chaque file au nombre de conteneurs coder qui la consomment, et agit :

  1. Démarrage à froid — des tâches attendent et aucun conteneur ne tourne pour cette file → ARDS en démarre un. C'est pour ça que la première tâche après une période calme met un peu plus longtemps à quitter Pending.
  2. Montée en charge — le retard dépasse un seuil → un conteneur de plus rejoint le pool, jusqu'à un plafond.
  3. Travail — un conteneur prend une tâche (la tâche passe InProgress), clone votre workspace depuis le miroir de revue, et s'y met : lit des fichiers, exécute des commandes, édite, teste, itère. Tout se passe dans le conteneur — votre système de fichiers hôte et votre dépôt d'origine ne voient jamais rien. Les identifiants nécessaires (clés d'API, jetons git) sont injectés comme variables d'environnement au démarrage du conteneur.
  4. Fin de tâche — succès, échec ou annulation : le coder commite sur une branche du miroir et pousse. Tout ce qui n'a pas été commité est perdu — c'est voulu.
  5. Réutilisation — le conteneur ne meurt pas avec la tâche ; il retourne à sa file et consomme la suivante.
  6. Retour à zéro — quand une file est restée vide plusieurs minutes, ses conteneurs sont retirés. Un conteneur qui sort ou devient malsain est remplacé automatiquement tant qu'il reste du travail en file.

Un conteneur peut donc vivre une tâche ou plusieurs — mais les produits d'une tâche ne vivent qu'à condition d'avoir été commités sur le miroir. Ce point compte pour ce que les coders peuvent et ne peuvent pas faire, voir ci-dessous.

Au sein d'un workflow, le succès, l'échec ou le refus d'un coder est routé par les outcome arms (« bras d'issue ») du workflow — voir Anatomie d'un workflow.

Capacités du coder

Toutes les tâches tournent sur l'image coder standard (back-end, front-end, développement d'outils MCP — SDK .NET 10, Node.js, npm, frameworks de test courants). Ce qui varie par tâche, ce sont les capacités supplémentaires qui lui sont attachées, puisées dans des pools de capacités partagés :

  • Navigateur — un vrai Chrome pour les tests visuels, l'automatisation navigateur ou les flux E2E qui ont besoin d'un vrai DOM.
  • Émulateur — un émulateur Android pour le travail mobile.
  • Outillage Windows — un environnement Windows pour les tâches qui en demandent un.

Vous ne les choisissez pas vous-même — elles sont attachées quand la tâche le demande, et la plupart des tâches n'en ont besoin d'aucune. Si vous êtes curieux de savoir comment une tâche a tourné, le détail de la page tâche montre le fournisseur qui l'a servie, la branche sur laquelle elle a travaillé, le nombre de tours et son coût.

Ce que les coders peuvent faire

  • Lire, modifier, créer des fichiers dans le workspace cloné.
  • Exécuter n'importe quelle commande disponible dans l'image — dotnet, npm, pytest, etc.
  • Aller sur Internet pour de la doc et le téléchargement de paquets.
  • Utiliser les outils MCP (le bridge ARDS) pour consulter l'état du projet, valider le travail, etc.
  • Commiter + pousser sur le miroir.

Ce que les coders ne peuvent pas faire (ou ne feront pas)

  • Pousser sur votre dépôt d'origine. Seul le flux d'approbation propage vers l'origine.
  • Persister du travail ailleurs que sur le miroir. Seul ce qui est commité et poussé survit à une tâche ; l'état de travail du conteneur est jetable, et les conteneurs inactifs sont régulièrement retirés.
  • Voir les données d'autres tenants. Le pool de coders est par tenant ; les conteneurs d'un tenant ne servent jamais les tâches d'un autre.
  • Tenir une conversation directe avec vous. Si un coder a besoin d'une entrée, il lève une attention request visible dans le tableau de bord — il n'ouvre pas une fenêtre de chat.
  • Modifier du code hors du workspace. Les coders sont restreints à un workspace à la fois.

Où lire les logs d'un coder

Sur toute page tâche, le lien Session du codeur en haut ouvre la vue de session en direct de cette tâche — tout ce qu'a dit et fait le coder : appels d'outils, sortie du modèle, commandes lancées. Si une tâche a échoué, c'est généralement là que se trouve la cause. Les mêmes données alimentent la page Costs (comptabilité au niveau token par tâche — voir Suivre les coûts).

Pour les runs de workflow, le visualiseur de run va plus loin : la fiche de node et le panneau Session du codeur montrent le prompt effectif exactement tel que dispatché, les fichiers touchés, un diff à la demande, et des téléchargements par fichier ou en zip. Voir Suivre un run.

Combien de temps prend une tâche

Très variable. Les petits refactorings finissent en quelques minutes ; une tâche « écrire un nouveau module avec ses tests » prend 10 à 20 minutes ; une tâche « implémenter la feature X de bout en bout » peut tourner une heure ou plus. La consommation en tokens évolue grossièrement avec le temps de mur quand c'est le même modèle qui tourne.