Dando Manos a los Agentes de AI: Bucles de Retroalimentación Móvil con Agent Device

Hace diez años, estaba hablando sobre CLIs, y hemos vuelto al círculo completo hablando de CLIs de nuevo. De todos modos, saben, en realidad he estado hablando tres veces en esta conferencia, y cada vez estoy en esta pista de Basecamp y generalmente hablo sobre React Native y diría que la audiencia es tal vez como la mitad de la sala, y aparentemente agregar IA al título de la charla aumentó la proporción de audiencia, así que estoy feliz de que todos estén aquí. Esta podría ser en realidad mi charla más popular hasta ahora.

Muy bien. Así que gracias por la introducción. Soy fundador y CTO en Coldstack. Hacemos aplicaciones multiplataforma con React y React Native desde hace unos diez años. He estado haciendo un poco del trabajo central de React Native, trabajando en CLI y un montón de paquetes de código abierto. Pero hoy quiero hablarles un poco sobre lo que realmente se necesita para que un agente de IA haga un trabajo móvil real, y spoiler, no se trata de incitar. Se trata de un ciclo de retroalimentación, y les mostraré cómo hemos hecho esto en un segundo. Así que vamos.

Antes de comenzar, una rápida muestra de manos. ¿Quién aquí está usando algún tipo de IA diariamente, cloud code, codex? Por favor levanten la mano. Muy bien. Eso es mucho. Supongo que todos los que no levantaron la mano, solo tienen miedo o tal vez solo se están calentando. Pero eso es básicamente todos o la mayoría de las personas. Cuando le pides a tu agente que cambie una pantalla móvil, ¿cuántos de ustedes realmente toman el teléfono y lo verifican manualmente en el simulador? Bien. Bastantes. Supongo que los demás ya están usando agent device, lo cual es genial. Así que en esta charla, les mostraré un poco de lo que sucede bajo el capó. Como dije, estamos entusiasmados con los agentes. Los usamos todos los días. Pero desafortunadamente, casi todos nosotros todavía estamos de alguna manera involucrados en el paso de verificación. Y esa brecha es lo que les mostraré cómo pueden cerrar en los próximos 20 minutos. Así que la tesis es que cada flujo de trabajo de desarrollador es un ciclo de retroalimentación. Y nuestro trabajo siempre ha dependido de una cosa, retroalimentación rápida y confiable. Cambias algo, lo ejecutas, observas, miras lo que sucedió y lo ajustas. Todo lo que llamamos experiencia del desarrollador, todo se trata realmente de hacer ese ciclo más corto. Antes de hablar sobre agentes, tal vez miremos cómo construimos retroalimentación para nosotros mismos.

Y no es que en mis tiempos, esperábamos, ya saben, 40 minutos para un tipo de diapositiva de compilación. Pero ya saben, no hace tanto tiempo, solíamos usar esas herramientas manualmente. Tal vez todavía lo hacemos, pero claramente está cambiando.

Chrome DevTools, por ejemplo, te da acceso a tantas cosas en la web, DOM Tree, red y consola. Y los navegadores envían esos DevTools y el desarrollo web se volvió dramáticamente más rápido debido a eso. Ahora, el móvil hizo lo mismo. Tienes instrumentos de Xcode, el perfilador de Android Studio, o tal vez React Native DevTools con marcos de plugins como Rosanite que te permiten agregar extensiones de la comunidad, como en este caso Expo Atlas para analizar tu paquete.

Diferentes proveedores, diferentes dispositivos, diferentes eras de desarrollo de software, pero siempre hay un trabajo cuando la aplicación está en ejecución, quieres ver qué está pasando bajo el capó y cómo tus cambios de código impactan y se comportan en dispositivos reales o simuladores. Y si has lanzado React Native en el pasado, lo más probable es que hayas trabajado con todas estas herramientas porque a nuestros respaldos realmente les encanta sentarse en algún lugar en la intersección de JavaScript y React Native, y esos son los respaldos que solo puedes ver en un dispositivo real, no en un simulador.

Entonces, en los últimos años, ha sucedido, y hoy es bastante evidente que los agentes escriben la mayor parte de nuestro código y lo hacen sorprendentemente bien. Refactorizan, añaden características y todo eso. Y ahora nuestro enfoque se dirige a la orquestación, verificación, revisando todos esos pasos para hacer que los agentes sean más productivos en el trabajo. Pero el desafío en tal configuración es que somos un humano en el bucle o un componente dentro de ese bucle de agentes.

Y no es cualquier tipo de componente, es en realidad el más lento y caro. Y solo empeora de la mejor manera posible. Un ingeniero solía producir un flujo de cambios. Ahora cada ingeniero ejecuta dos, tres agentes en paralelo y el código sale más rápido de lo que cualquiera puede realmente verificar manualmente en el dispositivo. Y la mitad verificada sigue siendo un humano, un par de ojos, y no puedes simplemente arreglarlo leyendo más diferencias. En algún momento, la capacidad de tu cerebro simplemente se agotará.

Y tenemos que solucionarlo de la misma manera que lo solucionamos para nosotros mismos. Tienes que dar a los agentes una forma de verificar lo que sucede en el dispositivo. Ahora los agentes web tienen esto, el navegador estaba justo allí, y la frase popular simplemente dar a los agentes un navegador funcionó bastante bien. Había Playwright, MCP, y todas estas herramientas. Así que fue bastante fácil comenzar. Sin embargo, el móvil es una historia un poco diferente.

Porque, en primer lugar, los agentes móviles necesitan trabajar en simuladores y dispositivos. Así que, por definición, tienes una amplia gama de cosas que necesitas tener en cuenta. Necesita sobrevivir a diferentes restricciones ambientales, diálogos de permisos, alertas, teclados que aparecen en el momento equivocado. Realiza gestos, no clics. Los registros a menudo se dividen entre JS y nativo, y tienes muchas superficies diferentes. En todo, iOS solo se ejecuta en macOS, que tu CI o tu compilación odian.

Y es por eso que simplemente dar al agente un navegador realmente no se traduce a ese tipo de flujo de trabajo en móvil. Así que decidimos hacer algo al respecto, y creamos Agent Device. Ahora Agent Device es esa capa que permite a tu agente operar en una aplicación móvil, realizar muchas automatizaciones diferentes, abrirla, ver los registros e interactuar con la aplicación. Y puedes hacerlo en simuladores y en dispositivos. Ahora, antes de que imagines algún marco pesado, Agent Device es solo un CLI. Simplemente npm install y listo. Está en tu máquina. Y eso importa bastante, porque a los agentes les encantan los CLIs. Y ya viven en el terminal.

Así que no tenemos que integrar ningún SDK o conectar nada. Tu agente solo tiene un comando más con el que trabajar, y ya trabajan con un montón de comandos. Así que aquí está todo lo que Agent Device hace en cinco simples pasos. Puede abrir la aplicación para ti, iOS, Android, TV o simulador, dispositivo real. Puede capturar lo que está en pantalla, en este caso accesibilidad, lo cual explicaré en un segundo. Puedes actuar sobre ello, realizar cualquier tipo de interacciones móviles, toques, desplazamientos, deslizamientos, gestos reales. Puedes recopilar evidencias cuando sea necesario, capturas de pantalla, registros de dispositivos, grabaciones de video. Y puedes reproducir la sesión más tarde como un script. Así que podemos pensar en tener un marco de pruebas de extremo a extremo gratis al final del día.

Ahora, una decisión de diseño en la que quiero detenerme un momento, porque es donde a menudo tenemos preguntas, ¿por qué no usar capturas de pantalla? Así que cuando un agente mira tu aplicación móvil con Agent Device, lo primero que ve no es una imagen. Es un árbol de accesibilidad, que se ve así. En el lado izquierdo, tienes la captura. Y en el lado derecho, tienes la aplicación expo fresca. Así que primero, el árbol de accesibilidad le dice a tu agente lo mismo con lo que tu usuario realmente puede operar. No es una jerarquía de vistas. Es más una referencia semántica interactiva a elementos. Y cuando el agente decide actuar sobre ello, presionará, por ejemplo, E12, tal vez, y eso hará referencia al elemento E12 en el árbol. Y hay un bono aquí. Esto solo funciona cuando tu aplicación está lista para accesibilidad. Así que si funciona con un lector de pantalla, funcionará con Agent Device. Si no, tendrás que arreglar tu árbol de accesibilidad.

Así que es un tipo de buen compromiso, supongo, para aplicaciones más accesibles. Entonces, ¿por qué importa tanto esto? En primer lugar, la economía de tokens. Sabes, el árbol de texto cuesta mucho menos que las imágenes. La visión es poderosa, pero obviamente es un poco más costosa de ejecutar. Pero incluso si puedes reducir el costo de los tokens, será mucho más lento. El modelo puede actuar sobre esos REFs con bastante precisión. Cuando usas capturas de pantalla, coordenadas, tal vez algunos elementos en la pantalla se superponen. Siempre hay algo de margen para la interpretación. Esto es más estricto. Y aquí, es más barato de ejecutar en general.

Así que cuando piensas en tu bucle, deberías pensar en ejecutar esto tal vez, ya sabes, multiplicado por 50, porque tu objetivo es ejecutar muchos de esos bucles de retroalimentación y tal vez seguir paralelizando tu trabajo. Así que aunque mantener el costo más bajo en una, dos ejecuciones pueda parecer irrelevante, piensa en cientos de estos, y entonces lo verás. Genial. Suficiente charla. Veamos la demostración. Como dije, Agent Device no es realmente un marco, y simplemente trabajas con él añadiéndolo a lo que sea tu agente de codificación.

Así que en este caso, tengo este prompt muy, muy realista, que trata sobre modificar la plantilla de Expo con ponentes del React Summit. Y la única diferencia aquí es que al final, estoy instruyendo al agente para usar Agent Device para verificar la retroalimentación. Obviamente, esto es opcional. Puedes ponerlo en el MD de tu agente o lo que sea. Pero en este caso, no lo tengo. Así que por eso lo estoy añadiendo. Y luego el agente va a empezar a trabajar en ello. Y estoy usando Codex y GPT 5.5 Medium. Extraerá ponentes del sitio web del Summit, construirá una base de datos local para eso, y añadirá esa aplicación a la aplicación. Y está hecho. Y puedes ver en el lado izquierdo, puedes ver que tiene una pequeña lista de verificación. Y tuve que detener el video en algún momento. Así que la verificación local de ejecución no está tachada. Pero está tachada.

Así que en realidad asume que todo está funcionando. Y sin Agent Device, ahí es probablemente donde terminaría tu flujo de trabajo. Y serías tú quien elegiría el simulador, interactuaría y probaría tu aplicación. Pero esta vez, habíamos verificado el trabajo. Así que veamos qué sucede después. Verificará la instantánea de la vista actual, navegará a Speaker Tap, intentará tocar un ponente. No funciona. Intentará cambiar la forma en que se realiza la navegación usando una API diferente. Pero una vez que eso tampoco funcione, llegará a la conclusión de que hay una jerarquía de navegación incorrecta.

Y sabes qué es lo gracioso, tuve que cambiar mi charla en el último minuto. Porque inicialmente, cuando estaba diseñando esta charla, asumí, está bien, el primer prompt tendrá éxito. Luego tendré que crear este error falso. Y luego te guiaré a través de, está bien, ahora hagamos algo que no funcione. Y esto es en realidad solo un error aleatorio que ocurrió cuando estaba haciendo algo simple. Solo agrega una pantalla y empuja hacia ella. Y sabes lo que pasó es que la aplicación regular de Expo solo tenía pestañas. Así que cuando comencé a empujar desde una pestaña, no había un stack navigator raíz que pudiera realmente tomar la ruta a la que estábamos empujando.

Así que, sí, todo estaba funcionando desde la perspectiva del desarrollador, pero el navegador padre no funcionaba. Honestamente, estoy bastante sorprendido de que 5.5 no lo manejara. Pero afortunadamente, eso hizo que mi demostración fuera aún más realista. Así que el agente dijo que funcionaba y su propia verificación demostró que estaba equivocado. Así que la pantalla del ponente nunca se empujó. Como dije, la jerarquía de vistas estaba rota. Así que una vez que se identificó el problema, y nuevamente, esto es solo una continuación del mismo video. La solución fue bastante fácil. Simplemente reemplaza la raíz o envuelve la raíz con stack navigator. Y aquí tienes. Ahora funciona automáticamente. Así que toda esta experiencia tomó alrededor de 7 minutos en total porque estaba haciendo algunas otras cosas entre medio. Pero la conclusión aquí es que sin este paso, no se completaría.

Y ahora con este paso, en realidad se autocorrigió. Así que gracias a agent device, todo el bucle verificó la UX en un dispositivo real. Navega a través de todo el flujo, pestañas, cuadrícula, hasta los detalles de la charla. Y aplicó las correcciones necesarias en la misma sesión seguida de otra verificación antes de informar que se ha completado.

Sin embargo, no todos los errores pueden ser descubiertos de esta manera. Algunos errores residen debajo del estado. Eso está mal, aunque la pantalla parezca normal. Y para esos, agent device te da acceso a algunas cosas bajo el capó. Como en este caso, tienes acceso a React DevTools a través del CLI. Puedes encontrar componentes, leer props, estado, usando la misma noción de árbol de accesibilidad que para leer la instantánea.

Y el modelo mental compacto aquí es que el árbol de accesibilidad responde a la pregunta externa, ¿qué puede hacer el usuario? Eso es lo que vemos. Y luego el árbol de React responde a la otra pregunta, ¿qué está renderizando, qué está pasando bajo el capó? Y esa es la vista que necesitamos cuando la vista externa no es suficiente. Y un agente está depurando una aplicación de React Native de ambas maneras, un poco como solíamos hacerlo cuando depurábamos tanto la UI nosotros mismos con los ojos como teniendo DevTools abiertas en el lado derecho.

Hay muchas más características en esta caja de herramientas. Puedes hacer logging, para que puedas leer logs nativos, marcadores, reproducir y leer exactamente lo que sucede en el lado nativo. Puedes extraer el tráfico HTTP y ver qué solicitudes están fallando, ¿dónde está la información pasando a través de la red? Puedes leer el rendimiento de inicio, la memoria, el perfilado de CPU. Y también puedes ver el perfilado de renderizado, qué componentes son lentos, re-renderizando, y así sucesivamente.

El punto es, cualquier evidencia que tu agente necesite, está ahí. Así que con todas esas características, tengo una demostración más para mostrarte. Y en este caso, vamos a hacer esta depuración realista en la aplicación Expensify. Vamos a realizar un flujo de usuario en el que vamos a presentar un gasto. En este caso, voy a intentar seguir lo que sucede aquí. Pero básicamente estamos haciendo una instantánea para poder llegar a la pantalla correcta.

Estamos abriendo DevTools. Vamos a hacer logging y marcadores para leer lo que está pasando, cuál es el tráfico. Cuando vamos a presentar un gasto, lo cual implicará tomar una foto con la cámara, vamos a poner un marcador en el lado nativo para leer el logging, qué sucede con el dispositivo nativo antes de que lleguen las cámaras, por ejemplo aquí. Y después de recopilar toda esa evidencia con logs, tiempos, perfilado y red, podremos continuar depurando, analizando, y el agente llegará a conclusiones sobre lo que está pasando.

Así que, típicamente, es el mismo flujo de depuración que haríamos, pero gracias a agent device, el agente ahora puede hacerlo de manera autónoma. Y como puedes ver, está encontrando evidencia de que alguna red está tardando mucho más, la API necesita ser mejorada, y hay algunos problemas con las entradas de texto. Así que hay un montón de esas cosas. El video está ligeramente aumentado en rendimiento, en velocidad, pero al final del día, ves problemas clave de rendimiento que fueron descubiertos.

Así que es bastante interesante cómo puedes hacerlo, y aquí tienes el uso total de tokens durante esa sesión. Así que no mucho, para ser honesto, y el tiempo ahorrado fue bastante bueno, al menos incluso para ver más información de tu aplicación, lo que está sucediendo. Así que de vuelta a este gráfico. Como puedes ver, la salida de código va en vertical, y la verificación, la única verificación que escala con ella, es la verificación que se ejecuta sin que estés en el bucle.

Y ese es un AQA agent que puede vivir en tu CI, y así es como se ve. AQA agent puede recoger la diferencia, abrir la aplicación, hacer cualquier tipo de depuración, grabar el flujo, hacer lo que quieras que haga, y el PR recibe este bonito comentario. Y ahora si estás pensando que, ya sabes, tal vez este es algún tipo de proyecto difícil de construir, o necesitas comenzar con un producto listo para usar, en la mayoría de los casos eso podría ser una buena dirección, sin embargo, en realidad es bastante fácil de construir para tu caso de uso para comenzar.

Como puedes ver, realmente nada, diría yo, revolucionario. Este es un bucle de herramienta versátil con acceso a agent device que puedes ejecutar en tu CI, y llamamos a estas plantillas en la documentación de agent device. Y tenemos una receta lista para EAS, que se ejecuta en un Mac, por lo que podemos hacer esto con solo unas pocas líneas de código. Y aquí está el artículo en ExpoDev que hicimos, para que puedas leerlo y configurarlo tú mismo. Ahora, la pregunta es, ¿dónde lo ejecutamos realmente?

Si tu CI puede ejecutarse en un Mac, estás en casa, como EAS. Pero si no estás usando un corredor de Mac, tal vez sea demasiado caro, tal vez tu proveedor no lo tenga, entonces se convierte en un desafío. Así que para ese caso de uso, también tenemos una solución, porque típicamente, en la mayoría de los casos, tus agentes están ejecutándose en sandboxes ligeros de Linux, por ejemplo, Versal Sandboxes, estás haciendo algunos cambios de código y quieres tener ese feedback rápidamente, iniciar Mac OS simplemente será demasiado lento o demasiado caro. Así que para esa solución, tenemos lo que llamamos un proxy de agent device, que es un proxy simple que inicias en tu máquina host, ya sea tu corredor de Mac OS o tu Mac que tienes en tu casa, y luego los comandos fluyen desde el sandbox al Mac y luego de regreso con las instantáneas, capturas de pantalla y evidencia fluyen de regreso a través del cable.

Así que en la práctica, aquí hay otra demostración, puedes ver una nube ejecutándose en la nube, y aunque se está ejecutando en la nube en Linux, aún puedes ver agent device depurando exitosamente los resultados y dándote capturas de pantalla y esas capturas de pantalla se hicieron en tu máquina local y se enviaron de regreso a la nube. Todo lo que tienes que hacer es iniciar este proxy simple en tu máquina objetivo, algo así como un túnel ngrok, y luego conectarlo desde la nube. O si no tienes una máquina a mano, puedes contactarnos y lo configuraremos para ti. Y eso es básicamente todo. Así que hagamos un resumen rápido.

Los agentes necesitan un bucle de retroalimentación y sin uno, tú eres la persona que les da retroalimentación. Un agent device es tu respuesta móvil a esto, y así es como tus agentes pueden trabajar con tus simuladores y dispositivos. Para el navegador, puedes usar agent browser, que sigue los mismos patrones, y es un proyecto realizado por amigos en Vercell. Puedes usarlo para desarrollo, depuración y QA, y has visto los tres hoy.

Y como es un CLI, un concepto muy ligero, puedes construirlo tú mismo y ponerlo en CI. Puedes ajustarlo a tus necesidades, después de todo, es solo un CLI y depende de ti, tu agente y tu flujo de trabajo hacerlo. Y funciona en la nube. Así que podemos escalarlo fácilmente cuando sientas que estás haciendo demasiado y tu flujo de trabajo local no puede seguir el ritmo.

Todo está en agent-device.dev. No he probado el código QR, pero con suerte funciona.

Agent-device.dev. Tenemos su GitHub, documentación, plantillas, el EAS, RECP, todo lo que necesitas para comenzar. Espero que lo hayas disfrutado y que tu bucle de retroalimentación ahora sea mucho más corto y rápido. Encantado de responder algunas preguntas y también más tarde, encantado de hablar sobre agentes, React Native o cualquier cosa entre medio. Muchas gracias.

La primera pregunta que tenemos para ti es, ¿puede funcionar con Flutter o solo con Expo o React Native? Buena pregunta. No lo he probado con Flutter, pero diría que si Flutter tiene características de accesibilidad, debería. Agent-device es independiente de la plataforma, por lo que puedes usarlo con aplicaciones nativas de iOS también. Tenemos bastantes ejemplos cuando usamos agent-device para hacer algunas automatizaciones en nuestros iOSes, como por ejemplo, obtener datos de Apple Health. Definitivamente no es solo para React Native y Expo. Se supone que es multiplataforma, multiframework y se centra en el lado nativo.

Eso es genial de escuchar. Esencialmente estás usando las características de accesibilidad del sistema integradas, lo que hace que funcione en todas las plataformas. Eso es genial. A esta siguiente, es de Jan. ¿Cómo detecta o maneja agent-device la regresión visual cuando la UI cambia inesperadamente entre interacciones sin cambiar el árbol de accesibilidad? Desearía poder cambiar rápidamente mi laptop, pero el equipo simplemente la está desconectando de todos modos. Tenemos esta característica llamada Screenshots Defink, en la que realmente trabajamos como parte de la construcción de agentes de migración.

Uno de los casos de uso que no he mencionado en la charla es usar agent-device para agenting migraciones. Comienzas con una captura de pantalla de una aplicación nativa y quieres hacer un clon exacto para la aplicación React Native. Tenemos Screenshot Defink, así que tomaremos la captura de pantalla, la compararemos, te mostraremos las diferencias entre fuentes, tamaños, márgenes de relleno de una manera agradable, para que tu agente pueda tener un poco de retroalimentación sobre lo que está cambiando y por qué.

Increíble. Esta siguiente pregunta, ¿puede agent-device reemplazar las herramientas tradicionales de pruebas end-to-end, como Detox o Maestro? Sí, puede. Tiene una característica que llamamos Replace. Después de que cada sesión se completa, como todos los videos que te mostré en mi charla, puedes obtener el script. En realidad está guardando todos sus pasos, y luego la próxima vez, no tienes que hacer agent-device, no sé, snapshot o hacerlo con el agente. Simplemente puedes hacer agent-device replay, poner tu script, y boom, tienes una repetición exacta. Lo curioso es que esas repeticiones dejan algo de espacio para la diferencia. No es como tocar este botón y luego ir allí. Deja algo de espacio para la flexibilidad, por eso a menudo funciona a través de pequeños cambios. Sí, es increíble escuchar eso, y básicamente en ese punto, ya no estás usando tokens, básicamente tienes una especificación. Sí, exactamente. Eso es genial.

Bien, esta siguiente pregunta, para un proyecto web de aplicación cruzada desde una única base de código, ¿puede agent-device también validar la parte web? Ahora mismo, no lo hace. Ahora mismo, tienes que usar agent browser por separado, sin embargo, estamos recibiendo más y más solicitudes para incluir agent browser o algún tipo de soporte para navegador de todos modos. Así que creo que se hará, y Michał probablemente lo está viendo, el mantenedor y autor de agent-device, así que Michał, ahora la pregunta está en el aire, así que tenemos que lanzarlo. Increíble. Bien, siguiente pregunta. ¿Hay otros casos además de usar un agent-device para pruebas, como crear bots? Sí, quiero decir, uno de nuestros casos de uso favoritos es usar agent-device para hacer algunas automatizaciones en el dispositivo donde no tienes API. Hay algunos modelos de visión interesantes y modelos hechos específicamente para controlar el dispositivo, creo que algunos de ellos son de ByteDance, así que creo que algunas personas lo están usando de esta manera, y definitivamente puedes hacerlo. Genial. Sin embargo, no hagas nada malicioso. Buenas razones. Siguiente pregunta, ¿agent-device también admite el uso de dispositivos reales? Sí, me encantan todas estas preguntas porque estoy como, sí, sí, sí, afirmativo. Admite dispositivos reales. Parte de la razón es que estamos usando APIs oficiales de Apple para pruebas. No son tan rápidas como nos gustaría que fueran. Sin embargo, funcionan en todos los dispositivos, por lo que puedes hacerlo en un simulador, puedes hacerlo en un dispositivo real.

We have people running this on device farm. For example, Mark Grossavi, he has a vision camera library, and he's been working with agent-device to run all the tests in device farm. I'm not sure if he actually made it announced already. If I leaked it, I'm sorry, but yes. Amazing.

Okay, next question. If this runs on CI, what optimizations can be made to prevent token spend exponential increase? That's a good question. Yeah. Some kind of optimizations, yes. I mean, we haven't gone into this. It's kind of outside of scope of the initial library. Although I guess at this point, same optimizations would apply as you would normally do. So perhaps a bit of caching, using replay scripts, optimizing them, and doing some smart device routing to prevent maybe going too deep into testing. That makes sense.

In your experience, is there any specific model which works really well with React Native? For coding? Yeah. Spoiler alert, we have our own. It's called Apex. If you type it, Apex call stack into Google, I love how this comes up, actually. It's not like I'm shilling my own tool. So we have our own React Native fine-tuned model, which is based on JMA4. We are trying to hit an angle of getting a nice cost optimization versus feature set. But if you want to check yourself which model is the best, you can type React Native evals in Google. In our evals data set, we're building it, trying to make it more, better, and better. But it gives you some kind of insight into which models are best. Right now, Composer 2 is killing it. But after Composer 2, it's GPT 5.4 and Opus 4.7. Surprisingly, 4.8 and 5.5 didn't improve much, apart from being five times more expensive. So just check it yourself and see the results. Fantastic.

Tiempo para una pregunta más. Veamos. Si lo usamos como un reemplazo para Detox o Maestro, ¿dirías que esto podría ser más inestable que esos? Creo que parte de la inestabilidad se debe solo al dispositivo, Apple, todas las conexiones, y el arnés en sí. Así que creo que hay algún componente de inestabilidad que ambos marcos tendrán. Tenemos algunos videos interesantes donde comparamos el rendimiento con Maestro, y estamos alcanzando el rendimiento tratando de ser más rápidos. Así que queremos mejorarlo. Pero obviamente hay algo de inestabilidad de todos modos.

Sí. Y todavía tenemos tiempo para la última pregunta. Sí, hagámoslo. Entonces, ¿soporta plataformas de TV? Sí. Genial. Muy bien, Mike, muchas gracias. Gracias.