Pourquoi Qoder 1.0 a renoncé à l'IDE à espace de travail unique

Les IDE traditionnels reposent sur un accord implicite : le dossier que vous ouvrez est celui où le code est écrit, et c'est celui à partir duquel vous livrez. Qoder 1.0, l'IDE d'agent de codage d'Alibaba Cloud, considère cet accord comme le bug. La publication parle à peine de la qualité des modèles. Elle parle de frontières.

Du chat au runtime de tâches

Qoder 1.0 transforme Chat en ce que l'équipe appelle un runtime de tâches agentique, en donnant à chaque tâche ses propres frontières d'espace de travail, d'exécution, d'artefacts, de livraison et de connaissances. Dans un IDE classique, ces couches pointent toutes vers un même répertoire : le dossier de la fenêtre ouverte est aussi le dossier d'exécution, le dossier d'artefacts et la racine Git unique sur laquelle Review et Commit agissent.

Cette configuration s'effondre dès lors qu'un agent entre dans la boucle, car une tâche peut s'étendre sur plusieurs états d'espace de travail. En mode Agent, les couches se chevauchent encore : le répertoire courant est aussi le répertoire d'exécution et d'artefacts. Introduisez un Worktree et elles se séparent. La tâche est créée à partir du dépôt source, l'agent s'exécute dans un worktree isolé, les fichiers et Review suivent le worktree, et la prochaine Quest repart du dépôt source.

Le gain, c'est un parallélisme sans collisions. Plusieurs Quests avancent en même temps pendant que vous inspectez la zone d'artefacts et décidez de Review, Apply ou Commit. Alibaba est direct : cela peut ressembler à la création d'un répertoire de branche de plus, mais il s'agit en réalité d'attribuer une frontière d'exécution indépendante à chaque tâche. La vue Quest à trois colonnes montre comment une tâche devient un résultat pouvant être revu et committé, et la zone de résumé et de références expose le contexte sur lequel l'agent s'est appuyé, afin que Review examine le raisonnement, et pas seulement le code.

Ce que le test A/B de mémoire a réellement mesuré

La mémoire et la connaissance du projet font partie de l'environnement d'exécution de Qoder 1.0, et non des fonctionnalités rapportées ; elles déterminent si l'agent a compris l'intention, les contraintes du projet et les conventions de l'équipe. Alibaba a mené deux évaluations, toutes deux sur des projets internes.

Le test en ligne a comparé la mémoire activée à la mémoire désactivée sur une période A/B de trois jours couvrant les cinq premières catégories, en suivant quatre métriques :

Métrique	Variation avec mémoire activée
Taux d'insatisfaction	-22.09%
Taux de rétention du code	+11.10%
Jetons d'entrée	-40.13%
Tours de conversation	-32.60%

L'évaluation hors ligne a construit des ensembles de tâches autour de la compréhension de l'architecture, du respect des conventions et de l'adaptation à la pile technologique. Les connaissances en architecture ont relevé les scores d'achèvement des tâches d'environ 25 %, tandis que la consommation de jetons a chuté d'environ 30 % ; les connaissances en pile technologique ont amélioré les scores de bout en bout d'environ 25 %, avec environ 15 % de jetons en moins.

Ce sont les chiffres d'Alibaba, mesurés sur les bases de code d'Alibaba, sans réplication indépendante pour l'instant. Considérez-les comme des indications de tendance. L'affirmation plus large est que l'enrichissement des connaissances se comporte comme une capacité d'ingénierie mesurable, plutôt que comme un artifice de prompt.

Les connaissances doivent être délimitées, pas injectées

La contrainte de conception à laquelle Qoder ne cesse de revenir est le périmètre. Les connaissances ne peuvent pas simplement être injectées dans l'agent comme un réservoir de prompts global ; sans périmètre, elles deviennent une source de pollution. Les frontières de connaissances sont donc liées à l'espace de travail : l'utilisateur, l'équipe et le dépôt dont proviennent les informations font partie du cadre de référence de la tâche.

La même conclusion apparaît ailleurs dans la conception d'agents d'entreprise : notre couverture de la délimitation dynamique des capacités des agents d'entreprise parvient à une réponse similaire via un jeu de données synthétique et une architecture d'autorisations à trois sources. Un contexte qui ne peut pas être rattaché à une frontière suscite la méfiance, ce qui est pire que l'absence totale de contexte.

L'échec qui ne se manifeste qu'au moment de la livraison

L'argument le plus clair en faveur de cette architecture est la chaîne de défaillances qu'elle prévient. Si une frontière d'exécution est instable, Apply peut écrire dans le mauvais répertoire, Reject peut restaurer les mauvais fichiers, Review peut comparer le mauvais diff, et Commit peut calculer par rapport à la mauvaise racine Git. La partie désagréable, c'est le moment où ces erreurs se produisent : elles apparaissent rarement pendant que l'agent écrit le code. Elles refont surface lorsque le travail est prêt à être livré.

Cela transforme la discipline des frontières en un problème de confiance. Des frontières stables sont ce qui rend l'exécution parallèle sûre ; sans elles, Review n'a rien de solide à juger, et déléguer la tâche est un pari. La solution consiste à stabiliser toute la chaîne : tâche créée à partir du projet source, exécution dans un environnement délimité, artefacts et diffs résolus à partir de la tâche courante, commit visant la bonne cible de livraison.

Cela correspond au positionnement de Qoder. Notre couverture précédente notait que son Repo Wiki et son indexation en arrière-plan sont conçus pour les bases de code existantes plutôt que pour les applications greenfield, et que les équipes établies perdent un travail réel lorsqu'un agent se trompe au moment de la remise. C'est aussi le champ de bataille sur lequel, selon notre couverture, l'évaluation récente de Gartner place Cursor en tête.

Le parallélisme multi-tâches n'a jamais été difficile à démontrer. La partie difficile consiste à garantir que le travail parallèle n'explose pas au moment du commit. Qoder 1.0 vend une promesse plus modeste que celle d'un meilleur code : une remise d'une sécurité ennuyeuse.