Canvases: la interfaz se construye con lenguaje natural
GitHub ha introducido en la aplicación de Copilot una funcionalidad denominada «canvases» —también conocida como canvas extension—, una superficie de interfaz que se genera a partir de una descripción en lenguaje natural y que puede ser utilizada tanto por el usuario como por el agente de forma bidireccional. El flujo es directo: en una sesión de agente se ejecuta el comando /create-canvas y se describe el flujo de trabajo deseado. La descripción debe cubrir tres aspectos: qué flujo debe soportar el canvas, qué acciones puede realizar el usuario y qué acciones puede ejecutar el agente. Por ejemplo, es posible solicitar un canvas para registrar notas de lanzamiento que se actualicen automáticamente según el trabajo completado en las sesiones de Copilot, con controles para revisar, organizar entradas y permitir que el agente las añada y modifique. La interfaz resultante se abre en el panel lateral derecho sin necesidad de escribir archivos ni configurar maquetaciones.
Lo que diferencia a los canvases de otras herramientas de automatización es su carácter compartimentado e interactivo. Cuando el usuario hace clic en un botón, actualiza un campo o arrastra una tarjeta, el estado compartido del canvas cambia de forma inmediata y el agente lo percibe sin requerir un paso adicional de sincronización. Esto permite una colaboración en tiempo real, similar a trabajar sobre una pizarra compartida: ambos actores pueden modificar la interfaz simultáneamente y ver los cambios al instante. Los canvases pueden guardarse como extensiones, ya sea vinculados a un repositorio para compartirlos con el equipo o como extensiones personales. Además, la comunidad ha publicado a través de Awesome Copilot plantillas de canvas listas para instalar, que abarcan tableros kanban, flujos de triaje de problemas, paneles de control y hojas de cálculo.
De la descripción al prototipo funcional
La primera versión de un canvas es solo un punto de partida. GitHub indica que no existe un menú fijo de maquetaciones: si se puede describir un flujo de trabajo, se puede convertir en un canvas. El usuario puede seguir refinando la descripción —añadir columnas, filtrar pull requests abiertos, transformar toda la extensión en una lista de tareas diarias— y el agente actualizará el canvas conforme a las instrucciones. El proceso elimina la fricción entre definir un flujo y construir la herramienta que lo soporta, ya que la configuración manual de componentes de interfaz queda sustituida por iteraciones de texto. La premisa básica para crear un canvas útil se reduce a responder tres preguntas: qué información se quiere ver, qué elementos se pueden modificar directamente y qué acciones puede realizar el agente.
Superficie de diff revisada desde cero
Paralelamente, el equipo de ingeniería de GitHub ha reconstruido la superficie de diff de la aplicación de Copilot para garantizar que la experiencia de revisión se mantenga fluida cuando el tamaño del cambio es extremo. Las refactorizaciones amplias y las migraciones de código a menudo deben consolidarse en un único pull request; las pilas de pull requests son una alternativa para dividir el trabajo, pero existen cambios que no se pueden fragmentar de forma limpia. La consecuencia es un único cambio que puede superar ampliamente el millón de líneas modificadas y acompañarse de cientos de comentarios integrados de revisión.
El principal escollo técnico radica en los comentarios, no en las líneas de código. Una línea de código tiene una altura conocida y predecible, pero la altura de un comentario depende de factores que solo se resuelven en el tiempo de renderizado: el ajuste de línea del markdown, los bloques expandibles, el cuadro de respuesta que crece mientras se escribe, los diffs de cambios sugeridos, las reacciones, los banners de resolución y las imágenes que cargan de forma asíncrona. Esto rompe la técnica estándar de virtualización —montar solo las filas visibles y reciclar los nodos DOM—, que funciona bien cuando todas las alturas se conocen de antemano.
Para resolverlo, el equipo optó por separar la geometría del documento en dos dominios independientes. La geometría del código se mantiene determinista y exacta, calculada de forma previa al pintado y nunca reconstruida cuando un comentario cambia de tamaño. La geometría dinámica, en cambio, cubre todo aquello cuya altura no puede predecirse —hilos de revisión, borradores, compositores de respuesta— y se basa en bloques identificados por su clave estable en lugar de por su posición en píxeles. Cada bloque se ancla a un archivo, una línea y un lateral del diff, de modo que un reflujo del contenido no pierde el rastro. Las correcciones de altura se miden de forma diferida y se mantienen acotadas al bloque que está mirando el usuario, evitando los saltos de desplazamiento que romperían la fluidez al subir o bajar por un documento enorme. En la práctica, el resultado es que un pull request de 2.200 archivos, más de un millón de líneas cambiadas y más de 400 comentarios integrados de revisión se muestra de forma interactiva sin colapsar el rendimiento del navegador.
SDK de Copilot para Java
GitHub ha publicado un SDK de Copilot para Java, dirigido expresamente a desarrolladores que trabajan en entornos empresariales. El objetivo es que los equipos puedan controlar Copilot desde código idiomático, aprovechando características propias del lenguaje como anotaciones y hilos virtuales, sin depender de integraciones generales o scripts externos. El SDK permite incrustar capacidades de agente dentro de aplicaciones Java existentes, lo que abre la puerta a flujos de trabajo automatizados que respondan a eventos del sistema, gestionen tareas programadas o interactúen con repositorios de forma controlada.
Hasta ahora, la personalización de Copilot para escenarios empresariales dependía en buena medida de extensiones genéricas o de la composición de llamadas a la API subyacente. El SDK para Java consolida ese control en una abstracción propia del lenguaje, lo que facilita la testabilidad, la integración con stacks corporativos y la adopción por equipos que ya operan con Java como lenguaje principal. La publicación coincide con la tendencia de GitHub a ofrecer SDKs por lenguaje que permitan a las organizaciones adaptar Copilot a sus flujos específicos sin salir del ecosistema que ya utilizan.
Migración del tiempo de ejecución a Rust
Uno de los anuncios de mayor calado técnico es la reescritura completa del tiempo de ejecución (runtime) de GitHub Copilot en Rust. Según los datos publicados por el propio blog de GitHub, la migración implica aproximadamente 800.000 líneas de código de producción. El proyecto no solo busca mejorar el rendimiento, sino también reforzar la seguridad de memoria y reducir la huella de recursos del servicio que atiende a millones de desarrolladores.
Un detalle relevante es que la propia migración se ha apoyado en el agente Copilot durante el proceso: el equipo ha utilizado la herramienta para asistir en la traducción del código, la revisión de cambios y la detección de problemas, lo que constituye un ejemplo de retroalimentación entre el producto y su infraestructura interna. Si bien no se especifica una fecha concreta de disponibilidad completa en producción para todas las regiones ni se detalla si alguna funcionalidad permanece en fase de transición, el anuncio confirma que el tiempo de ejecución ya opera bajo la nueva base en Rust.
Qué cambia para los usuarios
Para el desarrollador final, la migración se traduce principalmente en una mejora de la estabilidad y la latencia del asistente, aunque GitHub no ha desglosado métricas comparativas públicas en el material de anuncio. Lo que sí es tangible es que un tiempo de ejecución más eficiente permite escalar mejor ante picos de uso, como ocurre durante las horas punta de desarrollo o en organizaciones con grandes volumetrías de solicitudes.
Hoja de ruta y estado de disponibilidad
Las novedades anunciadas en septiembre de 2026 cubren frentes distintos: interfaz generada por lenguaje natural, soporte para diffs masivos, un SDK específico para Java y una reescritura de infraestructura crítica en Rust. Sin embargo, el anuncio no aclara si todas las funcionalidades están disponibles simultáneamente ni si los plazos de despliegue son idénticos para todos los segmentos de usuarios. Algunos aspectos, como la disponibilidad pública del SDK para Java o el estado exacto de la migración a Rust en todas las instalaciones, permanecen sin especificar en el material de presentación.
Lo que sí está claro es la dirección estratégica: GitHub está expandiendo Copilot más allá del asistente de chat para dotarlo de capacidades de interfaz visual, soporte para flujos de trabajo complejos, manejo de código a gran escala y una base de ejecución autónoma. La combinación de estas cuatro piezas —canvases, diffs de alta capacidad, SDKs por lenguaje y un tiempo de ejecución propio— señala que el producto se está consolidando como una plataforma de desarrollo asistido, no como un simple complemento conversacional sobre el editor.
