La ingeniería de UI en la era de la IA

El 12/12/2025, la ingeniera de Zed mikayla-maki cerró una PR que proponía añadir shaders personalizados a GPUI. La respuesta fue cordial. Agradeció la contribución y explicó: “we’re shifting focus to core product work at Zed, and without a Zed use case, I can’t validate this code”. Terminaba con una cara sonriente.

GPUI es el framework de interfaces con GPU que desarrolló Zed. Suele aparecer al hablar de alternativas a Electron. Menos de cuatro meses antes, Zed había anunciado una ronda de 32,000,000 de dólares liderada por Sequoia, con la que superaba los 42,000,000 recaudados en total.

Más de nueve meses después, el 26/9/2026, el desarrollador egoist creó un repositorio llamado MyGo. En 39 días acumuló 1,042 commits, 890 de ellos con la firma de Claude.

Claude es de Anthropic. La aplicación de escritorio de la propia Anthropic usa Electron.

Juntos, estos tres hechos resultan algo extraños. Medimos 10 frameworks en dos equipos para ver en qué punto está este sector.

Aplicaciones de escritorio como Claude y Codex siguen usando Electron: la Web tiene un ecosistema maduro, una base de código sirve para varias plataformas y los modelos la conocen bien. La IA reduce el coste de desarrollo, pero la compatibilidad entre plataformas y el mantenimiento siguen exigiendo trabajo.

El renderizado propio con GPU ofrece otra vía, pero GPUI sigue dando prioridad a Zed. El renderizado multiplataforma y un ecosistema de componentes requieren inversión sostenida. MyGo muestra cómo la IA y los componentes existentes aceleran el arranque; su madurez en producción y su mantenimiento a largo plazo aún deben demostrarse.

Flutter, Compose, Slint, egui e iced toman decisiones distintas. Probamos 10 frameworks con los mismos escenarios, midiendo fluidez, CPU, memoria y fidelidad visual para conocer el coste real de cada enfoque.

Probamos 10 frameworks con los mismos escenarios en un Apple M4 Max y un ThinkPad T14 Gen6. Medimos CPU y memoria en ambas plataformas; Windows cuenta además con mediciones externas de fotogramas mediante PresentMon. Los callbacks de fotogramas de Mac difieren entre frameworks y no se usan para compararlos. El hardware y las métricas de memoria también son distintos, por lo que solo comparamos dentro de cada plataforma.

La animación es una escena densa: 500 tarjetas de 96×64 píxeles lógicos, superpuestas en 25 columnas, con radio de esquina 12, degradado de 135° y sombra con blur 16 y desplazamiento vertical 4. Todas actualizan su posición en cada fotograma y describen círculos de radio 12 con un período de 4 segundos. Publicamos la mediana de cinco rondas de 30 segundos.

Medimos principalmente el coste de CPU al actualizar la interfaz, preparar el dibujo y enviar el renderizado de muchos elementos con efectos en movimiento continuo, además de la regularidad de los fotogramas. La CPU abarca el árbol de procesos de la aplicación; no mide uso de GPU ni tiempos por etapa. Debe leerse junto al intervalo entre fotogramas: producir menos también puede reducir la CPU. Las 500 tarjetas pertenecen a la escena; la superposición y el recorte de la ventana impiden que todas se dibujen completas en cada fotograma.

Windows

Todos siguieron el ritmo al desplazar listas. La diferencia apareció en las animaciones: con 500 tarjetas con sombras y degradados, los frameworks de dibujo propio en Rust y Go mantuvieron en general los 120Hz. Flutter, Electron, Tauri y Compose llegaron a intervalos de 80 a 160ms. Los 684ms de WPF se debían a 500 efectos de sombra independientes. Al desactivarlos volvió a 8.3ms, así que no es un problema general.

La edición de texto es otro obstáculo. Al insertar 10 caracteres por segundo en un documento de 5,000 líneas, Flutter, Compose y Slint saturaron un núcleo. En Windows, Flutter perdió además un treinta por ciento de la entrada.

Mac

En Mac, el CPU de animación fue de aproximadamente 15%–20% para GPUI, MyGo, egui e iced, frente al 237% de Flutter y alrededor del 100% de Electron y Compose. Al editar texto, Flutter y Compose siguieron cerca de un núcleo completo. Slint usó un 52%, por debajo de su 99% en Windows.

En la lista, los aproximadamente 40 MiB de SwiftUI, 340 MiB de GPUI y 800 MiB de egui describen ante todo la huella de los procesos de la aplicación. La UI nativa puede usar servicios de renderizado del sistema externos: Apple documenta que AppKit prefiere renderizar los árboles de capas fuera del proceso. Parte del dibujo y la composición ocurre, por tanto, fuera de la aplicación. Los renderizadores propios también usan composición del sistema, pero sus cifras de proceso no bastan para comparar el reparto de trabajo. La memoria unificada de los chips M comparte memoria física entre CPU y GPU; no atribuye automáticamente todos los costes al phys_footprint de la aplicación.

En cinco trazas GPU cortas por escena de lista y animación de SwiftUI, no se observaron eventos de ejecución GPU del PID de la aplicación, mientras WindowServer tenía actividad. Esto no significa que SwiftUI no use GPU ni permite atribuirle todo el escritorio. La memoria base de WindowServer fluctuó unos 205 MiB; no encontrar grandes objetos compartidos en las instantáneas tampoco descarta reutilizar recursos existentes del sistema. Solo podemos concluir que el proceso de SwiftUI ocupa menos, no que todo su renderizado cueste menos ni que el sistema pague toda la diferencia.

Estas cifras solo describen estos dos equipos, estas versiones y nuestros programas de prueba. El método y los datos completos están en la sección 05.

Editores, herramientas de desarrollo y aplicaciones de negocio tienen requisitos distintos de entrada de texto, animación, memoria, distribución multiplataforma y ecosistemas de componentes. Cada uno tiene sus casos de uso. Elegir un framework implica decidir qué compromisos son aceptables.

Muchos frameworks también recurren a la retención, la caché y las actualizaciones parciales para evitar repetir el cálculo de disposición y el dibujo. GPUI combina los modos inmediato y retenido. El modelo de interfaz, el trabajo que puede reutilizar y el tiempo que tarda en dibujar un fotograma son cuestiones distintas.

MyGo, iced, GPUI, Slint y egui responden bien en animaciones y consumen poca CPU. Slint es el que menos memoria usa, egui tiene un uso de memoria algo alto y GPUI requiere aportar los controles de edición. MyGo se usa actualmente sobre todo en las aplicaciones del propio autor y aún no ha sido validado a gran escala en producción.

Flutter, Electron y Compose también tuvieron intervalos entre fotogramas y consumo de recursos poco satisfactorios en esta prueba de estrés de animación. El paquete de Tauri ocupa solo 11 MB, pero su uso de memoria en ejecución es similar al de Electron.

Ahora creemos que la verificación importa más que el renderizado.

Escribir código se ha abaratado, pero comprobar que sea correcto sigue llevando tiempo. En la encuesta de desarrolladores de Stack Overflow de 2025, el 66% había recibido soluciones de IA “almost right, but not quite”, y el 45.2% decía tardar más en depurar código de IA. En una encuesta publicada por Sonar en 01/2026, el 96% no confiaba plenamente en la corrección funcional del código generado por IA y solo el 48% afirmaba revisarlo siempre antes del commit. Sonar vende herramientas de inspección de código, así que conviene tomar sus cifras con cautela, aunque encajan con la otra encuesta.

Los lanzamientos de Slint y egui hicieron poco ruido. Nos parecen más importantes que los avances en renderizado. Los agentes necesitan inyectar entrada y tomar capturas para cambiar algo, mirarlo y volver a corregirlo. Antes, verificar una interfaz exigía que alguien se sentara ante el equipo y pulsara cada elemento. Ahora empieza a poder encargarse la máquina.

Hoy hay tres formas de hacerlo. La Web multiplataforma cuenta con más recursos. El dibujo propio con GPU no requiere llevar un navegador y la barrera para construirlo es menor que antes. Hacer una aplicación nativa por plataforma es el método más antiguo. Antes, solo las grandes empresas podían mantener varios equipos. Ahora la dificultad está en triplicar los bugs y el alcance del soporte, como señala Breunig. Si verificar cuesta menos y la calidad mejora, generar directamente una aplicación nativa para cada plataforma también podría funcionar.

También exploramos nuestra propia GPU UI. La diferencia consiste en incorporar gran parte de la DX de la Web: componentes similares a JSX, estilos similares a CSS, composición flexbox, estado reactivo y DevTools como los del navegador, para compilar al final a código nativo. Aún estamos al principio.

No sabemos qué respuesta ganará. Puede que varias convivan durante mucho tiempo. Los tres hechos del inicio siguen igual: la PR está cerrada, MyGo sigue creciendo y el escritorio de Claude sigue usando Electron. Es una época muy interesante.

Las pruebas se realizaron del 4 al 6 de noviembre de 2026. Se implementaron los mismos escenarios en cada framework con las prácticas recomendadas, la configuración predeterminada y compilaciones de lanzamiento. Tras corregir el desenfoque, se volvieron a medir la página de diseño de Compose y el escenario en reposo que comparte su implementación.

Cada escenario se ejecutó 5 veces por framework, durante 30 segundos por ronda, en serie y con orden aleatorio. Todas las tablas muestran medianas. La mediana del rango entre las 5 rondas fue de aproximadamente el 3%; el noventa por ciento quedó dentro del 24%. Repetimos lista y animación tras unificar las especificaciones, por lo que las columnas no se recogieron en el mismo periodo. CPU: un núcleo lógico es el 100%. Las aplicaciones multiproceso incluyen todos los procesos hijos. En Tauri para Mac también contamos los procesos WebKit que el sistema inicia para él. Para fotogramas de Windows solo usamos rondas atribuibles de forma única a un swapchain y sin pérdida de registros.

Verificamos el trabajo realmente completado tanto en flujo como en edición: Flutter en Windows solo completó el 68% de la edición; todos los demás superaron el 99%.

Fidelidad al diseño

La prueba de desenfoque requiere suavizar las franjas de color en un panel concreto dentro de la ventana. Al aplicar Modifier.blur con 24 dp a la capa de franjas en Compose 1.12.2, las capturas de ventanas nativas de Mac y Windows mostraron transiciones suaves. SwiftUI también desenfoca primero la capa de franjas conocida y después superpone blanco translúcido. La verificación de ambos métodos se limita a esa capa. API de Compose Desktop

Las implementaciones probadas de GPUI, iced, egui y Slint superpusieron una capa translúcida sobre las franjas. Los bordes de color siguieron siendo nítidos en la repetición. Blurred de GPUI y window::Settings::blur de iced actúan sobre el contenido situado detrás de la ventana. No encontramos una API de dibujo integrada para desenfocar fondos locales en las versiones probadas. iced permite dibujar efectos locales con renderizado personalizado, y egui puede acceder al motor de renderizado mediante PaintCallback. GPUI · Configuración de ventana de iced · Callback de dibujo de egui

La prueba de Slint se hizo con la versión 1.18.1 y FemtoVG. Esa versión carecía de la propiedad de elemento backdrop-blur. El proyecto la añadió después para el renderizador Skia. Las capturas muestran la ruta de FemtoVG en la versión 1.18.1. Incidencia de Slint

La página de diseño tiene 11 comprobaciones. GPUI, egui, iced, Slint y Compose no reprodujeron la muestra P3 en la salida Mac probada. Las capturas Windows no tienen perfil de color, por lo que no se evalúa P3; las banderas emoji aparecen como letras.

La composición converge; la mayor diferencia está en el texto. Al pedir PingFang 700 en macOS, iced recurrió a Menlo Bold para las letras latinas.

Limitaciones:

• Solo hay un equipo por plataforma. Los resultados de animación proceden de una GPU integrada Intel y pueden no ser aplicables a GPU dedicadas.
• El Mac no estaba inactivo. Los datos de fotogramas son solo callbacks de la aplicación y no se comparan entre frameworks.
• La semántica de blur de las sombras varía. egui, iced y GPUI usan aproximaciones. Los controles de edición tampoco son equivalentes: GPUI usa un editor de ejemplo modificado.
• Las tablas de CPU y memoria cubren la aplicación y los procesos auxiliares incluidos. No reparten por ventana los costes de WindowServer y del controlador ni cuantifican la reutilización de recursos compartidos del sistema; no permiten clasificar el coste total de renderizado del sistema.
• No obtuvimos resultados válidos para las ventanas de candidatos del método de entrada, el árbol de accesibilidad de Mac ni el consumo energético.