Qoder Canvas : un système de conception conçu pour les agents, pas pour les humains

Demandez à un agent de codage IA de résumer une pull request et la réponse arrive dans une fenêtre de chat : Markdown, blocs de code, résumés de diff. Cela fonctionne tant que la tâche est petite. Dès que le travail se complique, le texte se transforme en chasse au trésor. Les risques, les fichiers et les prochaines étapes sont enfouis dans la réponse, et l'humain doit recopier des fragments dans le prompt pour continuer.

L'équipe Qoder, qui écrit sur Alibaba Cloud Community, a une réponse précise. Dans un article exposant la réflexion derrière Qoder Canvas, elle décrit une évolution récente : les agents commencent à générer des résultats complexes en HTML. Les tableaux de bord, les revues de PR, les diagrammes d'architecture, les rapports de test et les résultats de recherche deviennent des pages qui peuvent être lues, filtrées et cliquées. Le point essentiel : la sortie d'un agent n'a pas à être du texte. Elle peut être un artefact interactif.

Le HTML est trop libre pour être la réponse

Le HTML seul ne résout pas le problème, et l'équipe est franche sur ce défaut. Il est trop libre. Un agent peut inventer au hasard des couleurs, des mises en page et des composants, et chaque génération risque de devenir une page unique, belle mais isolée. Le pari de Qoder est que le problème de sortie est en réalité un problème de conception. Ils décrivent Canvas comme un système de conception pour les agents de codage, construit à partir du codebase, du système de composants, des tokens de conception et du contexte de la tâche.

Le prochain lecteur du système de conception est une machine

L'écart se situe entre un système de conception écrit pour les humains et un système qu'une machine peut utiliser. Les humains apportent beaucoup de jugement implicite aux composants. Les designers regardent Figma, les ingénieurs lisent la documentation des composants, et les équipes restent cohérentes grâce à Storybook, aux API des composants, aux directives de conception et aux processus de revue. Une personne sait quel composant convient à quel scénario et quelles props sont le chemin principal. Les agents n'ont rien de tout cela.

Tout ce qu'un agent comprend d'une bibliothèque de composants provient de ce que le codebase rend lisible : déclarations de types, relations d'export, commentaires, exemples, fréquence d'utilisation, structure des fichiers et traces de modifications récentes. La qualité de la sortie, selon l'équipe, dépend moins de la bibliothèque elle-même que de la manière dont la bibliothèque est exprimée dans le code. Un composant exposé comme une simple déclaration de type dit seulement à l'agent qu'il peut être utilisé ; un composant qui précise les cas d'usage, les limites, les contre-exemples et les exemples lui dit comment il doit être utilisé. Pour un agent, un commentaire sur un PieChart indiquant qu'il convient aux proportions mais pas aux tendances ou aux classements, qui appellent un LineChart ou un BarChart, fait partie du système de conception. Si le commentaire n'a jamais été écrit, l'agent choisit le mauvais graphique.

Atomes, composants et couche de recettes

Qoder structure Canvas selon les principes de l'Atomic Design. En bas se trouvent les atomes : des tokens de conception pour les couleurs, la typographie, l'espacement, le rayon des bordures, les ombres et la sémantique des états. Ils ne portent aucune signification métier, seulement des primitives visuelles stables, et l'agent doit tirer les valeurs de tokens sémantiques comme useHostTheme().tokens plutôt que de réinventer une palette à chaque fois. Au-dessus se trouvent les composants de base : Button, Tag, Card, Table, Input, PieChart, LineChart, FileReview et DiffGroup. Les Tags expriment l'état, les graphiques expriment les relations de données, les diffs expriment les changements de code.

Les vraies tâches d'agent sont rarement « dessine un composant ». Elles ressemblent plutôt à « génère une revue de code » ou « explique un test qui a échoué ». C'est là que la couche de recettes entre en jeu. Un recipe.md ne liste pas les composants ; il dit à l'agent comment l'information doit être organisée pour un type de tâche, où va la preuve, quelles actions exposer et quelles formes visuelles éviter. L'exemple de l'équipe : une recette de revue de code qui exige que l'agent explique d'abord le changement, classe les problèmes par risque, montre des preuves de diff pour les constats clés et attache un AI Fix à chaque problème réparable.

Canvas est un établi, pas un rapport

Si Canvas ne faisait qu'organiser les résultats plus clairement, il resterait au niveau de la sortie. L'utilisateur retournerait dans Chat, redécrirait le problème, collerait le nom du fichier, réexpliquerait pourquoi le diff compte. Le véritable changement se produit au niveau de l'interaction : chaque nœud structuré devient un point d'entrée pour l'action suivante. Un problème dans une revue de code Canvas est plus qu'une description de risque. Il porte la priorité, les fichiers associés, les preuves de diff, le périmètre d'impact, une stratégie de correction recommandée et la recette dont il provient.

Cliquer sur AI Fix n'envoie pas un simple « aide-moi à corriger ça ». Cela regroupe le constat, les fichiers associés, les preuves de diff, les contraintes du système de conception et les exigences de validation dans Chat. Cliquer sur Generate Test transmet la logique de couverture manquante, les chemins de risque et les conditions limites dans la génération de tests. C'est la ligne de démarcation entre Canvas et le HTML ordinaire. Le HTML organise les résultats. Canvas place les résultats, le contexte et les actions suivantes dans la même structure. Sans ce contexte, un bouton n'est qu'un bouton ; avec un système de conception et une recette derrière, un bouton devient un point de collaboration exécutable.

L'agent est désormais à l'intérieur de l'interface

Qoder qualifie Canvas de forme précoce d'Agentic UI. Les interfaces supposaient qu'un humain opère le système. L'ère des agents ajoute un second acteur à l'intérieur de l'interface, un acteur qui lit le contexte, fait des suggestions, appelle des outils et modifie des fichiers. Les questions changent : que fait l'agent, pourquoi, quel contexte est transmis à l'étape suivante, quelles actions nécessitent une confirmation humaine, et une erreur peut-elle être mise en pause, modifiée ou annulée ?

Cette direction n'est pas propre à Qoder. Nous avons couvert la mise à jour Design Mode de Cursor, qui attaque le côté entrée du même problème : pointer, dessiner ou énoncer un changement sur une vue navigateur en direct plutôt que de traduire un bug visuel en prompt textuel. Qoder attaque le côté sortie. L'un réduit la friction qui consiste à dire à l'agent quoi changer ; l'autre réduit la friction qui consiste à lire ce qu'il a produit. Tous deux partent du principe que la fenêtre de chat n'est plus le bon contenant pour le travail.

La viabilité de Canvas dépend de la capacité des équipes à garder leurs recettes honnêtes. Un système de conception pour agents ne fonctionne que si le codebase dit réellement ce que l'équipe prétend qu'il dit. Un lecteur machine ne déduira pas les décisions que personne n'a écrites.