Qoder Canvas: un sistema de diseño creado para agentes, no para humanos

Pídele a un agente de codificación de IA que resuma una pull request y la respuesta llega a una ventana de chat: Markdown, bloques de código, resúmenes de diff. Esto funciona mientras la tarea es pequeña. Cuando el trabajo se complica, el texto se convierte en una búsqueda del tesoro. Los riesgos, los archivos y los siguientes pasos quedan enterrados en la respuesta, y la persona tiene que copiar fragmentos de vuelta al prompt para continuar.

El equipo de Qoder, escribiendo en la comunidad de Alibaba Cloud, tiene una respuesta concreta. En un artículo que expone el razonamiento detrás de Qoder Canvas, describen un cambio reciente: los agentes están empezando a generar resultados complejos como HTML. Dashboards, revisiones de PR, diagramas de arquitectura, informes de pruebas y hallazgos de investigación se convierten en páginas que se pueden leer, filtrar y en las que se puede hacer clic. La idea: la salida de un agente no tiene que ser texto. Puede ser un artefacto interactivo.

El HTML es demasiado libre para ser la respuesta

El HTML por sí solo no resuelve el problema, y el equipo es sincero sobre la falla. Es demasiado libre. Un agente puede inventarse colores, diseños y componentes sin esfuerzo, y cada generación corre el riesgo de convertirse en una página bonita pero aislada y puntual. La apuesta de Qoder es que el problema de la salida es en realidad un problema de diseño. Describen Canvas como un sistema de diseño para agentes de codificación, construido a partir del código base, el sistema de componentes, los design tokens y el contexto de la tarea.

El siguiente lector del sistema de diseño es una máquina

La brecha está entre un sistema de diseño escrito para humanos y uno que una máquina puede usar. Los humanos aportan mucho juicio implícito a los componentes. Los diseñadores miran Figma, los ingenieros leen la documentación de los componentes y los equipos mantienen la coherencia mediante Storybook, las APIs de componentes, las guías de diseño y los procesos de revisión. Una persona sabe qué componente encaja en cada escenario y qué props son el camino principal. Los agentes no tienen nada de eso.

Todo lo que un agente entiende de una librería de componentes proviene de lo que el código base hace legible: declaraciones de tipos, relaciones de exportación, comentarios, ejemplos, frecuencia de uso, estructura de archivos y rastros de modificaciones recientes. La calidad de la salida, sostiene el equipo, depende menos de la librería en sí que de cómo está expresada la librería en el código. Un componente expuesto como una declaración de tipo escueta solo le dice al agente que puede usarse; uno que detalla casos de uso, límites, contraejemplos y ejemplos le dice cómo debería usarse. Para un agente, un comentario en un PieChart que señala que sirve para proporciones, pero no para tendencias o rankings, que requieren un LineChart o un BarChart, es parte del sistema de diseño. Si el comentario nunca se escribió, el agente elige el gráfico equivocado.

Átomos, componentes y la capa de recetas

Qoder estructura Canvas siguiendo las líneas del Atomic Design. En la base están los átomos: design tokens para colores, tipografía, espaciado, radio de borde, sombras y semántica de estado. No tienen significado de negocio, solo primitivas visuales estables, y el agente debería tomar los valores de tokens semánticos como useHostTheme().tokens en lugar de reinventar una paleta cada vez. Por encima están los componentes base: Button, Tag, Card, Table, Input, PieChart, LineChart, FileReview y DiffGroup. Los Tags expresan estado, los gráficos expresan relaciones de datos y los diffs expresan cambios de código.

Las tareas reales de los agentes rara vez son «dibuja un componente». Se parecen más a «genera una Code Review» o «explica un test fallido». Ahí entra la capa de recetas. Un recipe.md no lista componentes; le dice al agente cómo debe organizarse la información para un tipo de tarea, dónde va la evidencia, qué acciones exponer y qué formas visuales evitar. El ejemplo del equipo: una receta de code review que exige al agente explicar primero el cambio, clasificar los problemas por riesgo, mostrar evidencia de diff para los hallazgos clave y adjuntar un AI Fix a cada problema que pueda repararse.

Canvas es un banco de trabajo, no un informe

Si Canvas solo organizara los resultados con más claridad, seguiría en el nivel de la salida. El usuario tendría que volver a Chat, volver a describir el problema, pegar el nombre del archivo y volver a explicar por qué el diff importa. El cambio real ocurre en la capa de interacción: cada nodo estructurado se convierte en un punto de entrada para la siguiente acción. Un problema en una code review de Canvas es más que una descripción de riesgo. Lleva prioridad, archivos relacionados, evidencia de diff, alcance del impacto, una estrategia de corrección recomendada y la receta de la que proviene.

Hacer clic en AI Fix no envía un simple «ayúdame a arreglar esto». Agrupa el hallazgo, los archivos relacionados, la evidencia de diff, las restricciones del sistema de diseño y los requisitos de validación de nuevo en Chat. Hacer clic en Generate Test traslada la lógica de cobertura faltante, las rutas de riesgo y las condiciones límite a la generación de tests. Esa es la línea divisoria entre Canvas y el HTML ordinario. El HTML organiza resultados. Canvas coloca resultados, contexto y próximas acciones en la misma estructura. Sin ese contexto, un botón es solo un botón; con un sistema de diseño y una receta detrás, un botón se convierte en un punto de colaboración ejecutable.

El agente ahora está dentro de la interfaz

Qoder llama a Canvas una forma temprana de UI agéntica. Las interfaces asumían que un humano opera el sistema. La era de los agentes añade un segundo actor dentro de la interfaz, uno que lee el contexto, hace sugerencias, llama herramientas y modifica archivos. Las preguntas cambian: qué está haciendo el agente, por qué, qué contexto pasa al siguiente paso, qué acciones necesitan confirmación humana y si un error puede pausarse, modificarse o revertirse.

La dirección no es exclusiva de Qoder. Cubrimos la actualización Design Mode de Cursor, que ataca el lado de entrada del mismo problema: señalar, dibujar o decir un cambio en una vista de navegador en vivo en lugar de traducir un error visual a un prompt de texto. Qoder ataca el lado de salida. Uno reduce la fricción de decirle al agente qué cambiar; el otro reduce la fricción de leer lo que produjo. Ambos asumen que la ventana de chat ya no es el contenedor adecuado para el trabajo.

Que Canvas se sostenga depende de que los equipos mantengan sus recetas honestas. Un sistema de diseño para agentes solo funciona si el código base realmente dice lo que el equipo afirma que dice. Un lector máquina no va a inferir las decisiones que nadie escribió.