Les agents de Coroid écrivent du code à la manière d'un ingénieur utilisant le shell. Il n'y a pas d'intégration spécifique par langage à attendre : si un développeur compétent peut ouvrir votre dépôt, le lire, le modifier et exécuter ses commandes, l'agent peut en faire autant.
Ce qui varie selon le langage n'est pas la capacité de Coroid à fonctionner avec lui. Il s'agit plutôt du degré d'autonomie dont dispose Coroid pour prouver les modifications apportées — naviguer dans votre code de manière sémantique, le compiler, exécuter la suite de tests, le démarrer dans un conteneur. C'est là l'essence réelle du support des langages, et il est utile de le comprendre avant de juger un résultat.
L'environnement de l'agent
Chaque tâche s'exécute dans un Espace de travail Linux propre et temporaire, construit à partir d'une image Debian, sous un utilisateur non privilégié. Rien ne persiste entre les tâches : chaque exécution démarre à partir d'un nouveau clonage sans aucun élément en cache ni pré-installé en dehors de l'image.
L'image inclut une chaîne d'outils polyvalente, donc la plupart des projets n'ont besoin d'aucune configuration supplémentaire :
| Domaine | Disponible |
|---|---|
| JavaScript / TypeScript | Node.js 22, npm, npx |
| Python | Python 3, pip, venv, Poetry, Pipenv |
| Java | JDK (headless), Maven, Gradle |
| Go | Chaîne d'outils Go |
| PHP | PHP CLI, Composer |
| Ruby | Ruby, Bundler |
| C / C++ | GCC, G++, Make, CMake |
| Navigateur | Chromium, pour les tests dans le navigateur et la vérification de l'aperçu |
| Général | git, curl, jq, ripgrep, grep, sed, awk, coreutils, client PostgreSQL |
Tout ce qui n'est pas dans cette liste — un runtime peu courant, une version spécifique de compilateur, une dépendance native — n'est pas un obstacle. C'est simplement une raison de utiliser votre propre conteneur.
Ce qui varie selon le langage
Trois aspects, classés par ordre décroissant de leur impact sur la qualité.
Serveurs de langage
Un serveur de langage offre à l'agent une compréhension sémantique : aller à la définition, trouver les références, connaître les types réels. Avec un tel serveur, l'agent peut poser des questions précises sur votre code au lieu d'en déduire les réponses à partir du texte. Sans lui, il lit simplement — ce qui fonctionne bien pour les bases de code petites et moyennes, mais devient moins fiable à mesure que la base de code grossit et devient plus complexe.
Coroid exécute des serveurs de langage pour TypeScript et JavaScript, Python, Java et C#.
Les autres langages reviennent à la méthode de lecture. C'est la plus grande différence de qualité entre les langages, et il s'agit d'une différence de degré, non de nature.
Commandes de compilation et de test
L'agent doit compiler votre projet et exécuter votre suite de tests pour vérifier son propre travail. Coroid détecte ces éléments lors de la création du Projet, et sa détection est plus efficace pour les structures conventionnelles que pour les structures inhabituelles.
Il s'agit d'une configuration, non d'une capacité — consultez la configuration de compilation et de test. Une paire de commandes correctes pour un langage peu courant vaut mieux qu'une paire incorrecte pour un langage populaire.
Conteneurs
Si votre projet peut s'exécuter dans un conteneur, Coroid peut l'utiliser comme environnement d'exécution, ce qui élimine d'un coup les divergences d'environnement et les dépendances aux services.
Lorsque votre langage ne dispose pas de serveur de langage
Les solutions pratiques, classées par ordre d'efficacité :
- Configurer explicitement les commandes de compilation et de test plutôt que de compter sur la détection. Cela compte davantage que le serveur de langage.
- Conteneuriser. Un conteneur fonctionnel comble la plupart des lacunes au niveau de l'environnement.
- Investir dans le contexte du Projet. Un bon contexte compense partiellement ce qu'aurait fourni un serveur de langage, en indiquant à l'agent des informations sur la structure qu'il devrait autrement découvrir lui-même.
Utiliser votre propre conteneur
Si votre projet se compile et se teste dans un fichier Dockerfile ou Compose qui fonctionne déjà, c'est la configuration la plus fiable dont vous disposez — meilleure que celle d'un langage bien soutenu sur l'image par défaut, car le conteneur encode précisément votre chaîne d'outils, vos versions et vos dépendances aux services.
Le test est simple : clonez votre dépôt dans un répertoire vide et exécutez install, build et test sans aucune autre configuration. Si cela fonctionne, Coroid fonctionnera également.
Registres privés et accès réseau
Les espaces de travail peuvent accéder au réseau, ce qui permet aux registres de paquets publics de fonctionner sans configuration. Les flux privés — un registre npm privé, un dépôt Maven interne ou un PyPI auto-hébergé — nécessitent des identifiants fournis dans la configuration du projet, car l'espace de travail propre ne dispose pas d'identifiants ambients à hériter.
Projets multilingues
La plupart des projets réels utilisent plus d'un langage. Un frontend TypeScript associé à un service Python est courant, et Coroid le gère sans difficulté. Le niveau de traitement dépend du langage dans lequel la modification est effectuée : une modification dans la partie bien prise en charge bénéficie d'un traitement complet, quel que soit le langage utilisé pour l'autre partie.