La plupart des outils de codage AI sont des enveloppes: une boucle autour d'un modèle, accompagnée d'outils pour lire et écrire des fichiers ainsi que pour exécuter des commandes. Claude Code, Codex, OpenCode et Pi sont tous des enveloppes conçues pour un développeur travaillant en terminal.
Coroid n'utilise aucun d'entre eux. Il exploite son propre environnement.
Pourquoi ne pas envelopper un outil existant ?
Les outils susmentionnés sont conçus pour une session supervisée : quelqu'un observe, peut répondre à une question, interrompre le processus ou remarquer une erreur. Cette hypothèse est logique et influence tout – la manière dont les erreurs apparaissent, la quantité de contexte transmise, ou ce qui se passe lorsque le modèle renvoie une réponse inattendue.
L'hypothèse de Coroid est l'inverse : personne ne supervise le processus.. Le travail s'exécute dans le cloud, déclenché par un calendrier, un moniteur ou un événement, et doit aboutir à un résultat vérifiable ou à un échec clair sans quiconque pour intervenir en cours de route.
Il s'agit de problèmes différents. Plusieurs éléments décrits ci-dessous existent en raison de cette différence et n'auraient pas de sens dans une session terminal.
En quoi cet environnement d'exécution diffère-t-il ?
Il est conçu pour fonctionner sans supervision. Lorsque le modèle renvoie une réponse mal formée ou un appel d'outil corrompu, la boucle corrige et réessaie plutôt que d'afficher une invite à laquelle personne ne répondra. Une exécution sans surveillance qui s'arrête pour poser une question qu'elle aurait pu résoudre représente une perte de temps.
Il est multi-agents par conception. La boucle repose sur un transfert de tâche entre des rôles dotés de permissions distinctes, et non sur un seul agent effectuant toutes les tâches. La vérification est assurée par un agent qui n'a pas écrit le code, ce qui découle de l'architecture du système plutôt que d'une demande explicite.
Il dispose de budgets et de limites de profondeur explicites. Chaque exécution est soumise à un budget de jetons et à un nombre maximal d'étapes. Sans ces contraintes, un agent sans surveillance ayant mal interprété sa tâche continuerait indéfiniment.
La gouvernance est intégrée au processus d'exécution. Les politiques, les contrôles de qualité et les points de validation font partie du parcours d'exécution et non d'une couche externe ; ainsi, une étape bloquante peut interrompre le travail en cours plutôt qu'après son achèvement.
Le cache est un élément essentiel.
Le contexte représente la majeure partie du coût d'exécution des agents ; dans un environnement cloud, le même contexte de projet est lu à plusieurs reprises au cours de diverses tâches.
C'est pourquoi cet environnement d'exécution s'appuie largement sur le cache des invites. Vous pouvez observer son fonctionnement dans l' historique d'exécutiond'une tâche, où les étapes indiquent leur efficacité de cache :
9.1k used (90% cached)Un taux de réussite du cache élevé fait la différence entre une exécution coûteuse et une exécution économique. C'est aussi la raison pour laquelle un projet bien structuré avec un contexte stable coûte moins cher à manipuler qu'un projet désorganisé : un contexte stable se cache bien, tandis qu'un contexte qui change à chaque exécution ne se cache pas.
Cela s'accompagne de compétences progressives, ce qui permet de maintenir un contexte chargé à un volume réduit dès le départ.
Quelles sont les conséquences pratiques ?
- Pas d'installation locale. Pas d'interface en ligne de commande, pas de plugin d'éditeur, pas d'outil d'exécution à héberger. Coroid est basé sur API et s'exécute dans le cloud.
- Pas d'abonnements à des outils tiers. Vous n'achetez pas de licences pour un assistant de codage en complément de Coroid. L'utilisation du modèle est facturée sous forme de crédits ou via vos propres clés de fournisseur.
- Le travail s'exécute sans surveillance. Les calendriers, Sentinel et les hooks sont possibles car rien ne dépend du fait que l'ordinateur du développeur soit allumé.
- Le comportement est uniforme. Le travail de chacun s'exécute dans le même environnement avec les mêmes politiques, sans dépendre de ce que chaque développeur a installé ou configuré. Ce qui est installé est détaillé dans le support linguistique et l'environnement d'agents.
Ce qui ne change pas
L'environnement d'exécution détermine comment le travail est réalisé. Il ne modifie pas les limites : tout aboutit toujours à un pull request sur une branche, rien n'est fusionné automatiquement, et vos règles de protection de branche et de révision s'appliquent exactement comme pour les contributeurs humains.